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 email 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