The Proxy type of Service Provider is used for locally defined service provider endpoints. Eg. when a Service Provider does not support SAML, OAuth, OpenIDConnect, WS Federation or other IDHub-supported protocols.
IDHub will act as an intermediary between user, IDP and SP, as demonstrated in the diagram below.
|Display Name||User defined name of the Service Provider
|Description||User defined description of the Service Provider
|Authentication Scheme||Defines which IDP(s) that can authenticate this user.|
|Location||URL Path (after the hostname) that indicates where the Service Provider is located.|
|Hostname||Hostname of the server (if another server than the Admin Portal Server is used). Subdomain and domainname.
If not provided, this server hostname is used.
Enabling this, sets flag in SAML and OAuth Authentication Requests that the user must authenticate again.
|Enforce Consent||Enabling this checkbox will check if the user has given consent (via the consent template) to the attribute sets (set in Allowed Attribute Sets) before redirecting the user to the Service Provider.
Enforced consent indicates that the target application is consuming personal information of the user, for which the latter needs to give permission (consent).
|Attribute Set||Selecting an Attribute Set, allows IDHub to request these specific attributes to a SAML (via AttributeConsumingServices) or OpenIDConnect (via Scopes) IDP.|
|Allowed Attribute Sets||Specifies the list of attribute sets which the Proxy SP will consume.
Enabling an Attribute Set, implies the consent for this Attribute to this Proxy SP will be verified.
If the user does not give consent, the attributes will be removed from the headers.
If the user does not give consent, and the Attribute Set is checked as "required," the user will get an Access Denied error.
|Custom Attributes||Specify any Key/Value pair that can be requested and used from workflows, API, authentication rules, ...|
Due to the nature of how cookies work, it is only possible to have a SSO between subdomains of the same primary domain.
By default, the session cookie gets written to the current domain. If you want to enable SSO between subdomains, it is required to set an additional variable in the gateway configuration.
set $domain '.mycompany.com';
mind the dot preceding the domain name
It also advised to assign one subdomain to handle the login, for example 'login.mycompany.com'.
set $login_url 'https://login.mycompany.com/idhub/gw-login';