Jump to: navigation, search

Changes


Single Sign-On

775 bytes removed, 9 October
/* Important information */
= Important information =
Single Sign-On (SSO has additional ) offers benefits, other than "just" beyond reusing a central account and session. It also makes sure that no application other than , such as ensuring only the identity provider (and the browser) ever gets to see the user's credentials, and enforcing two-factor-authentication (2FA) can be enforced. Organizations often secure HTTPS interactions by ensuring requests carry a session cookie from the identity provider or redirecting requests to the identity provider.
Some organizations do While this by restricting every HTTPS interaction works for web applications in their networkbrowsers, making sure that all requests carry 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 cookie known by the identity providertokens for its own back channels, or otherwise redirecting the request to the identity provider (via making interception by an application gatewaynot only ineffective but also problematic, reverse proxy or load balancer)as it prevents UBIK® from functioning. Therefore, so UBIK® web service URLs must be excluded from 2FA rules on the user can login right away with their browserapplication gateway to implement SSO securely.
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? Hint|It is necessary to exclude {{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 service URLs from any application gateway not only useless, but also obstructive.'s 2FA redirect rules!}}
'''In other wordsConcerns about breaching cybersecurity protocols are unfounded, it is mandatory to exclude as UBIK® ensures all sessions are secured via the {{UBIK}} web service URLs from 2FA rules on identity provider. The responsibility for securing the application gatewayback channel lies with UBIK®, so {{UBIK}} can implement SSO securely without being as it is not a web application.'''
We've had the situation multiple times that customers or partners If there are worried that this further questions, support is a breach of their cyber security protocols.This is not the case: We have ensured that {{UBIK}} can be configured available 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 browserhelp.
We understand this is a complex topic. Please don't hesitate to approach our support if there are further questions![[Category:SSO|Single Sign-On]]
= Protocols =
1,606
edits