Changes
<!-- 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:
* 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?
