Identity Provider Proxy | Getting Started
Planning Cirrus Identity Provider Proxy
Proxy solutions tend to sit in the middle of things — the Cirrus Identity Provider Proxy is no different. A bit of planning before getting started will go a long way to reducing initial confusion. Consider the following questions:
Who is the target audience?
What IdP(s) will the audience use?
Does the audience vary based on the Service Provider being accessed?
What is/are the Service Providers that will be accessed?
Do the Service Providers meet Cirrus Identity Provider Proxy requirements?
Do the Service Providers have an authorization process to control access that is separate from authenticating to the service?
Will the Proxy be required to provide access control?
How will the end user “discover” which Identity Provider to use with the Proxy -- which is another way of saying what discovery configuration will the Proxy have?
By default, the Proxy is configured to use the Cirrus Discovery Service and is the quickest to start with. Both the Cirrus Proxy and the Cirrus Discovery Service are integrated with InCommon and eduGAIN metadata to further lower the initial configuration effort.
If the audience is being directed from another application such as a portal (and the service provider is reasonably well behaved), discovery can be bypassed with a carefully constructing a URL. The URL can be used for links in portals or other web content to direct the audience to the service. See “Discovery Configuration with Cirrus Proxy | Bypass Proxy Discovery” for more details.
The Proxy can also be configured to use any discovery service that is compatible with the OASIS IdP Discovery Service Protocol and Profile if an organization desires. See “Discovery Configuration with Cirrus Proxy | Configure my own Discovery Service for Proxy” for more details.
Cirrus Identity Provider Proxy “Hello World”
Customers subscribing to Cirrus Identity Provider Proxy will have a UAT Proxy instance provisioned during customer on-boarding. Cirrus staff will also perform some initial configuration and, if appropriate, register the instance as an SP in the InCommon trust federation.
Customers will often subscribe to one or more additional Cirrus Identity modules to support desired implementations. In addition to provisioning the Proxy instance, some initial setup for Cirrus Gateway, Cirrus Account Linking, and/or Cirrus Invitation will also take place.
The following are the steps needed to get started using Cirrus Identity Provider Proxy:
Customers should answer the question in the “Planning Cirrus Identity Provider Proxy” section. Cirrus Identity can offer generally accepted practices, customer stories, and professional services to help.
As mentioned above, Cirrus Identity generally registers the SP side of the Proxy with the InCommon trust federation as part of the provisioning process. This allows identity providers to access metadata. Identity Providers will need to adjust attribute release to the Proxy for any attributes needed.
Depending on the customer, Cirrus will provision other modules based on the customer’s subscription (or trial/PoC agreement). Modules such as Cirrus Gateway, Cirrus External Identity Provider, and Cirrus Invitation each have associated setup. See the “Getting Started” for each module as appropriate:
If the Customer has subscribed to the Cirrus Account Linking solution, the customer will need to coordinate with Cirrus Identity on the details of the linking identifier to be used. Cirrus Identity will need these details to finish the configuration of the Proxy (See Cirrus Account Liking Getting Started).
If there is a service provider (SP) that will use the Proxy, but the metadata for the SP is not published to federation metadata (for example InCommon or eduGAIN), the metadata needs to be sent to Cirrus Identity Support (email@example.com) for configuration. Additionally, if there is an SP with special attribute requirements, regardless where the metadata is published, that also needs to be communicated to Cirrus Identity Support.
If there is an identity provider that is needed by the Proxy audience, but the metadata for the IdP is not published to federation metadata (for example InCommon or eduGAIN), the metadata needs to be sent to Cirrus Identity Support (firstname.lastname@example.org) for configuration.
A member of the organization needs to have access to the Cirrus Console and to be granted the “Organization Administrator” (org admin) role for your organization. (See Cirrus Console Getting Started)
If the customer will be using the Cirrus Discovery Service (recommended at the start), an admin will configure the Cirrus Discovery Service for the service provider side of the Proxy using the Cirrus Console. The Discovery Service will be the interface users are redirected to when they attempt to log in to the service provider. All of the identity providers options for the Proxy audience should be configured (See Cirrus Discovery Getting Started).
Change the configuration for all service providers (SP) that will use the Proxy to trust the identity provider (IdP) side of the Proxy. Cirrus Identity will provide the path to the IdP metadata but it will generally be at a URL of the form https://NAME.proxy.cirrusidentity.com/saml2/idp/metadata.php (See Cirrus Proxy Documentation for further details).
If the customer configured the Cirrus Discovery Service (see Step #8), change the configuration for all SPs that will use the Proxy to use the Cirrus Discovery Service - the discovery URL is "https://apps.cirrusidentity.com/console/ds/index" and details for different service provider platforms are available here).