Trust Center Access Guide¶

This guide is for agency and customer users of a system operated in GRC-ITSM. It covers two ways to reach your certification data: the Trust Center portal, and the REST API for programmatic pulls.

Both paths show you the same records. The portal renders them for people; the API returns them for machines.

Part 1 - Portal access¶

Getting an account¶

Portal access is granted through a User Access Request (UAR). Your sponsor or point of contact submits the UAR under Request Services; an approver reviews it, and the request is tracked as a ticket you can audit later. Access is removed the same way.

You can also self-register from the portal login page (Create New User Account). A self-registered account is associated with your organization when your email domain matches; otherwise it is held unassociated. Either way, a UAR approval is still required before you can access your system's certification data.

Accounts are role-based. Your views are scoped to your own system, so you see your system's records and nothing else. Sensitive fields are excluded from shared reports.

The five portal surfaces¶

ConMon Reports¶

Ten reports, each in a FedRAMP shape, reading live system state:

1. Public Information
2. System Information
3. System POCs
4. Inventory (IIW)
5. Open POA&M
6. Closed POA&M
7. Vulnerability Details
8. Accepted Vulnerabilities
9. Reportable Incidents
10. Significant Changes

Because these read live records, the numbers change as the system changes. For a fixed snapshot you can cite, use Certification Documents.

Certification Documents¶

Point-in-time artifacts for the certification package. This includes the FedRAMP-schema JSON files (Security Decision Record, Certification Overview, Vulnerability Detail, and the Significant Change JSON to be published alongside them) plus the uploaded package documents. The provider will save historical snapshots aligned to Ongoing Certification Reports here as each report is issued.

Asking questions and sending feedback¶

Use Request Services. Pick the category that fits (General Services for questions and feedback, Incidents and Outages for an outage, Change Requests for a change, ConMon Requests for monitoring data). Your submission becomes a tracked ticket and shows up under My Requests & Tickets, so you can follow it without emailing anyone.

Part 2 - Programmatic access¶

How credentials are issued¶

There is no self-service token flow. The provider creates and issues your API credentials, scoped to your organization and your system.

To request programmatic access, submit a service request under Request Services (the same UAR path used for portal accounts). The provider then issues you:

• a Client ID and Client Secret
• your base URL and, on hosted instances, your tenant identifier
• the report ids for the reports your organization can pull
• the document retrieval endpoints for your system

Keep the secret in a secrets manager. Treat it as a credential to your system's certification data.

Step 1: Get an access token¶

Authentication is OAuth2 client_credentials. POST form-urlencoded to /auth/token:

curl -s -X POST "https://YOUR_BASE_URL/auth/token?tenant=YOUR_TENANT" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=all"

The ?tenant= query parameter applies to hosted instances. Your credential package tells you whether yours needs it.

The response contains an access token valid for one hour; expires_in gives the exact lifetime. There is no refresh token: when the token expires, call /auth/token again with the same client credentials. Cache the token for its lifetime rather than re-authenticating per request.

Every subsequent call carries the token in the Authorization header:

Authorization: Bearer YOUR_ACCESS_TOKEN

Step 2: Pull a report¶

GET /Report/{id} with loadreport=true returns the report together with its data:

curl -s "https://YOUR_BASE_URL/Report/1234?loadreport=true" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Use the report ids from your credential package. Those ids identify the reports your organization is entitled to pull.

Step 3: Retrieve a document¶

Your credential package includes the document retrieval endpoints for your system. When a document is attached to a ticket or record, fetch it by id:

# list
curl -s "https://YOUR_BASE_URL/Attachment?ticket_id=5678" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

# retrieve; printit=false returns a URL to the attachment
curl -s "https://YOUR_BASE_URL/Attachment/91011?printit=false" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Use the ids and paths your credential package names.

Rate limit¶

700 requests per rolling 300-second window. Exceeding it returns HTTP 429.

Practical guidance:

• Cache the access token for its full hour. Re-authenticating per call burns request budget for nothing.
• Poll on a schedule, not in a loop. ConMon reports change at the pace the system changes.
• Handle 429 with backoff and retry rather than immediate re-send.
• Pull reports rather than reconstructing them from many small calls.

Quick reference¶

Getting help¶

Submit a request under Request Services in the portal. Questions about credentials, report ids, or document endpoints go through the same channel and are tracked as tickets.