Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the name of the feature (Single Sign-on). CargoDocs supports SSO through SAML 2.0.
SSO using SAML 2.0
SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain single sign-on (SSO). In other words, it allows a user to authenticate in a system and gain access to another system by providing proof of their authentication.
The setup process will work as follows.
- Upon request from Customers or Partners, essDOCS will provide all SSO configurations as needed by the Identity Providers.
- The client configures the Identity Providers and provides the .xml federated metadata file.
- essDOCS updates the metadata file.
- SSO testing initiates.
SSO Testing Environments
Each client will be provided a seperate UAT & Production configurations.
Three elemental properties must be configured per the settings provided by essDOCS.
|SSO Service provider identifier
|The Reply URL is where the application expects to receive the authentication token. This is also referred to as "Assertion Consumer Service" within SML.
|Sign On URL
|URL where the whole sign-in process starts.
There are scenarios based on the implementation to migrate the users over to the SSO based on a certain approach. Here are some elemental approaches to SSO Migration.
|This aspect relates to a new setup where all users will be joining the organization SSO for the first time.
|No migration is needed as all SSO users will be new.
|The entire user base needs to be migrated over to the SSO.
|All users are migrated to SSO in a single go. This method is widely adopted for SSO migration.
|Majorly used for wide-scale migration of users across the organization.
|For large-scale in-use systems, the Phased rollout approach enables the user base to shift over to the SSO batch by batch.
SSO Authentication deals with validating user credentials and establishing the identity of the user who is gaining access to the essDOCS platform.
Security Access Markup Language (SAML) is an open standard that encodes text into machine language and enables the exchange of identification information. It has become one of the core standards for SSO and is used to help application providers ensure their authentication requests are appropriate. SAML 2.0 is specifically optimized for use in web applications, which enables information to be transmitted through a web browser
|Identity Provider & Protocol
|The Identity Provider is an endpoint with which the external applications will relate.
SAML, OAuth, WS-Fed [Web Services Federation Protocol], Open ID Connect, etc.
|Configured with the federated metadata. XML file exported from the identity provider SAML.
|NameID Value & Format
|What is the person identifier to be used for user authentication (unique application ID, email address, SAM Account name, other, or if a combination of identifiers used)
|NameID Value will be the user's email address, and the format unspecified.
|User information is required.
- These claims must be configured exactly as mentioned, respecting capital letters and word spacing.
- First Name
- Last Name
- Phone Number
Against a successful authentication, Authorization is the process by which a third party is granted permission to access information or perform an action associated with another entity. essDOCS handles the authorization by providing relevant details against the logged-in user to the consumer accordingly.
Authorization Management falls under two different types of applications, as below.
User role details exist with the application database, where the application administrator manages the entire authorization process.
User roles will be internally created and managed in Active Directory [AD]. These groups will be either synchronized to the application database or passed through as claims to allow access control within the application. In the case of the AD Managed approach, the application owner is responsible for requesting the local service desk to create an Active Directory Security Group and specifying the owner to approve subsequent membership of the required users. All future user creations shall go through a Service Desk request. SSO team will not be involved in this process.
|The authorization process depends on the selected approach i.e., Wholly Application Managed or the AD Managed.
|Based on the user details collected, the SSO configurations go accordingly.
SSO provisioning assigns permissions based on roles and event changes throughout an account’s lifecycle. Provisioning (and de-provisioning) grants, modifies, or revokes access and privileges based on triggers. User provisioning can be automated by integrating the user directory, Active Directory, and a connector tool, such as the open-standard System for Cross-domain Identity Management. Based on the requirement, four commonly used Provisioning are available to select from.
The application creates a user enters the instant a user logs into the system based on the information presented by Azure AD.
The application has a web API that supports SCIM (System for Cross-domain Identity Management) API pointing to https://tools.ietf.org/html/draft/ietf-scm-api-19 . Azure AD will automatically synchronize users into it and remove the users as required.
A script, tool, or process is created to remove them when they leave the organization.
Administrators manually create users in the application before they log in and remove them when they leave.
|The service owner is responsible for building processes by setting up the required provisioning out of the four described above.
|Based on the selected provisioning, the scope of provisioning is managed accordingly.
essDOCS support both Security Assertion Markup Language SAML and OpenID Connect OIDC based SSO implementations. Once initial details are exchanged between the client and essDOCS, the following details are required from the client
- Discovery URL
- Client ID
- Client Secret
These details are incorporated into the SSO configurations, and the Service Provider Sign-On URL is shared with the client that points to the client's authentication URL for SAML or OIDC-based SSO purposes as below.
Updated over 1 year ago