Admin User Authentication with SSO (Single Sign On)

Ascenda integrates with your organizations' Administrative authentication providers using Single Sign-On (SSO) to provide a seamless authentication experience for end users. After end users sign in to your identity provider, they can access the Ascenda Admin Panel without reentering their credentials.

For your identity apps that support federated SSO through SAML, OIDC, or any other proprietary authentication protocol, Ascenda establishes a secure connection with a user's browser and then authenticates the user. With SSO, a central domain performs authentication and then shares the session with other domains. The way a session is shared may differ between the various SSO protocols, but the general concept is the same.

Managing Multiple SSO Integrations

You may be considering employing multiple login providers against the Ascenda platform. Typically this means a dedicated parameter indicating end user SSO login for either our Rewards Portal or Admin Platform is required.

Without doing that, any login attempt would result is Ascenda's Authentication Service rejecting the request without providing the target application and target login provider.

Ascenda can also integrate as a Service Provider using OAuth2.0 against your identity application, however we can only do this for 1 of the Rewards Portal or the Admin Platform unless a different identify provider is provided by you.

**Components of the System: **

• User: Requests service from our applications
• Ascenda Admin Platform: The admin website that your administrator visits
• Ascenda Auth Platform: The authentication platform within Ascenda that acts as a service provider to your identity and auth platform
• Your Auth Platform: Your authentication platform for the User that acts as the identity provider executing on the SSO login
• Client ID & Secret: A standard part of OAuth2.0 and OIDC enabled logins, this is the credentials that allows Ascenda to identify itself when executing on the SSO login with your Auth Platform
• Token (optional): Some protocols (like a SAML assertion) may involve identifying the User with the Ascenda Auth Platform. It contains authentication information, attributes, and authorization decision statements

You should reach out to your Customer Success manager for more details on integrating SSO between yours and the Ascenda platforms. You should provide Ascenda with the integration documents necessary for your SSO login provider.

Admin OIDC App Integration

📘

Reach out to your Customer Success manager with your Admin SSO identity provider workflow and documentation to get started here

Ascenda can integrate with OIDC applications by acting as an service provider that links your SSO to our applications. Ascenda also supports MFA prompts (primarily SMS or Emails) to improve your application security.

1. The user requests access to the Ascenda Admin Panel (we are your client application).
2. Ascenda redirects the user to your Identity Provider site to authenticate and establish the user session
3. The end-user logs in with your Identity Provider. Invalid logins should be mapped to a failure to login page on your App
4. Successfully logged in users are redirected back to Ascenda's site. Our application should receive a token from your Identity Provider to establish the user session.
   1. Separately (depending on whether you're employing OAuth 2.0 or OIDC), a token verification procedure is introduced in place for verifying the authenticity of the user attempting to access the Admin Panel.
   2. If the user grants access, your Identity Provider generates an ID token containing the user identity information that the Ascenda application can establish a working user session.
      1. Ascenda maps the admin user's roles and status against the enlisted access against Ascendas admin roles before generating the right permissions for your admin user's session
      2. For additional security, acting as the IdP, Ascenda can employ Multifactor Authentication (MFA). Ascenda verifies the user, and if successful, prompts the user to grant access to the portal before continuing with the session.
5. Ascenda returns the authenticated user to the Admin Panel application

Admin JWE Token Integration

📘

Reach out to your Customer Success manager with your SSO identity provider workflow and documentation to get started here

The token-based approach requires the native app to request, from the your identity provider backend or API gateway, a token that represents the user’s current session on the native app. The format of the token is mutually agreed between Ascenda and you (the client). Typically, it is a JSON message which is encrypted using a shared secret key. The contents of the JSON message vary depending on bank-specific implementation and depending on how the bank wishes to perform the token exchange and user info retrieval.

For example, if your API endpoints are protected as an OAUTH resource, the JSON message may contain the admin user’s OAUTH code to allow Ascenda to perform a token exchange operation. The access token is then used to retrieve the admin user’s profile.

The JSON message may contain attributes such as:

• uid (admin user ID assigned by your identity provider)
• timestamp (to prevent against replay attacks)
• authorization_code (optional)

The JWT standard allows us to send signed information in a JSON token. This is a standard as a mode of communicating information between systems.

If you would like to go with the token approach over an authorization code grant type, this indicates that admin user information is communicated directly over the user-agent in view of the customer.

To secure any user information from being publicly visible, the data will need to be encrypted. Ascenda then requires you to adopt the JOSE standard for sending such information.

Please do reach out to your Customer Success manager for more details around the integration process here.

Admin SAML App Integration

📘

Reach out to your Customer Success manager with your Admin SSO identity provider workflow and documentation to get started here

Security Assertion Markup Language (SAML) is an XML-based protocol used for Single Sign-On (SSO) and exchanging authentication and authorization data between applications. Within the SAML workflow, Ascenda acts as the Service Provider to integrate your end user experience to our .

1. The user opens Ascenda Admin Panel in a browser
2. Ascenda acts as the Service Provider and delegates the user authentication to your Identity Provider (IDP).
3. Your IDP authenticates the user.
4. Your IDP sends a SAML assertion back to Ascenda.
   1. Ascenda validates the SAML assertion against your IDP and, if necessary, enforces MFA.
   2. Ascenda maps the admin user's roles and status against the enlisted access against Ascendas admin roles before generating the right permissions for your admin user's session
5. Ascenda returns the authenticated user to the Admin Panel application