[Openid-specs-fastfed] notes from May 2, 2019
Erik Gustavson
erikgustavson at google.com
Sat May 18 17:36:36 UTC 2019
Hi all,
Below are the notes from the WG meeting at IIW on May 2, 2019.
-Erik
*Attendees*
- Darin McAdams, AWS
- Dick Hardt
- Erik Gustavson, Google
- Matt Domsch, SailPoint
- Mike Jones, Microsoft
- Pam Dingle, Microsoft
- Romain Lenglet, Google
- Sanjoli Ahuja, ADP
*Agenda*
1. Learning from pilot
2. Image standardization
3. SCIM directionality
4. SCIM schema
5. Minimum SCIM APIs
6. Identity governance
7. What's up with OAuth Tokens?
Erik Gustavson has been voted a new co-chair of the Working Group.
*1. Learning from pilot*
Questions about the UX for the approval workflows on both the Application
Provider and the Identity Provider side:
- Once the integration is approved by the admin, how do we notify that it's
approved and we can continue the registration?
- How does the admin get back into the context of the SSO integration after
approval?
- How does the admin check on the progress of the approval?
- In more complex use cases, e.g. when the org that manages the SP is
different from the org that manages the IdP, who receives an email to
approve the registration?
We'll keep that workflow as a black box in the standard.
There's no need to extend the protocol.
But we could specify best practices to get the UX right, incl.:
- Diagram of the different standard states of the registration.
While implementing the pilot, we had discussions about what authentication
mechanism to use.
We settled with OAuth bearer tokens.
The pilot will be demoed live at Identiverse, in a 25-minute session.
Suggestions for the session:
- Contrast the demo with the instructions required to setup SSO /
auto-provisioning manually.
- Schedule a WG meeting & happy hour at Identiverse after the session, to
gather what everyone has learnt.
The scenarii are not accessible from the WG website.
This makes it look like the WG is inactive.
*Action items:*
*- [Erik, Pam] Update the website to link to the git repo and the WG
meeting minutes.*
*2. Image standardization*
Darin proposed a first draft of license for logo images.
It's not clear whether the license allows caching images, and for how long.
The standard actually mandates that a client refreshes the metadata
periodically.
The client should also refresh the logos along with the rest of the
metadata.
We need to specify reasonable size constraints for the icons and logos.
All the provider metadata should be localized:
- The display name is already localizable.
- The images should also be localized (cf. for example Google Play Store).
Is there a need to differentiate the metadata for multiple services hosted
at the same provider / domain?
That's a problem especially for "suite" application providers: ADP, Google,
Microsoft, Zoho, Salesforce, etc.
Should we extend the metadata to include information about the service, in
addition to the provider?
E.g. should we support having a separate logo or domain name per service /
"real-estate"?
This goes into the management of entitlement ("which service can a client
access?"), and that's beyond the scope of FastFed / SSO setup.
The problem is that extending the metadata can become complicated quickly.
*Action items:*
*- [everyone] Send suggestions of image formats / sizes / aspect ratios
(square? rectangle?) that should be mandated.*
*- [Darin] Update the metadata spec to allow for localized images.*
*3. Identity governance*
Matt proposed to separate the roles of Identity Provider (doing SSO) and
Identity Governance (doing SCIM provisioning).
The Identity Provider is not necessarily the source of truth for
provisioning, and may not have all the information needed by the
Application Provider.
"Provisioning Provider" would be a more desciptive term than "Identity
Governance Provider".
In FastFed, from the Application Provider's viewpoint, the Identity
Provider (doing SSO) and Identity Governance Provider (doing SCIM) are one
big box.
Those two functions can already be different systems.
We want to keep the handshake / workflow as simple and unified as possible,
i.e. we want to keep the admin redirected to a single place to setup and
orchestrate both SSO and provisioning.
We'll keep naming this entity "Identity Provider".
SailPoint is working on AP and IdP implementations.
*Action items:*
*- [Darin] Audit the spec for anything that would prevent the use of
different backend systems for authentication vs. provisioning. E.g. using
Okta for sign-in and Sailpoint for SCIM. The shared OAuth token is one
example of an attribute that assumes both functions are fulfilled by a
single party.*
*- [Darin] Eventually, extend the messages from Identity Provider
(metadata, etc.) to support different sets of credentials, one for SSO and
one for provisioning, etc.*
*4. SCIM directionality*
The standard currently states that the IdP is always the client in the SCIM
protocol.
In the future, we may need to support setting up SCIM in the other
direction as well, where the Application Provider is the SCIM client.
We may even need to support bi-directional SCIM to support backflows, where
the Application Provider feeds back updates about users to the Identity
Provider.
*Action items:*
*- [Pam] Research the right vocabulary for expressing those configurations.*
*- [Darin] Allow for flexibility for multiple SCIM provisioning modes (push
and pull).*
*5. SCIM schema*
ADP HR integration requires 8 employment-related attributes that are
missing from standard SCIM schemas, incl. hiring date, termination date,
employment type (full time, part time, ...), department, etc.
It's better to negotiate a SCIM schema in FastFed than a raw list of
required attributes, since the former has a well-defined semantics.
If there's no existing SCIM extension that is the union of attributes
needed by HRISes, HR Application Providers should get together to define
and standardize a common SCIM schema.
*Action items:*
*- [Matt, Sanjoli (?)] Specify the minimum set of SCIM schemas / attributes
to implement FastFed, and the SCIM extensions recommended to cover the HRIS
use cases.*
*- [Darin] Consider if a JIT provisioning profile is necessary in order to
signal that the desired user attributes must be included in the sign-in
assertions.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20190518/c107c9ab/attachment.html>
More information about the Openid-specs-fastfed
mailing list