<div dir="ltr"><div><div>No need to read this email prior to our call tomorrow. We will have some time at the beginning of the call for everyone to read the whole document and then we will discuss the contained questions and any other questions that come up. </div><div><br></div><div>-- Dick</div><div><br></div><div>###FastFed</div><div><br></div><div>##Background</div><div><br></div><div>The purpose of FastFed is to enable an administrator to setup a federation between an identity provider and a cloud application in minutes. Although there are standardized federation protocols, there are numerous ways to implement them which makes deployment complicated and can take days to complete. Identity providers have created recipes that simplify deployment for popular cloud applications, but it can still take hours to setup, and creates a barrier to adoption of new cloud applications.</div><div><br></div><div>FastFed will provide a set of highly prescriptive profiles for federation between an identity provider and an application that are the best current practice to support the common use cases. It is anticipated that the initial profiles will be suitable for most applications currently deployed, but it is not a goal to be suitable for all applications. As additional common patterns emerge, additional profiles will be developed. </div><div><br></div><div>Given the diversity of deployment configurations, most deployed applications will need to be updated to support FastFed. Q: Is this acceptable?</div><div><br></div><div>FastFed will assist applications that have not implemented federation as there will be a prescriptive best practice that will work with any identity provider that has implemented FastFed, with no need to create a recipe, and will result in a faster configuration process.</div><div><br></div><div>Following are the draft use cases. </div><div><br></div><div>TBD:</div><div>- API / Token authentication</div><div>- discovery</div><div>- testing</div><div>- key rotation</div><div><br></div><div>##Use Cases</div><div><br></div><div>#Identifier Only</div><div>The application only requires a unique identifier for the user. This identifier is presented at authentication time. No additional attributes are provided. SAML 2.0 or OpenID Connect can provide this.</div><div><br></div><div>Q: Are there real world deployments of Identifier Only?</div><div><br></div><div>#Identifier and Attributes</div><div>The application requires a unique identifier for the user and a set of attributes. Groups, roles and entitlements are not included.</div><div>SAML includes attributes in the assertion. We will need to prescribe the schema for the SAML attributes. OpenID provides a user info API. </div><div><br></div><div>Q: Are the attributes in SCIM sufficient? </div><div><br></div><div>#Identifier and Just-In-Time Attributes and Groups</div><div>The application requires a unique identifier for the user, attributes, and group membership that are provided just-in-time (JIT). SAML can include attributes and groups in the assertion.</div><div>Q: Is there a standardized way of communicating group membership in OpenID? Or do we have a SCIM pull?</div><div>Q: Why would an application choose JIT over a SCIM push?</div><div>Q: Can we just use group memberships to indicate what "role" and "entitlements" the user has? Will these groups be the "roles" already known the application and the identity provider has mapped the groups in the directory to the applications roles? Do we still need to have roles and entitlements?  (this also applies to the next use case)</div><div><br></div><div>#Identifier and SCIM</div><div>The application separates authentication from provisioning. A SAML or OpenID flow provides just the user identifier which is only authentication. Attributes and group membership is pushed from the identity provider to the application.</div><div><br></div><div>Q: Same group / role / entitlement question as in JIT.</div></div><div><br></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Subscribe to the <a href="http://hardtware.com/" target="_blank">HARDTWARE</a> mail list to learn about projects I am working on!</div></div></div></div></div></div>
</div>