Gateway | Getting Started
Cirrus Gateway “Hello World”
The Cirrus Gateway enables any Service Provider (SP) that supports SAML v2.0 to leverage social login as a method for authentication. It is also quick to setup if the SP supports the use of a SAML based discovery service. If you have an SP that doesn’t quite meet these requirements, consider using the Gateway with the Cirrus Identity Provider Proxy as an integrated authentication solution (the Proxy supports additional protocols).
NOTE: If you are using a Proxy, your target SP will trust the Proxy as its identity provider (IdP), and the “SP” in the instructions below will be for the Proxy (see Cirrus Identity Provider Proxy getting started). The Cirrus Proxy is automatically integrated with the Gateway for social login and you will not need to perform Steps #4 and #7 below.
The following are the steps needed to get started using the Cirrus Gateway:
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).
From the Cirrus Console, an org admin will enable social providers for the organization -- this should be any social providers an organization wants to allow.
Cirrus Identity needs the metadata for any service providers (SP) that you want to use with the Gateway. If the SP is registered with one of the eduGAIN federations (InCommon, UK Fed, CAF, or others) we already have it. If not, you can send us the metadata and we will load it.
From the Cirrus Console, an org admin will create the SP in the Console so it can be configured (not for Proxy integration). At this point, the org admin may designate an SP admin to complete the setup.
From the Cirrus Console, an admin will enable the desired social providers specific to the SP (this may be a subset of social providers allowed at the org level). The admin will need a developer account for each social provider to complete the API integration. For each enabled social provider, the admin will follow the instructions available in the Console to perform the social provider API integration.
From the Cirrus Console, an admin will configure the Cirrus Discovery Service -- to enable login via social identity providers, the organization’s enterprise identity provider (see Cirrus Discovery getting started), as well as other federated partners and custom IdPs.
For SPs integrating directly with the gateway (not for Proxy integration), you will need to change the configuration for the SP to consume Cirrus Gateway metadata - the metadata is available at https://md.cirrusidentity.com/metadata/CirrusIdentitySocialProviders-metadata.xml (further details on Gateway metadata).
Change the configuration for the SP to use the Cirrus Discovery Service - the discovery URL is "https://apps.cirrusidentity.com/console/ds/index" (further details on configuring different service providers).
Once these steps are complete, you are ready to use the Gateway.
Social Provider Considerations
Several factors go into the selection of which Social Providers to use (Step #2 above). While the target audience will play a significant factor in the selection, there are other aspects of each provider that should also be considered. The table below summarizes:
The availability of an email address - many service providers require an email address to provision a user profile
How an ePPN will be constructed - Cirrus Identity generally recommends using the Social Provider’s internal ID with a scope
Does the Social Provider’s ID statically define the end user, or does it function as a targeted ID that depends on the API integration
What is the API rate limit - while usually not a significant issue, most of the Social Providers have rate limits on their APIs
|Email provider - user cannot change||Unique ID scoped to the provider (@google.com)
ID tied to user
|“Your application is limited to the number of API calls it can make by a usage courtesy quota. To view the courtesy limit and to request additional quota for your application, in the Google Developers Console, ...” choose “IAM & Admin” in the Google Console and select “Quotas”. See https://developers.google.com/+/web/api/rest/?hl=en_US#quota for more details.||Google provides an ID that is unique to the user and we recommend that you use this ID. The ID will be scoped to @google.com by the Cirrus Gateway.|
|Available - user can change||Unique ID scoped to the provider (@facebook.com)
ID tied to API Key
|”Rate limiting in the Facebook Graph API should be encountered only in rare circumstances.” See https://developers.facebook.com/docs/graph-api/advanced/rate-limiting for more details.||Facebook returns an "application scoped" ID, (i.e. a targeted ID). This means that each SP that has its own integration with Facebook, will get a different ID for the same user. If you are planning to use the Cirrus Identity Invitation Service, you must share the same API Key/Secret with each SP that will be integrated with Facebook|
|Microsoft||Email provider - user cannot change||Unique ID scoped to the provider (@live.com)
ID tied to user
|No Information Available||Microsoft provides an ID that is unique to the user and we recommend that you use this ID. The ID will be scoped to @live.com by the Cirrus Gateway.|
|Available - user can change||Unique ID scoped to the provider (@linkedin.com)
ID tied to API Key
|“... make more than 500,000 daily calls to an API.. ” See Section 1.4.2 of Terms of Service https://developer.linkedin.com/legal/api-terms-of-use for more details..||LinkedIn only provides a targeted ID for the user is tied to the actual API Key/Secret, and not the LinkedIn application that you associate with your SP. You must share the same API Key/Secret with each of the SPs that will be integrated with LinkedIn.
NOTE: LinkedIn allows you to regenerate the API Key/Secret for any application. If you do this, the user ID will change. If you use LinkedIn, be sure to never change the API Key/Secret.
|Yahoo!||Email provider - user cannot change||No Information Available||Yahoo! is a mail provider and the returned ID will be a value with a scope of @yahoo.com. This ID and scope will be asserted by the Cirrus Gateway.|
|Available - user can change||Unique ID scoped to the provider (@twitter.com)
ID tied to user
|A formula but generally 15 calls in 15 minutes per user token. See, https://dev.twitter.com/rest/public/rate-limiting for more details.||Twitter provides an ID that is unique to the user and we recommend that you use this ID. The ID will be scoped to @twitter.com by the Cirrus Gateway.|
|Not available||Unique ID scoped to the provider (@weibo.com)
ID tied to user
|“...So the limit value is not fixed, different applications have different restrictions, depending on the application of their own quality.” From http://open.weibo.com/wiki/%E6%8E%A5%E5%8F%A3%E8%AE%BF%E9%97%AE%E9%A2%91%E6%AC%A1%E6%9D%83%E9%99%90 using Google Translate, see for more details.||Weibo provides an ID that is unique to the user and we recommend that you use this ID. The ID will be scoped to @weibo.com by the Cirrus Gateway.|