Skip to main content
Skip table of contents

Proxy Service Provider


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




Display Name

User defined name of the Service Provider


Not used


User defined description of the Service Provider

Authentication Scheme

Defines which IDP(s) that can authenticate this user.


"Proxy Locations"


URL Path (after the hostname) that indicates where the Service Provider is located.  


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   '';

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

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

edit line:

set $login_url   '';

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.