Difference between revisions of "Single Sign-On"
m (→Architecture and flow (OIDC)) |
m (→Architecture and flow (OIDC)) |
||
| Line 21: | Line 21: | ||
## 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 above | + | |
| + | The above algorithm explains the authorization code flow using OIDC, applied to {{UBIK}}. 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). | ||
[[Category:SSO|Single Sign-On]] | [[Category:SSO|Single Sign-On]] | ||
Revision as of 20:19, 21 November 2023
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
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
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). 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. In UBIK®, a user can have their interaction with a 3rd party system authorized by passing their SSO token to said 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 in the 3rd party system, on the user's behalf. But we can also use the claims stated in the SSO token to evaluate the user's rights within UBIK® itself, without any 3rd party system involved, if required.
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 above algorithm explains the authorization code flow using OIDC, applied to UBIK®. 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).
