wiki:GeniIdentityAndAttributes

Identity and Attributes

GENI requires a way of positively identifying experimenters and granting them access to tools and resources. Current control frameworks either maintain their own database of users or explicitly outsource this task to an identity provider. In addition to identifying experimenters, GENI needs information about attributes like institutional affiliation, project role, etc.

The GENI Software Architecture specifies some of how this should work. The GeniApi describes URNs and Certificates.

This page needs improvement, to provide a summary of the decisions made at the meetings described below.

GEC11 Engineering Meeting

At GEC11 there was an identity engineering meeting which discussed progress towards incorporating external identity providers in GENI.

Meeting Summary

Tom Mitchell discussed the goals of the Identity Management effort within GENI and provided an update since GEC 10. Briefly:

  • InCommon membership took longer than expected, but the GENI Project Office became InCommon members in July, shortly before GEC 11
  • A prototype identity portal has been built. It uses Shibboleth single sign on so it will be compatible with InCommon.
  • The prototype identity portal was federated with ProtoGENI to demonstrate the ability to create slices and allocate resources from an operational GENI aggregate manager.

Tom gave a brief demonstration of the prototype identity portal that showed the creation of a GENI certificate, a slice and associated slice credential, and then using the GENI certificate and slice credential to list resources via Flack at ProtoGENI's Utah site. Tom's slides are available on the session wiki page.

Ken Klingenstein discussed the state of federated identity management today and what's coming on the horizon for federated identity management in general, and InCommon in particular. Some of the key topics included Social2SAML gateways, attribute release and consent, non-web apps (SAML ECP), and collaboration management platforms. Ken also talked about implications for GENI: federated identity and ABAC, levels of assurance, and incident handling. Ken's slides are available on the session wiki page. Specifically, Ken made the point that GENI will probably have to confront these issues as it moves forward with federated identity management. Ken posed questions like:

  • What level of assurance will GENI aggregates and slice authorities require from identity providers?
  • How will GENI handle incident response?
  • How will attributes from identity providers be used in authorization decisions?
  • What attributes will be used for authorization, and who will be trusted to make this assertions?

Ken's slides are available on the session wiki page.

Proposed Next Steps

  • Continue to push InCommon membership forward
    • Publish Participant Operational Practices (POP)
    • Publish Service Provider Metadata
    • Negotiate For Attributes From A Few Institutions
  • Continue to develop the prototype identity portal
    • Proper certificate management
      • Protected signing key
      • Certificate Revocation List (CRL)
    • Programmatic access to some functions
    • Management/Operations integration
    • Integration with Federation/Clearinghouse concepts

GEC10 Engineering Meeting

At GEC10 there was an identity and attributes engineering meeting which discussed a proposal by Ken Klingenstein (Internet2) and Tom Mitchell (BBN) to incorporate external identity providers in GENI. Specifically, an InCommon compatible GENI portal was proposed to allow new GENI experimenters to authenticate using their existing institutional accounts. The meeting also discussed standardizing a set of identity attributes required for resource manipulation within GENI. Jeff Chase (Duke, ORCA) and Rob Ricci (Utah, Emulab/ProtoGENI) gave their perspectives on the proposal based on their experience as GENI control framework developers.

Community Agreement

  • Add external identity providers to GENI
  • GPO should build a prototype InCommon compatible GENI portal / slice authority
  • Agreed on an initial set of required identity attributes
    • Name
    • Institution
    • Affiliation
    • Email address
    • Phone number

Next Steps

  • GPO will build a prototype portal / slice authority that accepts InCommon logons and produces slice credentials
    • Build a portal
    • Become an InCommon service provider
    • Work with a few test institutions to get desired attributes from their identity providers
    • Federate with a few GENI Aggregates
  • Demonstrate this portal at GEC11
    • Pending group evaluation, expand this portal to other institutions and aggregates

Getting Involved

If you have questions or comments on the status of the authorization work, please email the GENI developers list (dev at geni.net) or Tom Mitchell (tmitchell at bbn.com).

Last modified 6 years ago Last modified on 10/31/12 13:41:23