Service Provider Types: Proxy

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 than the Admin Portal Server is used). Subdomain and domainname.  
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';

mind the dot preceding the domain name

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

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.