HowTo:Integrate UBIK in an SSO Environment - Revision history

NWE at 15:02, 2 April 2026

2026-04-02T15:02:03Z

NWE: /* Important information */

2026-04-02T15:01:39Z

‎Important information

NWE: Undo revision 28946 by NWE (talk)

2025-10-06T14:18:26Z

Undo revision 28946 by NWE (talk)

NWE at 12:58, 2 October 2025

2025-10-02T12:58:52Z

CWI at 15:48, 25 September 2025

2025-09-25T15:48:55Z

CWI: /* OIDC */

2025-09-22T11:26:07Z

‎OIDC

LGE at 12:56, 17 January 2025

2025-01-17T12:56:36Z

NWE: /* Important information */

2024-10-09T07:33:44Z

‎Important information

NWE: /* Important information */

2024-10-09T07:28:59Z

‎Important information

NWE: /* OIDC */

2024-10-09T06:54:36Z

‎OIDC

@@ Line 7: / Line 7: @@
 = Instructions =
-= Important information: Reverse Proxies =
+== 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, 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.
@@ Line 16: / Line 16: @@
 If there are further questions, support is available to help.
 == Login ==

@@ Line 7: / Line 7: @@
 = Instructions =
-== 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:Client|Integrate UBIK in an SSO Environment]]
+[[Category:How-To|Integrate UBIK in an SSO Environment]]
+[[Category:Mobile|Integrate UBIK in an SSO Environment]]
 == Login ==

← Older revision		Revision as of 14:18, 6 October 2025
Line 6:		Line 6:

	= Instructions =		= Instructions =
		+
		+	== 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.
		+
		+
		+
		+

	== Login ==		== Login ==

@@ Line 6: / Line 6: @@
 = Instructions =
 == Login ==
@@ Line 272: / Line 257: @@
 * [[SYSCLS_EXTERNALENTITY|External Entity Classification (SSO)]]
 [[Category:How-To|Integrate UBIK in an SSO Environment]]
 [[Category:SSO|Integrate UBIK in an SSO Environment]]
 [[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
 [[Category:WinX|Integrate UBIK in an SSO Environment]]

@@ Line 234: / Line 234: @@
 {{Hint|Entra requires a client secret for web applications (to be configured both in Entra as well as in the client profile's OIDC settings described above). For native/mobile applications, the client secret must be null though!}}
-[[Category:How-To|Integrate UBIK in an SSO Environment]]
-[[Category:SSO|Integrate UBIK in an SSO Environment]]
-[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
 == SAML ==
@@ Line 275: / Line 275: @@
 [[Category:SSO|Integrate UBIK in an SSO Environment]]
 [[Category:Version 3.6|Integrate UBIK in an SSO Environment]]

@@ Line 217: / Line 217: @@
 </syntaxhighlight>
-{{Attention|The "RedirectURL" is needed so that the SSO login process can be redirected back to the client after authentication. When using the Xamarin clients, the custom protocol ("com.augmensys.ubik://sso/") might trigger a trust warning from some SSO providers (e.g. Entra), asking users to additionally confirm the login. If you want to avoid such warnings, it's possible to configure the so called "universal link" ("https://ubikapp.augmensys.com/sso/") as the RedirectURL instead. {{Version/XamarinSince|4.9}} This is not the case for the UWP client because there's no such trust warning problem and universal link is not properly supported on Windows anyway.}}
+{{Attention|The "RedirectURL" is needed so that the SSO login process can be redirected back to the client after authentication. When using the Mobile clients, the custom protocol ("com.augmensys.ubik://sso/") might trigger a trust warning from some SSO providers (e.g. Entra), asking users to additionally confirm the login. If you want to avoid such warnings, it's possible to configure the so called "universal link" ("https://ubikapp.augmensys.com/sso/") as the RedirectURL instead. {{Version/XamarinSince|4.9}} This is not the case for the UWP client because there's no such trust warning problem and universal link is not properly supported on Windows anyway.}}
-{{Hint|When using the universal link as the RedirectURL, the Xamarin iOS client needs to open the Safari browser in order to successfully complete the login process. If you see the browser stuck on the {{UBIK}} SSO page and that it does not redirect to the client, please set Safari as the default browser. And the Xamarin iOS client opens the Safari browser externally, because we found out that the redirect process requires user interaction even when the user has already previously logged in. (This is in line with what many others also experienced, like described in [https://stackoverflow.com/questions/44706216/universal-link-does-not-work-in-safari this example].) This means there will be a browser instance open in the background after you log in/out using SSO on a Xamarin iOS client, which is unfortunately a technical limitation until Apple changes their universal link support.}}
+{{Hint|When using the universal link as the RedirectURL, the Mobile iOS client needs to open the Safari browser in order to successfully complete the login process. If you see the browser stuck on the {{UBIK}} SSO page and that it does not redirect to the client, please set Safari as the default browser. And the Mobile iOS client opens the Safari browser externally, because we found out that the redirect process requires user interaction even when the user has already previously logged in. (This is in line with what many others also experienced, like described in [https://stackoverflow.com/questions/44706216/universal-link-does-not-work-in-safari this example].) This means there will be a browser instance open in the background after you log in/out using SSO on a Mobile iOS client, which is unfortunately a technical limitation until Apple changes their universal link support.}}
 * Integrate client configuration in profile:
@@ Line 234: / Line 234: @@
 {{Hint|Entra requires a client secret for web applications (to be configured both in Entra as well as in the client profile's OIDC settings described above). For native/mobile applications, the client secret must be null though!}}
+[[Category:How-To|Integrate UBIK in an SSO Environment]]
+[[Category:SSO|Integrate UBIK in an SSO Environment]]
+[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
 == SAML ==

← Older revision		Revision as of 07:33, 9 October 2024
Line 11:		Line 11:

	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.		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.		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.