Jump to: navigation, search

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


(Authorization)
Line 7: Line 7:
 
= Instructions =
 
= Instructions =
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
 +
 +
The customer's Identity Provider must know {{{UBIK}}} as a Service Provider. We need to provide an SSO mediator server in order to relay SSO responses for the client; this is our ACS (Assertion Consumer Service).
  
 
There are two major use-cases for SSO:
 
There are two major use-cases for SSO:
Line 19: Line 21:
  
 
== Authorization ==
 
== 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:
+
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 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?
 
* For which synchronization operations (e.g., update, commit, create, etc.) do I need authorization?
Line 25: Line 27:
 
For each resulting combination we have to create an [[SYSCLS_EXTERNALAUTHCONFIG|External Auth Config]] object and give it to the client in the infrastructure list.
 
For each resulting combination we have to create an [[SYSCLS_EXTERNALAUTHCONFIG|External Auth Config]] object and give it to the client in the infrastructure list.
  
[[Category:How-To|Integrate UBIK in an SSO Environment]]
+
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.
  
 
= Studio =
 
= Studio =
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
<Give step-by-step instructions, use images, ...>
+
* Add [[SYSCLS_EXTERNALAUTHCONFIG|External Auth Config]] objects to the client's infrastructure
 
+
* Add the [[SYSCLS_EXTERNALENTITY|External Entity Classification]] to all affected meta classes
TBD
+
  
 
= Client =
 
= Client =
Line 37: Line 38:
 
<Give step-by-step instructions, use images, ...>
 
<Give step-by-step instructions, use images, ...>
  
TBD
+
* Set up an SSO mediator backend server to relay SSO responses to the client
 +
* Configure the SSO profile settings respectively
  
 
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/End}}<!-- DO NOT REMOVE THIS -->
 
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/End}}<!-- DO NOT REMOVE THIS -->
Line 43: Line 45:
 
==See also==
 
==See also==
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
 
<!-- DO NOT MODIFY THE NAME OF THIS SECTION, BUT REMOVE IT IF NOT REQUIRED -->
 
+
* [[SYSCLS_EXTERNALAUTHCONFIG|External Auth Config Classification (SSO)]]
[[Category:How-To]]
+
* [[SYSCLS_EXTERNALENTITY|External Entity Classification (SSO)]]
  
 
[[Category:How-To|Integrate UBIK in an SSO Environment]]
 
[[Category:How-To|Integrate UBIK in an SSO Environment]]

Revision as of 11:59, 13 July 2021

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. We need to provide an SSO mediator server in order to relay SSO responses for the client; this is our ACS (Assertion Consumer Service).

There are two major use-cases for SSO:

  • Authentication: Establishing or re-using an SSO session (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 IdP endpoint is 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.

Studio

Client

<Give step-by-step instructions, use images, ...>

  • Set up an SSO mediator backend server to relay SSO responses to the client
  • Configure the SSO profile settings respectively


See also