Single Sign-On (SSO)

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.

essDOCS SSO Workflow

The setup process will work as follows.

1. Upon request from Customers or Partners, essDOCS will provide all SSO configurations as needed by the Identity Providers.
2. The client configures the Identity Providers and provides the .xml federated metadata file.
3. essDOCS updates the metadata file.
4. SSO testing initiates.

📘

SSO Testing Environments

Each client will be provided a seperate UAT & Production configurations.

Setting up SAMP IDP (Provided by essDOCS)

Three elemental properties must be configured per the settings provided by essDOCS.

Aspect	Background Information	Requirement/Scope/Setting
Entity ID	SSO Service provider identifier	urn:amazon:cognito:sp:eu-west-1_69KUpZjtY
Reply URL	The Reply URL is where the application expects to receive the authentication token. This is also referred to as "Assertion Consumer Service" within SML.	https://cargodocs-test.auth.eu-west-1.amazoncognito.com/saml2/idpresponse
Sign On URL	URL where the whole sign-in process starts.	https://cargodocs-test.auth.eu-west-1.amazoncognito.com/login?client_id=2mf01ff44fdstrrvePoK&response_type=code&scope=email+phone+profile&redirect_uri=https://test.essdatabridge.com/sso/saml/6352fcf2-ff86-4a15-84a4-2790c34aaaa7

Migration Plan

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.

Aspect	Background Information	Requirement/Scope/Setting
Greenfields	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.
Big Bang	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.
Phased/Graded Rollout	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.

essDOCS SSO Authentication

SSO Authentication deals with validating user credentials and establishing the identity of the user who is gaining access to the essDOCS platform.

📘

SAML

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

Aspect	Background Information	Requirement/Scope/Setting
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.
Claims/Permission Required*	User information is required. - These claims must be configured exactly as mentioned, respecting capital letters and word spacing.	- Email - First Name - Last Name - Phone Number

essDOCS SSO Authorization

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.

Wholly Application Managed

User role details exist with the application database, where the application administrator manages the entire authorization process.

AD Managed

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.

Aspect	Background Information	Requirement/Scope/Setting
Authorization Management	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

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.

Just-in-Time Provisioning

The application creates a user enters the instant a user logs into the system based on the information presented by Azure AD.

Automatic Provisioning

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.

Custom Provisioning

A script, tool, or process is created to remove them when they leave the organization.

Manual Provisioning

Administrators manually create users in the application before they log in and remove them when they leave.

Aspect	Background Information	Requirement/Scope/Setting
Provisioning	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 SSO Implementation

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.

HTTP

https://test-essdatabridge-com.auth.eu-west-1.amazoncognito.com/login?client_id=4tvd6ur1105h8lgkpl9rmfqhu1&response_type=code&scope=email+openid+phone+profile&redirect_uri=https://test.essdatabridge.com/sso/saml/a2ad8037-8242-49a7-82cb-a2e1fdea9048