Jump to: navigation, search

Changes


HowTo:Integrate UBIK in an SSO Environment

749 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 Concerns about breaching cybersecurity protocols are unfounded, as UBIK® ensures all web applications running in sessions are secured via the user's browseridentity provider. However, many applications do not run within The responsibility for securing the user's browser, like for example demon services, or native mobile applications. But such applications often still use HTTPS to interact back channel lies with other services or even their own serversUBIK®, just as it is 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 wordsIf there are further questions, it support is mandatory available to exclude the {{UBIK}} web service URLs from 2FA rules on the application gateway, so {{UBIK}} can implement SSO securely without being a web applicationhelp.'''
We've had the situation multiple times that customers or partners are worried that this is a breach of their cyber security protocols.[[Category:How-To|Integrate UBIK in an SSO Environment]]This is not the case[[Category: We have ensured that {{SSO|Integrate 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. in an SSO Environment]] We understand this is a complex topic[[Category:Version 3. Please don't hesitate to approach our support if there are further questions!6|Integrate UBIK in an SSO Environment]]
== Login ==
1,606
edits