Proxy Service Provider

Introduction

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.

Sequence Diagram

Fields

Field	Description
Display Name	User defined name of the Service Provider
URL	Not used
Description	User defined description of the Service Provider
Authentication Scheme	Defines which IDP(s) that can authenticate this user.
Type	"Proxy Locations"
Location	URL Path (after the hostname) that indicates where the Service Provider is located.
Hostname	Hostname of the server (if another server then the Admin Portal Server is used). Subdomain and domain name. If not provided, this server hostname is used.
Force Authentication	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, ...

Cross-domain support

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.

file: /opt/trustbuilder/gateway/instances/<instance_name>/conf/root.conf.d/00_secure_gw.conf

add line:

set $domain '.mycompany.com';

It also advised to assign one subdomain to handle the login, for example 'login.mycompany.com'.

file: /opt/trustbuilder/gateway/instances/<instance_name>/conf/root.conf.d/00_secure_gw.conf

edit line:

set $login_url 'https://login.mycompany.com/idhub/gw-login';