Changes

Single Sign-On

2,007 bytes added, 4 October
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 =
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!
 
= Protocols =
SSO protocols supported by UBIK are:
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.
[[Category:SSO|Single Sign-On]]
= Architecture and flow (OIDC) =
|}
[[Category:SSO|Single Sign-On]]
= See also =
1,606
edits