FastFed Easy Connections IDP – APP + Governance – Who should have permissions in the App

From IIW

FastFed: Easy Connections IDP – App + Governance: Who Should Have Permissions in the App?


Wednesday 6C

Convener: Matt Domesch

Notes-taker(s): Thomas Berry


Tags for the session - technology discussed/ideas considered:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


1. Notes received from Matt Domesch:

Session Summary:

High-level introduction to the OpenID Foundation FastFed working group draft specification. Discussion of its implications on Identity Governance (access, permissions, workflow, and lifecycle) for users within an application, which Identity Providers have historically not been responsible for.  Will discuss with the WG how best to resolve the inherent conflict, either by a) not including Provisioning in the spec; b) including Provisioning in the spec, and ignoring governance; c) encouraging a private IDP<->Governance Provider interaction that lets each do their part without further complicating the spec.


Link to presentation: https://domsch.com/IIW28/FastFed-Governance-IIW28.pdf


2. Notes received from Thomas Berry:

Presentation: Identity Governance Using FastFed

OpenID Foundation

SaaS apps to companies IdP


AWS login; tenants; login to FastFed; IdP and App are hooked up after a couple of clicks.

- discovery of IdP
- Metadata for SAML/OIDC (hand-shake)
- OpenID/SAML/SCIM


Standards provide common attributes between IdP and App


Oath, Google, AWS, SalesForce...


FastFed 1.0 Draft


Just in time provisioning when the user login to the system; utilizes SCIM to provide the user data to IdP

- IdP is not the canonical source of the identities; identities have to come from somewhere else. 
- Access: Which users should have access to the application?
- Permissions: which permissions within the target service; what if there are hundreds of things to manage in the application?
- Workflow: access requests—approvals
- Lifecycle: joins, moves, leaves; what actions should be taken


All of this is not typically performed by IdP; Identity Governance!


Governance Provider provides the birthright, workflow, certifications, auditing and logging

GP Private/manual updates to IdP

SCIM between IdP and application


Must turn on governance at the beginning instead of later in the implementation (schedule).


How to do FastFed with Explicit Governance

Governance Provider ——Private exchange, could be SCIM—-> Identity Provider —-AuthN—> Application

Governance Provider ——SCIM, provisioning/deprovisioning/updating users—> Application


Identity Provider would continue providing user authentication to application


Comment/Input:

- Most applications decouple SSO capabilities (authentication/authorization enforcement) from the application; all of the FastFed functionality should be provided (packaged into) by IdP.
- addresses the SAML use case, but SAML doesn’t provide bootstrap
- This would depend on pre-catalog of Application/IdP
- Existing IdP/Federation solutions present a deployment problem


If we were to remove (moving) provisioning from IdP to GP, 

- IdP is the source for identity
- Group membership is specified by business policy in GP


FastFed with IGA = Governance from the start


By splitting the FastFed concept of Identity Provider into two parts, the IdP and the GP, we can allow richer governance...


Pre-employment/post-employment use cases

- Comment: FastFed shouldn’t try to address this workflow; out of scope
Retrieved from "https://iiw.idcommons.net/index.php?title=FastFed_Easy_Connections_IDP_–_APP_%2B_Governance_–_Who_should_have_permissions_in_the_App&oldid=22256"