If you wish, you can set up the same translate5 instance on different domains and configure for different clients different domains and different OpenID servers.
| Table of Contents |
|---|
Use different IPDs with the same translate5 / Mapping of client via domain
...
This way it is possible to use different OpenID IPDs with different clients in the same translate5 instance.
Alternatively, you can use one OpenID IDP and map users to different clients via a custom field of your IDP.
Examples how to use translate5 as OpenID client with different OpenID servers for Single-Sign-On (SSO) usage
...
For more information on how the translate5 domain is used and why it is important, please see above.
All other fields exist in the OpenId tab of the edited client)
...
Create and map a translate5 client to a client on IDP side via custom claims
By default The to what a client a user belongs to, that authenticates via SSO is defined by the URL he/she uses to access translate5.
Yet, you can also configure one OpenID IDP together with translate5, so that one IDP can authenticate users for different clients within translate5.
To do this:
- Go to the system configuration and look up the field `runtimeOptions.customers.openid.claimsFieldName`
...
- . Set it to the name of the attribute in your IDP, that contains the client number in the OpenID token claims. How translate5 will handle values in this config:
- no value: the currently authenticated user will
...
- be
...
- mapped to the
...
- client in translate5 via URL (see above)
- defined value: translate5 will check if there
...
- exists an attribute in the OpenId token claims with this value. In case there is value, translate5 will try to find
...
- a client with the number
...
- in the token claims value.
- If there is
- in the token claims value.
...
- a client with this number, this
...
- client will be used for the current user.
- If no
...
- client is found, a new
...
- client will be created with number and name as the value provided in the claims