Difference between revisions of "Single Sign-On"
(→Important information) |
|||
| (13 intermediate revisions by 2 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 = | ||
| + | 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. | ||
| + | |||
| + | {{Hint|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. | ||
| + | |||
| + | [[Category:SSO|Single Sign-On]] | ||
| + | |||
= Protocols = | = Protocols = | ||
SSO protocols supported by UBIK are: | SSO protocols supported by UBIK are: | ||
| Line 5: | Line 19: | ||
* Security Assertion Markup Language (SAML) | * Security Assertion Markup Language (SAML) | ||
However, OIDC is the more modern protocol and better suited for mobile applications, and therefore recommended by us. | However, OIDC is the more modern protocol and better suited for mobile applications, and therefore recommended by us. | ||
| − | = Use Cases = | + | = Use-Cases = |
| − | == Authentication == | + | == Login == |
| − | Authentication is the process of verifying the user's identity, in the case of SSO using a central authority called the "Identity Provider" (IdP). | + | 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. | 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. | + | === 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) = | = Architecture and flow (OIDC) = | ||
[[Image:UBIK SSO Architecture.png|thumb]] | [[Image:UBIK SSO Architecture.png|thumb]] | ||
| Line 20: | Line 43: | ||
## The content web service checks whether the {{UBIK}} session is valid. | ## 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 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 = | ||
| + | {| class="wikitable" style="text-align: center; width: 30%" | ||
| + | |- | ||
| + | ! style="width:60%" | Clients | ||
| + | !! style="width:40%" | 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 | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
= 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:SSO|Single Sign-On]] | [[Category:SSO|Single Sign-On]] | ||
Latest revision as of 07:34, 9 October 2024
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.
Contents
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.
- 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 |
|---|---|
| Xamarin.Android | Version 4.6 Xamarin |
| Xamarin.iOS | Version 4.8 Xamarin |
| WinX | Version 4.6 (WinX) |
| WebClient | Version 4.2 Web Client |
