m (→Interfacing) |
(→Important information) |
||
| (12 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
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. | 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: Reverse Proxies = | ||
| + | |||
| + | Single Sign-On (SSO) offers benefits beyond reusing a central account, such as ensuring only the identity provider and browser see user credentials, enforcing two-factor authentication (2FA), and shielding intranet servers via reverse proxy checking for valid SSO sessions. Organizations often secure HTTPS interactions by ensuring requests carry a session cookie or bearer token from the identity provider, otherwise redirecting requests to the identity provider. | ||
| + | |||
| + | {{UBIK}} supports this, too, by providing the SSO bearer token within the "Authorization" header for every request. A reverse proxy can verify this token or prevent access otherwise. Unfortunately, Microsoft Entry Application Proxy - even with the helpful-sounding "header-based SSO" configuration - is unable to just check this header without dropping the data when forwarding the incoming message to {{UBIK}}. Hence, with the Microsoft Entra Application Proxy the only way is to deactivate the check. Also, any method checking the session cookie is doomed to fail because for the backchannel, {{UBIK}} doesn't have any access to the browser's cookies, just to the SSO token. | ||
| + | |||
| + | {{Hint|With Microsoft Entra Application Proxy, it is necessary to exclude {{UBIK}} web service URLs from the 2FA redirect rules!}} | ||
| + | |||
| + | If there are further questions, support is available to help. | ||
| + | |||
| + | [[Category:Mobile|Single Sign-On]] | ||
| + | [[Category:SSO|Single Sign-On]] | ||
| + | |||
= Protocols = | = Protocols = | ||
SSO protocols supported by UBIK are: | SSO protocols supported by UBIK are: | ||
| Line 16: | Line 30: | ||
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. | 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 == | + | == 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. | 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) = | = Architecture and flow (OIDC) = | ||
| Line 39: | Line 53: | ||
! style="width:60%" | Clients | ! style="width:60%" | Clients | ||
!! style="width:40%" | Available since | !! style="width:40%" | Available since | ||
| + | |- | ||
| + | | Mobile (Maui) | ||
| + | || [[Version_5.0_(Mobile)]] | ||
|- | |- | ||
| Xamarin.Android | | Xamarin.Android | ||
| Line 50: | Line 67: | ||
|- | |- | ||
| WebClient | | WebClient | ||
| − | || 4. | + | || Version 4.2 Web Client |
|} | |} | ||
| + | |||
| + | {{Attention|Android caches some information about the app regarding the so-called universal link which is needed in the SSO process. If you already have a {{UBIK}} client on an Android device and install another {{UBIK}} client, the SSO process might not work since the cached information is for the old app. So it's advised to uninstall the old app before installing the new one. | ||
| + | * Just to be clear, this is about installing a brand new app, e.g migrating from the Xamarin app to the MAUI app. | ||
| + | * Simply updating a Xamarin app or a MAUI app to their respective newer versions will NOT have this problem.}} | ||
| + | |||
| + | |||
| + | |||
| + | |||
= See also = | = See also = | ||
* [[HowTo:Integrate_UBIK_in_an_SSO_Environment|How to integrate {{UBIK}} in an SSO environment]] | * [[HowTo:Integrate_UBIK_in_an_SSO_Environment|How to integrate {{UBIK}} in an SSO environment]] | ||
| + | [[Category:Mobile|Single Sign-On]] | ||
[[Category:SSO|Single Sign-On]] | [[Category:SSO|Single Sign-On]] | ||
Latest revision as of 15:00, 2 April 2026
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: Reverse Proxies
Single Sign-On (SSO) offers benefits beyond reusing a central account, such as ensuring only the identity provider and browser see user credentials, enforcing two-factor authentication (2FA), and shielding intranet servers via reverse proxy checking for valid SSO sessions. Organizations often secure HTTPS interactions by ensuring requests carry a session cookie or bearer token from the identity provider, otherwise redirecting requests to the identity provider.
UBIK® supports this, too, by providing the SSO bearer token within the "Authorization" header for every request. A reverse proxy can verify this token or prevent access otherwise. Unfortunately, Microsoft Entry Application Proxy - even with the helpful-sounding "header-based SSO" configuration - is unable to just check this header without dropping the data when forwarding the incoming message to UBIK®. Hence, with the Microsoft Entra Application Proxy the only way is to deactivate the check. Also, any method checking the session cookie is doomed to fail because for the backchannel, UBIK® doesn't have any access to the browser's cookies, just to the SSO token.
 | With Microsoft Entra Application Proxy, it is necessary to exclude UBIK® web service URLs from the 2FA redirect rules! |
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.
- The content web service checks whether the UBIK® session is valid.
- 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 |
|---|---|
| Mobile (Maui) | Version 5.0 (Mobile) |
| Xamarin.Android | Version 4.6 Xamarin |
| Xamarin.iOS | Version 4.8 Xamarin |
| WinX | Version 4.6 (WinX) |
| WebClient | Version 4.2 Web Client |
 | Android caches some information about the app regarding the so-called universal link which is needed in the SSO process. If you already have a UBIK® client on an Android device and install another UBIK® client, the SSO process might not work since the cached information is for the old app. So it's advised to uninstall the old app before installing the new one.
|