User Authentication Federation

To allow your organization users (with the same domain name that is already reserved by your organization account) and trading partners to access the Smart Trading Cloud services without having to create a Smart Trading account, you can federate the Authorization service (Account Service) for Smart Trading Cloud services, for example, Onboarding and Testing Cloud Service, with your organization and trading partner identity providers. Smart Trading Cloud supports:

  • The Security Assertion Markup Language (SAML) 2.0 protocol: a commonly used standardized way to tell web applications and services that a user is who he or she claims to be. SAML makes the single sign-on (SSO) scheme possible by providing a way to authenticate a user only once and then delivering that authentication to multiple applications.
  • OpenID Connect (OIDC) federated protocol: a federated protocol that provides an identity layer built on the top of the OAuth 2.0 protocol. The OpenID Connect protocol enables third-party applications to verify the end-user identity based on the authentication that is performed by the authorization server. OAuth 2.0 provides authorization, while OIDC Federation is required for authentication.

At a high level, the authentication flow with SAML federation enabled within your organization looks as follows:

  1. A payer user goes to any Smart Trading Cloud service, for example, Onboarding and Testing Cloud Service, using a web browser. The payer user is redirected to the Smart Trading Cloud service sign-in screen where he/she is prompted to enter his/her email address.
  2. The Authorization service (Account Service) checks to see if the domain name of the payer user's email address has SAML federation enabled. If yes, the Authorization service sends a SAML request to the browser which redirects the payer user to the sign-in screen of your identity provider.
  3. The identity provider authenticates this payer user against your organization's identity store and generates a SAML assertion that includes information about the authenticated user in the form of attributes.
  4. The assertion is sent to the browser that then passes this assertion to the Authorization service (Account Service).
  5. The Authorization service validates assertions' correctness, retrieves the required user attributes, and gives the payer user access to Onboarding and Testing Cloud Service.
  6. After successful authentication, the payer user is logged in to Onboarding and Testing Cloud Service.

When authentication through the identity provider for your trading partners is set up, at a high level, the workflow looks as follows:

Note When you configure your trading partner identity provider, all your partners should sign in to a Smart Trading Cloud service only through the identity provider(s). If you do not configure your trading partner identity provider, all your partners should sign in using a Smart Trading account.

  1. A partner user goes to an identity provider selection screen using the link you provided.
  2. The partner user selects a required identity provider through which they will sign in to a Smart Trading Cloud service.
  3. The identity provider prompts the partner user for their credentials.
  4. If the partner user submits valid credentials, they get authenticated by the identity provider.
  5. The identity provider returns the successful authentication in the form of a SAML response to the Authorization service (Account Service).
  6. Smart Trading Cloud passes the SAML assertions to a Smart Trading Cloud service, for example, Onboarding and Testing Cloud Service to which the partner user signs in.
  7. Onboarding and Testing Cloud Service verifies that the username in the SAML response matches a licensed partner user and logs in the partner user.