Skip to main content
U.S. flag

An official website of the United States government

Single Sign-On Integration

If your agency has an identity provider that supports SAML 2.0-based Single Sign-On (SSO), such as Active Directory Federation Service (ADFS) or SecureAuth, you can integrate your identity provider (IDP) with, at no cost, so users from your agency can authenticate to using your agency IDP.


The process for integrating with using your SSO solution is fairly simple and straightforward. To properly integrate, here is a high-level overview of what the process looks like.

  1. Send an email to Support to get the process started, notifying us you’d like to integrate.
  2. Support will ask you for three things:
    • Public SAML 2.0 Endpoint (preferred) or Federation Metadata
    • 100x100 transparent PNG of your agency’s seal
    • List of email domains to authenticate users against
  3. Once Support has the information, we’ll schedule and then deploy the configuration to our staging environment. This aspect can take a few weeks as it requires manual steps from the Operations team.
  4. will notify you of when the IDP configuration is available in our staging environment.
  5. You can try to log into our staging environment’s user portal to ensure the login process works as intended and verify with Support you can log in successfully.
  6. Once the previous step has been completed, the Operations team will schedule and deploy the configuration to our production environment, at which point your SSO configuration will be ready to go!

We provide SSO integration with federal agencies at no cost, since using an agency IdP reduces our overall support and compliance costs. Validation that you control an IdP with a valid U.S. government email domain is sufficient for our needs.

System Information

By default, your SSO integration will appear on our default login page for all customers with your agency seal and base email domain for an easy user experience. Below is a list of things that you may find useful for integrating with us, depending on your IDP’s configuration. The only attribute needs to authenticate a user is the email attribute as we manage group membership independently of the downstream IDP.


This is the environment where we test the configuration first. It matches our production configuration minus the hostnames and endpoints.



Entity ID


OIDC Configuration



The same configuration as our staging environment, just with production hostnames and endpoints.



Entity ID


OIDC Configuration


Root Certificate

Here is the public key of our root certificate. Use this if you need to trust our SAML provider and you can’t properly get it from our SAML endpoints.


Upstream Documentation

If you would like to understand how the integration works, please see the open source documentation. LDAP integration is not supported, only SAML. In the existing configuration, acts as the Service Provider (SP) in the SAML assertion workflow, and any authentication requests coming from will be SP initiated. IDP initiated authentication is not supported.

Active Directory Federation Services Integration Reference

This is a basic reference of steps used to configure Active Directory Federation Services (ADFS) as a SAML IDP for your agency in These steps listed are intended to be used as a reference, not a source of truth, as every agency will likely have a different configuration. These steps were kindly donated to by the folks from the Office of Management and Budget (OMB).

Add Relying Party Trust

Add a new Relying Party Trust

You can find the Microsoft documentation for configuring a Relying Party Trust here. You will need to select the Claims-aware Trust radio button.

Select a Data Source

Select the Import data about the relying party published online or on a local network radio button. While you can download the SAML SP metadata, by referencing our metadata endpoint, you can receive any updates as we push them out. Enter the staging or production metadata URL referenced in the System Information section.

Specify Display Name

This value can be whatever you want it to be, we recommend attaching an environment reference so it’s easily distinguishable between the environments at a glance. Notes are optional and at your discretion.

Choose Access Control Policy

Apply whichever policy is relevant to your agency, however it’s recommended to allow Permit Everyone as manages user authorization within the platform.

Ready to Add Trust

Verify the initial configuration is valid and then save it.

Secure Hash Algorithm

In order to properly ensure all data is encrypted and decrypted in the same format, the relying party trust needs to use the same algorithm uses.

  1. Double-click the new relying party trust.
  2. In the Advanced tab, select SHA1 for the Secure hash algorithm.

Configure Certificate

You can find our root certificate referenced above if you need to explicitly trust our system. Our referenced root certificate is PEM encoded, so you will need to convert it to a format supported by Windows. You can use whichever tools you are most comfortable with for the conversion, if you would like to use open source tooling, Stack Overflow user evergreen has a great guide about using OpenSSL to convert certificates between various encodings, you can find that guide here.

To import the encoded certificate into ADFS, you will need to execute these steps on all servers configured to respond to SAML requests.

  1. On the ADFS server, start MMC (mmc.exe).
  2. Add the Certificates snap-in for the computer account and manage certificates for the local computer.
  3. Import the root CA certificate into Trusted Root Certification Authorities > Certificates.

ADFS will refresh it’s certificate store the next time an authentication request comes in, no need to take manual steps.

Disable Revocation Checking does not support certificate revocation checking, so the certificate revocation check will need to be disabled. This is specific to the relying party trust and will not impact other configurations.

Run this command in Powershell:

Set-AdfsRelyingPartyTrust -TargetName "<display-name>" `
  -EncryptionCertificateRevocationCheck None `
  -SigningCertificateRevocationCheck None

Create a Claim Mapping

In order to properly map users in your SSO system to the SAML identifier, you may need to create a claim policy. If this is the case, you will need to take these steps for each of the environments.

  1. Select the relying party trust.
  2. Right-click > Edit Claim Issuance Policy
  3. Add Rule
  4. You can name the rule whatever is easiest to understand, we recommend something similar to Transform NameID to Email so it’s clear.
  5. Here are the field values to set
    1. Incoming claim type: E-Mail Address
    2. Outgoing claim type: Name ID
    3. Outgoing name ID format: Email
  6. Select the Pass through all claim values radio button.
  7. Save the policy.


This is the end of the reference kindly donated by OMB, please ensure you try to log into


We are committed to improving the user experience of government. If you have questions, please don’t hesitate to reach out at We recommend that you subscribe to service updates at the StatusPage.