This page is being used to collect Use Cases. Per the usual policy on this wiki, any authenticated user should be able to edit this page, and submit their Use Cases for discussion. Please add your name and site within parentheses at the start of each of your Use Cases.
- (Carnegie Mellon University, Russell J. Yount <rjy@cmu.edu>)
We are working towards using Incommon Federation, OpenID and other future social authentication systems to provide access for what we are terming "Low Level Of Assurance" LLOA access. Our first application to use this is for parental accounts. We would like to provide student billing information to parents based on permissions granted by their children.
The model we have decided on will send an email at the student's request to a parent that invites the parent to register with using one of a number of OpenID providers or Incommon Federation identity providers. We are using this model as we believe students are more likely to know their parents email address than know their parents InCommon or OpenID identity.
The implementation will be done with gateway service which will provide a CMU identities within local CMU shibboleth federation which are the translation of the OpenID or other provider's identity. InCommon federation identities will be used directly.
We hope to use outside identity providers for access to a number of other service in the future. These may include guest network access, preadmission students....
- (CILogon, Jim Basney <jbasney@ncsa.uiuc.edu>)
We are accepting both InCommon and OpenID authentication for the issuance of X.509 certificates for use with grids and cyberinfrastructure (for command-line, message-based, and batch workflows). For IGTF (high assurance) certificates, required by TeraGrid, EGI, and others, we can accept only InCommon Silver authentication. But representatives of other cyberinfrastructure projects (such as DataONE, FutureGrid, and OOI) have requested that we provide lower assurance certificates based on OpenID authentication for greater ease-of-access, especially in cases where the researcher's home campus isn't (yet) an InCommon member. The OIX Certified OpenID providers are of particular interest to us, so we have some minimum level of assurance.
A significant difference for us between InCommon and OpenID is that we can get the researcher's name and email address from InCommon identity providers to insert into the certificate, whereas we find many OpenID providers can not provide this information to us, so we just put the OpenID URL itself in the certificate (see http://ca.cilogon.org/names).
- (Internet2 COmanage, Benn Oshrin)
We anticipate that some members of some VOs will maintain relationships with different Real Organizations (ROs) over the course of their affiliation with the VO. We anticipate that different ROs will be able to support different identity protocols, and that in between affiliation with "traditional" education and research organizations, some members may only maintain identities at "social" organizations such as Facebook and Google. This should look pretty similar to Peter's original use case.
- (Shibboleth Project, Scott Cantor)
My interest is in ensuring that the use of OpenID in conjunction with Shibboleth is sensible and as much as possible seamless to applications. I prefer to think that Shibboleth integration models represent a coherent, consensus-based view of how federation and SSO ought to be integrated, and would just like to maintain that with OpenID in the picture. In particular, I think user identification, discovery, and provisioning should be addressed with a protocol-neutral view where possible, and I would like to see multiple deployment architectures possible without changing applications.
Some of the scenarios I can imagine:
A SAML IdP can leverage OpenID as an authentication source. This is addressed in SAML as "proxying". This might be done by hiding the details from the SAML SP, treating all OpenID sources as a single SAML IdP, and mapping OpenID identities either through links or transformations into familiar SAML-friendly attributes or subject identifiers. A challenge here is what to do about "ahead of time" provisioning, if knowing somebody's OpenID can't be used to predict the identifier the application will be getting. Another issue is discovery, since a naive approach might lead to a multiple hop selection of one IdP followed by an OP.
The OpenID information might also be passed through the gateway and carried in some new SAML form, so that the application can handle the OpenID identifier directly when needed.
Or the gateway might be replaced by a more capable SP stack that handles both SAML and OpenID (and possibly other protocols), in which case the software itself may need to know how to represent the different types of users. The issues there should be largely the same as in the gateway case, but it makes discovery less likely to cause "new" problems.
- (UCSF Library, Lucas Rockwell <lucas.rockwell@ucsf.edu>)
We would like to allow temporary and even long-term guests to authenticate to our wiki, which is used by faculty, students, researchers, and staff across campus. Most of the guests are temporary, as they might be a guest lecturer for one day, and then might need to post some content or comments on the wiki. These guests are most likely from a corporation or doctor's office, i.e., not from an InCommon institution.
As Scott points out, "ahead of time" provisioning is difficult, but once the user authenticates, the space admin (we use Confluence) could then add the guest to a particular space (perhaps by looking the user up by name or email address).
- (UC Berkeley, Dedra Chamberlin <dedra@berkeley.edu>)
At UC Berkeley, we have been getting an increasing number of queries from campus departments who would like to provide services to short-term guests. Most of them aren't concerned about LoA and just want to establish a lightweight profile for guests and keep a record of what they do with the service (how often they visit, what types of features
they use, etc). Examples include our Matterhorn/OpenCast developers, our campus Sakai team, a group implementing the Alfresco content management system, and managers of our campus SharePoint service. I'm sure there are others.
They would very much like to avoid the overhead of forcing these users to create an account before they log in, whether it be setting up an account in our identity management systems or creating an account with something like ProtectNetwork or openidp.org to accept Shibboleth or SAML2 assertions.
Many of the campus departments I deal with would like to allow guests to authenticate using any number of existing identifiers, from OpenID, Facebook account, Google account, etc. They would especially like to set up their apps to use a single authentication protocol (Shib or CAS), and still provide users the choice to use some existing external credential.