Single Sign-On (SSO) allows a user to access multiple services in a single session, without having to authenticate themselves repeatedly. UBIK^® can be integrated into an SSO environment.

SSO has additional benefits, other than "just" reusing a central account and session. It also makes sure that no application other than the identity provider (and the browser) ever gets to see the user's credentials, and two-factor-authentication (2FA) can be enforced.

Some organizations do this by restricting every HTTPS interaction in their network, making sure that all requests carry a session cookie known by the identity provider, or otherwise redirecting the request to the identity provider (via an application gateway, reverse proxy or load balancer).

This works out well for all web applications running in the user's browser. However, many applications do not run within the user's browser, like for example demon services, or native mobile applications. But such applications often still use HTTPS to interact with other services or even their own servers, just not using a browser. This is also true for UBIK^®.

So how can such browser-less interactions be secured with SSO? UBIK^® can be configured to require a valid SSO login via the user's web browser to create surrogate session tokens for the browser-less back channels. This renders interception by an application gateway not only useless, but also obstructive.

In other words, it is mandatory to exclude the UBIK^® web service URLs from 2FA rules on the application gateway, so UBIK^® can implement SSO securely without being a web application.

We've had the situation multiple times that customers or partners are worried that this is a breach of their cyber security protocols. This is not the case: We have ensured that UBIK^® can be configured to prevent ANY session that is not secured via the identity provider! The responsibility for securing the back channel has to be with UBIK^® though, otherwise it cannot work technically, because UBIK^® is not a web application where all communication runs via the browser.

We understand this is a complex topic. Please don't hesitate to approach our support if there are further questions!

SSO protocols supported by UBIK are:

• OpenID Connect (OIDC)
• Security Assertion Markup Language (SAML)

However, OIDC is the more modern protocol and better suited for mobile applications, and therefore recommended by us.

Login

One use-case is logging in to UBIK^® via SSO. Here, we can distinguish between authentication and authorization.

Authentication

Authentication is the process of verifying the user's identity, in the case of SSO using a central authority called the "Identity Provider" (IdP) or simply "Authority". In UBIK^®, this is implemented by opening a browser so the user can negotiate their login with the IdP, instead of using input fields for the credentials. The UBIK^® authentication web service never gets to see the user's credentials - instead, it just verifies the SSO token provided by the IdP and establishes an internal UBIK^® session based on this.

Authorization

Authorization is the process of allowing an action to be performed. In the case of SSO, an action is authorized based on the user's identity and rights attested by the Identity Provider. This means UBIK^® can be customized to assign groups and/or rights to a user based on the information received from the IdP, or even to grant or deny access completely.

Interfacing with SSO

Another use-case is interfacing, where UBIK^® interacts with a 3rd party system on the user's behalf. For authentication (and authorization), the user's SSO token is provided to the 3rd party system as credentials. Since a UBIK^® app synchronizes all content with the UBIK^® content web service, the latter takes care of the interaction with any 3rd party system. Thus, the app relays the user's SSO token via the content web service to perform an action at the 3rd party system, on the user's behalf.

1. The user logs in to the SSO environment at the Identity Provider, using their web browser. If the login was successful, the browser redirects the user back to the app.
2. Using a back channel without user interface, the app now fetches the actual SSO token from the Identity Provider.
3. In order to establish a UBIK session, the app presents the SSO token to the UBIK^® authentication web service (USAM). If the token is valid, a UBIK session is created and the app receives a UBIK session token.
4. In some cases, we want to send or receive data to/from 3rd party services. In this case, we send an SSO token to the UBIK^® content web service, together with our UBIK^® session token.
   1. The content web service checks whether the UBIK^® session is valid.
   2. The content web service processes the app's request, including an interaction with a 3rd party service. For authorization, it sends along the SSO token the app provided before.

The first two steps of the above algorithm explain the authorization code flow of OIDC. For SAML, the only real difference is the reception of the IdP's response at the app, which happens via a mediator server in that case, necessarily (the SAML protocol does not support redirecting the result to a mobile app).

• How to integrate UBIK^® in an SSO environment