SSO Integration
Introduction
Welcome to the DFS SSO Integration Guide! This guide is designed to help you understand SSO Integration and how to implement it.
What is SSO Integration?
SSO integration stands for Single Sign-On integration, and it refers to the process of allowing users to access multiple applications or services with one set of login credentials (typically a username and password). Instead of requiring separate logins for each service, SSO enables centralized authentication.
Who is This Guide For?
This guide is for individuals and/or organizations that need to access any combination of the following with DFS:
- Zeus
- Portal
- Flight Status
- Vault
- Services
- Database
- Permissions Required
- API
How to Use This Guide?
Whether you are a new or current customer, this guide will walk you through:
- Identity Provider (IdP)
- Authentication Configuration
- User Attribute Mapping
- Security and Authentication Rules
- Testing and Validation
- Support and Contact Recommendations
- Additional Considerations
How It Works
Implementing Single Sign-On (SSO) is an efficient and secure way for users to access multiple applications with a single set of credentials. Below, we outline the information we need to properly configure SSO for your organization.
Identity Provider (IdP)
- SSO requires an Identity Provider (IdP) to authenticate users. Please ensure that your organization has already set up an IdP such as Active Directory Federation Services (ADFS), Okta, Azure AD, Google Identity, OneLogin, or any other compatible identity provider. DFS will need the following information:
- Identity Provider (IdP) Name
- What platform are you using for SSO?
- IdP URL
- The authentication service URL (typically something like https://idp.example.com).
- IdP Public Certificate
- Please provide the public certificate that the IdP uses to sign the OpenID Connect or OAuth responses. This is necessary to validate the authenticity of the authentication responses.
Configuration for OpenID Connect (OIDC) or OAuth
Currently DFS supports OpenID and OAuth protocols. Depending on the protocol used for SSO (OpenID Connect or OAuth), we will request the following information:
OpenID Connect (OIDC)
- Issuer URL
- The base URL of the IdP that identifies the authentication server (e.g., https://accounts.google.com).
- Client ID
- The unique identifier of the client used to authenticate your application with the IdP.
- Client Secret
- The secret key generated when registering your application with the IdP.
- Redirect URI
- The URL where the IdP will send users after authentication.
- Scopes
- The permissions requested to access user information (e.g., openid, profile, email).
OAuth
- Authorization Endpoint (Authorization URL)
- The URL where users will be redirected to authorize access. This endpoint is usually something like https://idp.example.com/oauth/authorize.
- Token Endpoint (Token URL)
- The URL where the application can exchange the authorization code for an access token (and optionally a refresh token). For example: https://idp.example.com/oauth/token.
- Client ID
- The unique identifier obtained when registering your application with the OAuth provider.
- Client Secret
- The secret key used to authenticate your application to the OAuth provider.
- Redirect URI
- The URL to which the IdP will send the authorization code after the user grants access.
- Scopes
- The permissions requested by the application (e.g., read, write, profile, etc.).
- Refresh Token Endpoint (optional)
- If you plan to use refresh tokens, the URL to obtain new access tokens using a refresh token.
User Attribute Mapping
It is important to ensure that the user attributes provided by the IdP align with what our platform requires. Common attributes include:
- Full Name
- FirstName, LastName
- Email Address
- User Roles
- Roles, Permissions
- User ID
- User ID or UID
- User Group
- User Group, if applicable
- Please specify which attributes should be provided and how they should be formatted.
Security and Authentication Rules
To ensure a successful implementation, we need to confirm the following:
- Logout Policy
- Are there any specific requirements for user logout, such as automatic expiration or the use of "single logout" (SLO)?
- Session Duration
- What is the standard session duration for users in your platform? This information is important to manage sessions and expiration.
Testing and Validation
Before moving to production, it is important to perform tests to ensure that the SSO integration works correctly. We will need:
- Test Users
- Please provide a set of users for login tests and to verify that the user attributes are being transmitted correctly.
- Testing Environment (Sandbox)
- If you have a testing or staging environment where we can perform the integration tests without affecting the production environment, please provide the details.
Support and Contact
In case adjustments are needed or issues arise during the integration, it is helpful to have a contact within your team:
- Contact Name
- Person responsible for configuring the IdP or SSO.
- Support Email
- Email address for technical issue resolution.
- Phone Number (optional)
- For faster response in case of urgency.
Additional Considerations
Estimated Setup Time
- Depending on the complexity of the integration and the availability of the required data, SSO integration may take between 3 to 4 weeks.
- This includes testing and adjustments.
- Note: We can add the code to support SAML, however this will take additional development time.
- Additional Documentation
- If your identity provider has technical documentation (e.g., integration guides for OIDC or OAuth), we would appreciate it if you could share that with us for faster integration.