[Openid-specs-fastfed] DRAFT :: FastFed use cases
Dick Hardt
dick.hardt at gmail.com
Tue Aug 16 01:03:01 UTC 2016
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.
-- Dick
###FastFed
##Background
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.
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.
Given the diversity of deployment configurations, most deployed
applications will need to be updated to support FastFed. Q: Is this
acceptable?
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.
Following are the draft use cases.
TBD:
- API / Token authentication
- discovery
- testing
- key rotation
##Use Cases
#Identifier Only
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.
Q: Are there real world deployments of Identifier Only?
#Identifier and Attributes
The application requires a unique identifier for the user and a set of
attributes. Groups, roles and entitlements are not included.
SAML includes attributes in the assertion. We will need to prescribe the
schema for the SAML attributes. OpenID provides a user info API.
Q: Are the attributes in SCIM sufficient?
#Identifier and Just-In-Time Attributes and Groups
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.
Q: Is there a standardized way of communicating group membership in OpenID?
Or do we have a SCIM pull?
Q: Why would an application choose JIT over a SCIM push?
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)
#Identifier and SCIM
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.
Q: Same group / role / entitlement question as in JIT.
--
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20160815/b3648f34/attachment.html>
More information about the Openid-specs-fastfed
mailing list