FastFed Easy Connections IDP – APP + Governance – Who should have permissions in the App
FastFed: Easy Connections IDP – App + Governance: Who Should Have Permissions in the App?
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:
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
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
- - 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