<div dir="ltr"><div>( looks like the Erik's email got stuck somewhere ... I'm posting assuming my posts will make it through! :)</div><div>/Dick</div><div>....</div><div><br class="gmail-Apple-interchange-newline">Hi all,</div><div><br></div><div>Below are the notes from the WG meeting at IIW on May 2, 2019.</div><div><br></div><div>-Erik</div><div><div><br></div><div><div><b>Attendees</b></div><div>- Darin McAdams, AWS</div><div>- Dick Hardt</div><div>- Erik Gustavson, Google</div><div>- Matt Domsch, SailPoint</div><div>- Mike Jones, Microsoft</div><div>- Pam Dingle, Microsoft</div><div>- Romain Lenglet, Google</div><div>- Sanjoli Ahuja, ADP</div><div><br></div><div><b>Agenda</b></div><div>1. Learning from pilot</div><div>2. Image standardization</div><div>3. SCIM directionality</div><div>4. SCIM schema</div><div>5. Minimum SCIM APIs</div><div>6. Identity governance</div><div>7. What's up with OAuth Tokens?</div><div><br></div><div>Erik Gustavson has been voted a new co-chair of the Working Group.</div><div><br></div><div><b>1. Learning from pilot</b></div><div><br></div><div>Questions about the UX for the approval workflows on both the Application Provider and the Identity Provider side:</div><div>- Once the integration is approved by the admin, how do we notify that it's approved and we can continue the registration?</div><div>- How does the admin get back into the context of the SSO integration after approval?</div><div>- How does the admin check on the progress of the approval?</div><div>- 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?</div><div><br></div><div>We'll keep that workflow as a black box in the standard.</div><div>There's no need to extend the protocol.</div><div>But we could specify best practices to get the UX right, incl.:</div><div>- Diagram of the different standard states of the registration.</div><div><br></div><div>While implementing the pilot, we had discussions about what authentication mechanism to use.</div><div>We settled with OAuth bearer tokens.</div><div><br></div><div>The pilot will be demoed live at Identiverse, in a 25-minute session.</div><div>Suggestions for the session:</div><div>- Contrast the demo with the instructions required to setup SSO / auto-provisioning manually.</div><div>- Schedule a WG meeting & happy hour at Identiverse after the session, to gather what everyone has learnt.</div><div><br></div><div>The scenarii are not accessible from the WG website.</div><div>This makes it look like the WG is inactive.</div><div><br></div><div><b>Action items:</b></div><div><b>- [Erik, Pam] Update the website to link to the git repo and the WG meeting minutes.</b></div><div><br></div><div><br></div><div><b>2. Image standardization</b></div><div><br></div><div>Darin proposed a first draft of license for logo images.</div><div>It's not clear whether the license allows caching images, and for how long.</div><div><br></div><div>The standard actually mandates that a client refreshes the metadata periodically.</div><div>The client should also refresh the logos along with the rest of the metadata.</div><div><br></div><div>We need to specify reasonable size constraints for the icons and logos.</div><div><br></div><div>All the provider metadata should be localized:</div><div>- The display name is already localizable.</div><div>- The images should also be localized (cf. for example Google Play Store).</div><div><br></div><div>Is there a need to differentiate the metadata for multiple services hosted at the same provider / domain?</div><div>That's a problem especially for "suite" application providers: ADP, Google, Microsoft, Zoho, Salesforce, etc.</div><div>Should we extend the metadata to include information about the service, in addition to the provider?</div><div>E.g. should we support having a separate logo or domain name per service / "real-estate"?</div><div>This goes into the management of entitlement ("which service can a client access?"), and that's beyond the scope of FastFed / SSO setup.</div><div><br></div><div>The problem is that extending the metadata can become complicated quickly.</div><div><br></div><div><b>Action items:</b></div><div><b>- [everyone] Send suggestions of image formats / sizes / aspect ratios (square? rectangle?) that should be mandated.</b></div><div><b>- [Darin] Update the metadata spec to allow for localized images.</b></div><div><br></div><div><br></div><div><b>3. Identity governance</b></div><div><br></div><div>Matt proposed to separate the roles of Identity Provider (doing SSO) and Identity Governance (doing SCIM provisioning).</div><div>The Identity Provider is not necessarily the source of truth for provisioning, and may not have all the information needed by the Application Provider.</div><div><br></div><div>"Provisioning Provider" would be a more desciptive term than "Identity Governance Provider".</div><div><br></div><div>In FastFed, from the Application Provider's viewpoint, the Identity Provider (doing SSO) and Identity Governance Provider (doing SCIM) are one big box.</div><div>Those two functions can already be different systems.</div><div><br></div><div>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.</div><div>We'll keep naming this entity "Identity Provider".</div><div><br></div><div>SailPoint is working on AP and IdP implementations.</div><div><br></div><div><b>Action items:</b></div><div><b>- [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.</b></div><div><b>- [Darin] Eventually, extend the messages from Identity Provider (metadata, etc.) to support different sets of credentials, one for SSO and one for provisioning, etc.</b></div><div><br></div><div><br></div><div><b>4. SCIM directionality</b></div><div><br></div><div>The standard currently states that the IdP is always the client in the SCIM protocol.</div><div>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.</div><div>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.</div><div><br></div><div><b>Action items:</b></div><div><b>- [Pam] Research the right vocabulary for expressing those configurations.</b></div><div><b>- [Darin] Allow for flexibility for multiple SCIM provisioning modes (push and pull).</b></div><div><br></div><div><br></div><div><b>5. SCIM schema</b></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div><b>Action items:</b></div><div><b>- [Matt, Sanjoli (?)] Specify the minimum set of SCIM schemas / attributes to implement FastFed, and the SCIM extensions recommended to cover the HRIS use cases.</b></div><div><b>- [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.</b></div></div></div></div>