Identity Provider Proxy | Using Cirrus Identity Provider Proxy
Cirrus Identity Provider Proxy discovery configuration
In most scenarios your Service Provider (SP) will send users to the Cirrus Proxy to authenticate. The Cirrus Proxy will show a discovery interface to users. The user will select an identity provider (IdP) and the Proxy will send the user to that IdP to authenticate.
If authentication is successful, the IdP will send the end user back to the Proxy, the Proxy will perform any configured business logic, and send the end user back to the SP.
For a Shibboleth Service Provider deployment, see the “Shibboleth Resources | Using a Shibboleth service provider with Cirrus Proxy” example configuration.
Bypass Proxy discovery
In some situations your SP may already know the upstream IdP that the proxy should use and you want the user to bypass the discovery normally performed by the proxy. This can be achieved by sending a carefully constructed request to the proxy that contains the following information:
The SP Entity ID
Relay State for the SP. This is often the path on the SP that the user should end up on after authenticating
The upstream IdP EntityID
URL encode these parameters and use them as query parameters to the SingleSignOnService HTTP-Redirect binding URL for the proxy. You'll have a URL of the format $bindingUrl?spentityid=$SPEntityID&RelayState=$RelayState&IDPList=$IdpEntityID
Sending a user to the below example will tell a Cirrus proxy to use Google as the upstream IdP and return the user to a Cirrus test SP that will display some attributes.
Perform discovery before AuthNRequest
In the standard flow the SP sends the user/browser to the proxy first (using a SAML AuthNRequest) and then discovery is performed. In some case you may want to perform discovery first and send the user to the proxy second AND bypass discovery on the proxy. This can be achieved by constructing two URLs with the necessary parameters: The discovery return URL and discovery URL
Discovery return URL
The discovery return URL is similar to the 'Bypass Proxy Discovery' URL. It initiates the login after discovery has been performed. It will get used when constructing the discovery URL. You'll need the following information:
The SP Entity ID
Relay State for the SP. This is often the path on the SP that the user should end up on after authenticating.
URL encode these parameters and use them as query parameters to the SingleSignOnService HTTP-Redirect binding URL for the proxy. You'll have a URL of the format $bindingUrl?spentityid=$SPEntityID&RelayState=$RelayState
The discovery URL will load Cirrus's Discovery interface. Users can be sent here to pick an IdP and initiate a login. You'll need to know the following information:
The Proxy's SP entityId
The return URL from above
URL encode these parameters and use them as query parameters to the discovery URL. You'll have a URL for the format https://apps.cirrusidentity.com/console/ds/index?returnIDParam=IDPList&entityID=$proxySpEntityId&return=$returnUrlEncoded
Sending a user (or iframing) this example discovery URL will allow you to initiate discovery from your SP and have the response processed by the Proxy. https://apps.cirrusidentity.com/console/ds/index?returnIDParam=IDPList&entityID=https%3A%2F%2Fsupport.proxy.cirrusidentity.com%2Fsp&return=https%3A%2F%2Fsupport.proxy.cirrusidentity.com%2Fsaml2%2Fidp%2FSSOService.php%3Fspentityid%3Dhttps%253A%252F%252Fstandard.monitor.cirrusidentity.com%26RelayState%3D%252Fmodule.php%252Fcore%252Fauthenticate.php%253Fas%253Dmonitor-standard
Configure my own Discovery Service for Proxy
The Proxy uses the Cirrus Discovery Service to perform discovery. If you have a Discovery Service that is compatible with OASIS IdP Discovery Service Protocol and Profile and want to use that with the Cirrus Proxy then contact firstname.lastname@example.org to have this enabled for your proxy.
Standard Flow with Custom Discovery for SP
In the standard flow the proxy displays the same discovery interface for all SPs making use of the proxy. If you want to customize the discovery interface shown by the proxy based on the SP using the proxy then contact email@example.com to discuss your options.
Cirrus Identity Provider Proxy and assertion scoping
In an identity federation each Identity Provider has certain scopes that it can use when asserting user attributes to avoid name collisions. For example if two Identity Providers had a user called John they would need a way to distinguish which john is from which IdP. Using scoping, the IdPs could assert the identifier as john@orgA.com and john@orgB.com, where orgA and orgB are the domain names for the organizations associated with each IdP.
The Cirrus SAML Proxy supports scopes in several fashions
Exact Scope Checking
The proxy will check that the scope asserted from an Identity Provider matches the allowed scope for the Identity Provider. If an IdP asserts a scope that it is not allowed to the proxy will remove that assertion.
This is enabled by default for these attributes: eduPersonPrincipalName, eduPersonScopedAffilitation
Ends with Scope Checking
In some scenarios a Service Provider uses email address as its internal identifier. The proxy can perform scope checking on the email address. In some organizations user's email addresses may contain subdomains. For example Example Edu may have a scope of example.edu but email address domains like org.example.edu. If it enabled this feature performs scope checking by ensuring the scope domain ends with the appropriate domain.
Ignore Scope Checking
If you intend to proxy an Identity Provider that does not have a fixed scope you may opt to disable scope checking for that Identity Provider. For example Google provides email for lots of enterprises. If you use the Cirrus Gateway as an IdP AND use email address for eduPersonPrincipalName then the Google gateway may assert a scope for any business that uses Google for email. In such a scenario you'll want to disable scope checking for a specific IdP, and continue checking other IdPs.
This is enabled by default for Cirrus Gateway IdPs that provide email service for multiple domains.
Your use case may require you to re-write the scope of proxied attributes. This feature will have proxy change scoped attributes in one of two ways:
Change scope: A scoped value of firstname.lastname@example.org will be changed to email@example.com. This is useful if your SAML profile has specified the allowable values for the de-scoped attribute.
Change scope and de-scoped value: A scoped value of firstname.lastname@example.org will be changed to email@example.com. This is useful when you want to preserve the old scope in some fashion during the rewrite.
The new scope is configurable. This feature is disabled by default. If enabled it can be applied to specific attributes, or to specific scopes or to a combination of the two.