Jump to: navigation, search

Difference between revisions of "HowTo:Integrate UBIK in an SSO Environment"


(See also)
Line 30: Line 30:
 
Further, we have to make sure the authorization tokens can be transported to the server. Therefore, add the [[SYSCLS_EXTERNALENTITY|External Entity Classification]] to all meta classes of objects that need external authorization.
 
Further, we have to make sure the authorization tokens can be transported to the server. Therefore, add the [[SYSCLS_EXTERNALENTITY|External Entity Classification]] to all meta classes of objects that need external authorization.
  
[[Category:How-To|Integrate UBIK in an SSO Environment]]
+
 
[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
+
 
  
 
= Studio =
 
= Studio =
Line 74: Line 74:
 
An external auth config object specifies for which meta class and sync action (e.g., when uploading instruction documents), which SSO configuration should be used. The result of a correct configuration will be, that the client sends an SSO token to the server when performing the sync action for an instance of the meta class. On the server side, you can use that token to interact with the external system. This only works if there is a scope with the external entity classification for that meta class, because it provides the means to transport the token.
 
An external auth config object specifies for which meta class and sync action (e.g., when uploading instruction documents), which SSO configuration should be used. The result of a correct configuration will be, that the client sends an SSO token to the server when performing the sync action for an instance of the meta class. On the server side, you can use that token to interact with the external system. This only works if there is a scope with the external entity classification for that meta class, because it provides the means to transport the token.
  
[[Category:How-To|Integrate UBIK in an SSO Environment]]
+
 
[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
+
 
  
 
= Client =
 
= Client =
Line 103: Line 103:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
[[Category:How-To|Integrate UBIK in an SSO Environment]]
+
 
[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
+
 
  
 
== SAML ==
 
== SAML ==
Line 143: Line 143:
 
[[Category:How-To|Integrate UBIK in an SSO Environment]]
 
[[Category:How-To|Integrate UBIK in an SSO Environment]]
 
[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
 
[[Category:Version 3.6|Integrate UBIK in an SSO Environment]]
 +
[[Category:SSO|Integrate UBIK in an SSO Environment]]

Revision as of 16:33, 21 November 2023

Single Sign On (SSO) allows an end-user to interact with multiple services without logging in more than once.

This page shows how to integrate UBIK® into such an SSO environment.


[edit]

Instructions

The customer's Identity Provider must know UBIK® as a Service Provider. In case of SAML, we need to provide an SSO mediator server in order to relay SAML responses for the client; this is our ACS (Assertion Consumer Service). In case of OIDC, the client app interacts with the OIDC provider directly.

There are two major use-cases for SSO:

  • Authentication: Establishing or re-using an SSO session with an external authority (logging in)
  • Authorization: Interaction with external systems (interfacing)

In order to configure UBIK® for SSO integration, we need to address both.

Authentication

  • In the UBIK® client profile, adjust the SSO relevant settings (enabling SSO and specifying the Identity Provider Endpoint URL for an IdP-initiated flow).
  • On the server side, make sure that an SSO Processor is configured able to process the responses from the Identity Provider.

Authorization

When a UBIK® object is synchronized between client and server, the UBIK® customizing can interact with external systems. There, we might require authorization, and we need to make sure the client provides a respective token. In order to do so, we have to identify the specific authorization use-cases:

  • For which types of objects (meta classes) do I need to interact with external systems, requiring SSO authorization?
  • For which synchronization operations (e.g., update, commit, create, etc.) do I need authorization?
  • Which SSO client configurations (identity provider base URL, scopes, etc.) are used in this case?

For each resulting combination we have to create an External Auth Config object and give it to the client in the infrastructure list.

Further, we have to make sure the authorization tokens can be transported to the server. Therefore, add the External Entity Classification to all meta classes of objects that need external authorization.



See also