Skip to Main Content

Fast Federation: Onboarding Applications to your Identity Provider

As an IT administrator charged with onboarding a new application to your environment, you most often want to enable Single Sign-On, giving your team members access to the app using their corporate credentials (username and password). Granting said access is typically done via integration to an LDAP service directly (assuming the application can speak LDAP natively), or more commonly these days, via a federation protocol such as SAML or OpenID Connect (OIDC) to an Identity Provider (IdP).

One challenge IT administrators face is that every IdP, and every application, have different configuration screens and options when setting up such SAML or OIDC federations. What are my Client IDs called? What certificates do I need to exchange between the IdP and application? How do I handle certificate rotation (because you will rotate certificates, right?)  Do I use a POST binding or a Redirect binding? That’s just at the protocol level.

Then there are additional complexities in mapping user attributes between the IdP and the application. What one IdP calls “last_name”, your application may call “surname” or “LastName”. Which user attribute is the unique identifier, and is it of a form the application can consume?

Get any of these details incorrect, on either the IdP or application side and federation, doesn’t work as expected.

The OpenID Foundation Fast Federation Working Group (FastFed) was started in 2016 to simplify this onboarding experience for IT administrators. By being prescriptive about their use, the working group is standardizing how SAML and OIDC federations are established. By incorporating the SCIM standard, FastFed prescribes the user attributes to be used, so there’s no need within the protocol to map between attribute names and types.

At Identiverse 2019, working group members Darin McAdams of Amazon Web Services, and Erik Gustavson of Google demonstrated the FastFed user experience on stage. With an AWS account as the application, and Google Apps as the IdP, Darin, in the role of application administrator, by only entering his email address, federated that AWS account to Google Apps. Erik, in the role of the IdP administrator, had to approve the addition of the application to the IdP. Neither had to configure their tools but only provide their approval. You can watch the process in action below.

SailPoint joined the FastFed working group earlier this year for several reasons:

  • Our applications are routinely federated in our customer’s deployments, and we want that simple onboarding experience for our customers.
  • As a primary contributor to the SCIM standard, we’re excited to see it used to exchange user attributes and for user provisioning.
  • We see user provisioning as a function that an identity governance platform, like SailPoint IdentityIQ and IdentityNow, can naturally deliver, enabled within the scope of the onboarding experience. We see lots of value to the work of the FastFed working group and are pleased to contribute to it.

For more information on the FastFed Working Group, or to join and contribute yourself, please see https://openid.net/wg/fastfed/.


Discussion