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.

Important information

Single Sign-On (SSO) offers benefits beyond reusing a central account, such as ensuring only the identity provider and browser see user credentials, and enforcing two-factor authentication (2FA). Organizations often secure HTTPS interactions by ensuring requests carry a session cookie from the identity provider or redirecting requests to the identity provider.

While this works for web applications in browsers, it poses challenges for non-browser applications like daemon services or mobile apps. UBIK® addresses this by requiring a valid SSO login via a web browser to create session tokens for its own back channels, making interception by an application gateway not only ineffective but also problematic, as it prevents UBIK® from functioning. Therefore, UBIK® web service URLs must be excluded from 2FA rules on the application gateway to implement SSO securely.

It is necessary to exclude UBIK^® web service URLs from any application gateway's 2FA redirect rules!

Concerns about breaching cybersecurity protocols are unfounded, as UBIK® ensures all sessions are secured via the identity provider. The responsibility for securing the back channel lies with UBIK®, as it is not a web application.

If there are further questions, support is available to help.

Protocols

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.

Use-Cases

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.

Architecture and flow (OIDC)

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.
Using a back channel without user interface, the app now fetches the actual SSO token from the Identity Provider.
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.
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).

Availability

Clients	Available since
Xamarin.Android	Version 4.6 Xamarin
Xamarin.iOS	Version 4.8 Xamarin
WinX	Version 4.6 (WinX)
WebClient	Version 4.2 Web Client

Single Sign-On

Contents