[Openid-specs-fastfed] New member, IDP & Governance thoughts

Matt Domsch matt.domsch at sailpoint.com
Fri May 3 00:25:50 UTC 2019


Slides from my IIW discussion are available here.  Notes will come out in the proceedings.
https://domsch.com/IIW28/FastFed-Governance-IIW28.pdf


Matt Domsch
VP, Lead Corporate Architect
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
mobile: 512-981-6486
www.sailpoint.com<http://www.sailpoint.com/>

From: Matt Domsch
Sent: Monday, April 22, 2019 3:54 PM
To: openid-specs-fastfed at lists.openid.net
Subject: New member, IDP & Governance thoughts

Greetings.  I'm a new member of the FastFed WG, though I've been following along for several weeks and have been very pleased with both the concept and specifications the team has developed.  I look forward to meeting people at IIW and/or Identiverse in the coming weeks, and participating in the WG.

In thinking about user provisioning, deprovisioning, updating, and permission assignment, I believe there is an opportunity to include identity governance concepts within FastFed more fully.

FastFed expects that governance is done by the Identity Provider.  Governance includes:

  *   Provisioning and de-provisioning accounts from IDPs into Applications
  *   Informing Applications when user attributes change in the IDP
  *   Assigning permissions within the Application based on IDP-known information

The challenge is that many traditional Identity Providers do not provide these functions today, or do so sub-optimally.  An IDP may know the groups to which someone is a member, but it knows nothing about:

  *   Which users within an IDP should have an account in the Application?
     *   Not every employee, temporary employee, contractor, or service account should have an account in every Application.
     *   This is traditionally handled by assigning group membership, and communicating that group membership to the Application somehow, e.g. a SAML attribute of "application_X_user_allowed", used for just-in-time account provisioning at the application.
  *   Which permissions within the target service should an individual account be granted?
     *   Every application defines their own role and permission structure. Within an IDP, these are often modeled as groups. You wind up with an explosion of IDP groups if you try to manage all the user permissions as merely group membership.
     *   Inherited permissions require well-defined, nested groups, and don't easily allow for exceptions.
  *   Does an individual require approval, by a manager or the application administrator, for requests to use the application?
     *   Few IDPs have their own service desk with request and approval workflows.
     *   Requests for updated permissions (e.g. moving from a read-only to a read/write permission) may require review and approval.
  *   FastFed Scenario #3, wherein a user may need access to applications before employment begins and their corporate IDP account is active, or after they leave employment and their IDP account is deactivated, is difficult to accomplish solely from an IDPs perspective.

Furthermore, when IDPs do project permissions, via group memberships, via SAML attributes or OIDC claims, the previous set of permissions remain valid for the lifetime of the claim token, and may require a user to log out and back in again to obtain a new access token (unless the IDP can force a token refresh asynchronous to the token lifetime).  This also requires a 1:1 mapping of SAML attributes or OIDC claims to application permissions, and ongoing coordination between the two configurations as Application permission models are enhanced.

End-user administrators also want to establish governance when initially onboarding a new application, whenever possible, so as to have less to clean up after the ungoverned application has been in use for a while.

An Identity Governance service would be in the perfect position to address these scenarios, and to perform the actions necessary to configure the Application for each user's specific policy-defined access.
By splitting the FastFed concept of Identity Provider into two parts, the Identity Provider and the Governance Provider, we can allow a richer governance experience in the application, backed by well-defined corporate policy, and with no loss of functionality.  Identity Providers that also serve as the Governance Provider can continue to operate as a single system without change.  Splitting the concepts just allows for two separate products to be used for the Identity Provider and Governance Provider functions.  Any data synchronization needed between the Identity Provider and Governance Provider can be orchestrated by them pairwise, as is already common, using SCIM or the IDPs native API.
For purposes of governing the Application, including provisioning and deprovisioning of accounts, and  updating account entitlements, the Governance Provider would be a registered OIDC client in the Identity Provider, with its own client credentials, able to make IDP-authenticated SCIM calls to the Application Provider, close in time as each user's attributes change.

Thoughts?

[cid:image004.png at 01D5011C.D83B3A90]
Thanks,
Matt
Matt Domsch
VP, Lead Corporate Architect
[X]<https://www.sailpoint.com/>
matt.domsch at sailpoint.com<mailto:matt.domsch at sailpoint.com>
mobile: 512-981-6486
Join the #SailPointCrew<https://www.sailpoint.com/company/careers/>
[The Power of Identity - SailPoint Email Signature]<https://www.sailpoint.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20190503/2e5964b4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.emz
Type: application/octet-stream
Size: 12907 bytes
Desc: image002.emz
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20190503/2e5964b4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 46957 bytes
Desc: image004.png
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20190503/2e5964b4/attachment-0001.png>


More information about the Openid-specs-fastfed mailing list