Single Sign-On - Revision history

NWE: /* Important information */

2026-04-02T15:00:49Z

‎Important information

NWE: Undo revision 28945 by NWE (talk)

2025-10-06T14:18:07Z

Undo revision 28945 by NWE (talk)

NWE at 12:58, 2 October 2025

2025-10-02T12:58:23Z

CWI: /* Availability */

2025-09-25T15:20:36Z

‎Availability

CWI: /* Availability */

2025-09-24T12:45:47Z

‎Availability

CWI at 12:43, 24 September 2025

2025-09-24T12:43:52Z

LGE: /* Availability */

2025-07-16T11:31:00Z

‎Availability

NWE: /* Important information */

2024-10-09T07:34:05Z

‎Important information

NWE at 15:14, 4 October 2024

2024-10-04T15:14:35Z

NWE at 15:12, 4 October 2024

2024-10-04T15:12:03Z

@@ 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.
-= Important information =
+= Important information: Reverse Proxies =
-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.
+Single Sign-On (SSO) offers benefits beyond reusing a central account, such as ensuring only the identity provider and browser see user credentials, enforcing two-factor authentication (2FA), and shielding intranet servers via reverse proxy checking for valid SSO sessions. Organizations often secure HTTPS interactions by ensuring requests carry a session cookie or bearer token from the identity provider, otherwise redirecting requests to the identity provider.
-{{Hint|It is necessary to exclude {{UBIK}} web service URLs from any application gateway's 2FA redirect rules!}}
+{{UBIK}} supports this, too, by providing the SSO bearer token within the "Authorization" header for every request. A reverse proxy can verify this token or prevent access otherwise. Unfortunately, Microsoft Entry Application Proxy - even with the helpful-sounding "header-based SSO" configuration - is unable to just check this header without dropping the data when forwarding the incoming message to {{UBIK}}. Hence, with the Microsoft Entra Application Proxy the only way is to deactivate the check. Also, any method checking the session cookie is doomed to fail because for the backchannel, {{UBIK}} doesn't have any access to the browser's cookies, just to the SSO token.
-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.
+{{Hint|With Microsoft Entra Application Proxy, it is necessary to exclude {{UBIK}} web service URLs from the 2FA redirect rules!}}
 If there are further questions, support is available to help.
+[[Category:Mobile|Single Sign-On]]
 = Protocols =

← Older revision		Revision as of 14:18, 6 October 2025
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.
		+
		+

	= Protocols =		= Protocols =

@@ 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.
 = Protocols =
@@ Line 74: / Line 61: @@
 * Simply updating a Xamarin app or a MAUI app to their respective newer versions will NOT have this problem.}}
-[[Category:Mobile|Single Sign-On]]
-[[Category:SSO|Single Sign-On]]
 = See also =
 * [[HowTo:Integrate_UBIK_in_an_SSO_Environment|How to integrate {{UBIK}} in an SSO environment]]
 [[Category:Mobile|Single Sign-On]]

@@ Line 55: / Line 55: @@
 |-
 | Mobile (Maui)
-|| [[Version_5.1_(Mobile)]]
+|| [[Version_5.0_(Mobile)]]
 |-
 | Xamarin.Android

@@ Line 53: / Line 53: @@
 ! style="width:60%" | Clients
 !! style="width:40%" | Available since
 |-
 | Xamarin.Android
@@ Line 71: / Line 74: @@
 * Simply updating a Xamarin app or a MAUI app to their respective newer versions will NOT have this problem.}}
+[[Category:Mobile|Single Sign-On]]
 = See also =

← Older revision		Revision as of 11:31, 16 July 2025
Line 67:		Line 67:
	\|}		\|}

		+	{{Attention\|Android caches some information about the app regarding the so-called universal link which is needed in the SSO process. If you already have a {{UBIK}} client on an Android device and install another {{UBIK}} client, the SSO process might not work since the cached information is for the old app. So it's advised to uninstall the old app before installing the new one.
		+	* Just to be clear, this is about installing a brand new app, e.g migrating from the Xamarin app to the MAUI app.
		+	* Simply updating a Xamarin app or a MAUI app to their respective newer versions will NOT have this problem.}}

		+	[[Category:SSO\|Single Sign-On]]

	= See also =		= See also =

@@ Line 2: / Line 2: @@
 = 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.
+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.
-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), so the user can login right away with their browser.
+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.
-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}}.
+{{Hint|It is necessary to exclude {{UBIK}} web service URLs from any application gateway's 2FA redirect rules!}}
-−
-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.'''
+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.
-We've had the situation multiple times that customers or partners are worried that this is a breach of their cyber security protocols.
+If there are further questions, support is available to help.
-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!
+[[Category:SSO|Single Sign-On]]
 = Protocols =