University of Illinois at Urbana-Champaign National Center for Supercomputing Applications COI Identity Management and Federation: Design Issues, Process, and Progress Jim Basney Tom Scavo Von Welch

National Center for Supercomputing Applications Identity Management (IdM) Identity management is administration of identifiers and attributes (i.e. policy) regarding entities and the assertion of such between entities. Provides the basis for authentication and, in combination with governance, authorization.

National Center for Supercomputing Applications Identity Federation (IdF) Federated identity (IdF) is the sharing of identity and attributes across security domains. –“Authenticate Locally, Act Globally” IdM is about Technology IdF is about Policy

National Center for Supercomputing Applications IdM relationship to Governance IdM/IdF provides OOI entities with a persistent identifier and a set of attributes, and mechanisms by which to deliver those to other entities. The governance system then renders authorization decisions based on those identifiers, attributes, and relevant policy.

National Center for Supercomputing Applications Motivation for IdM/Authentication To authorize –Often don’t care identity except as binding to attributes For audit –E.g. incident response –Want binding to contact information and “real world identity” (sometimes for law enforcement) For metrics –How many users have we served? –From what communities, universities, etc.?

National Center for Supercomputing Applications What identities do we manage? People Applications running on a user’s behalf Servers/Services –Becoming more the latter than the former Data –Either at rest or in motion (messages) –Integrity, timeliness, source

National Center for Supercomputing Applications Issues in Identity Management to Consider

National Center for Supercomputing Applications Web Browsers vs Thick clients Conceptually similar But very different to implement and deploy A key decision for security in general - doing both is almost twice the work Browsers make for a nice client platform –Easy GUI, ubiquitous –In terms of security provide rich but rigid functionality Thick clients can do whatever you want –Just have to implement and maintain it

National Center for Supercomputing Applications NIST E-Authentication Guidelines – Aspects of Authentication Token type –What the user has. E.g. password, private key, token, fingerprint… Identity proofing –The vetting process to bind the token to an identity Remote Authentication mechanism –The protocol used to verify proof of token Assertion mechanism –Used to communicate result of authentication to remote parties –E.g. SAML, cookies

National Center for Supercomputing Applications Attributes vs Identifiers Attribute federation often has a different topology than Identity federation AAs often different than identity authorities –The folks who authenticate your users don’t know everything about them –VOs are prime example Third-party & commercial Idps exist for Shibboleth

National Center for Supercomputing Applications Semantics Attribute and Identity semantics are an issue What exactly does a “member” mean? Is a retired faculty a member of a university? A student showing up next Fall? Is the identity persistent? Can it be reassigned when someone leaves? Is it private?

National Center for Supercomputing Applications Delegation: Dealing with N-tier E.g. User makes a request of a front-end service which uses back-end service to complete request Two models The trusted front-end service –User authenticates and then is vouched for –Often easiest to implement and deploy –Lose end-to-end trust and information Delegation –Explicit delegation from user to front-end service –Specification of limited delegation is still open issue –E.g. RFC 3820: X.509 Proxy Certificates

National Center for Supercomputing Applications Id Federation Lessons Learned Based on our development… –MyProxy, GridShib, GSI, RFC 3820 and deployment experience. –TeraGrid PKI, LTER, LSST, DoEGrids… Putting IdF system on a good user database is easy What is hard? Maintaining the user database Applications like to assume they know their users. Controlling policy run-away… Standards are a treadmill –X.509, SAML1, SAML2, OpenID… –Need to put a stake in the ground and go Finding the Security vs Usability sweet spot –E.g. Short-lived vs long-lived credentials

National Center for Supercomputing Applications IdF Deployment Process Identify the entities being federated –Derived from use cases and requirements –Users and Resources Select technologies based on requirements –Probably more social/political issues here Identify the stake holders for those entities –PIs, Security Officers, Funding Agencies, etc. Find the Policy Sweet Spot –Identify and address social, political and technical issues –Define just enough policy to satisfy everyone

National Center for Supercomputing Applications An X.509 IdF Example: TeraGrid TeraGrid CAs present TG users –Used both internal and external to TeraGrid –Some sites have local CA –NCSA CA serves all TeraGrid users Resource Providers (RPs) agree on trusted Certificate Authorities (CAs) –Internal and external to TeraGrid: Leveraging International Grid Trust Federation TG users manage binding of X.509 certificates to accounts –I.e. account linking Use Attributes flow from TG User DB to RPs

National Center for Supercomputing Applications COI IdM/IdF Activities to Date Refining COI models for IdM/IdF High level OOI Idm & Governance driver: A scientist is trying to setup up a facility out of resources (instruments, computing capabilities, storage) spread out over a variety of authority domains. Analyzing OOI documents and deriving relevant IdM/IdF use cases/requirements –Direct use cases for Idm are rare, usually they are component of another use case

National Center for Supercomputing Applications OOI Documents analyzed for Use Cases with Idm component ORION Cyberinfrastructure Concept of Operations (Version 0r ) Device Life Cycle Concept of Operations for Device Alpha (Instrument Life Cycle Concept of Operations v1r00.pdf) OOI Cyberinfrastructure Architecture & Design: OV-5 Operational Activity Model (OV5.doc) CI System Requirements Document ( CI-SRD-1.4- edited.doc) –Has requirements against which we will reconcile. OOI Domain Model ( OOI-DomainModel-draft.pdf) –Source of terminology OOI COI Prototype ( COI_Early_Prototype.ppt) OOI CI Design Overview & Security Options (Security CIIO.pdf) Underlined are significant sources of Idm Use Cases

National Center for Supercomputing Applications Examples OOI Idm Use Cases An OOI user creates a personal page on the OOI web portal. An OOI user subscribes to a data stream. –The user provides some information how the data will be used. –The user obtains a data subscription token for the desired data stream. –The CI associates the user's identity and contact information with the subscription token. –The user associates a modeling application with the data stream via the subscription token. –[The ConOps document says the user edits the subscription token, but this violates the integrity of the token.] –The modeling application executes whenever a new data resource is received from the data stream. –The modeling application submits the subscription token every time it accesses the data stream. –If a new data resource is received while the application is running, the data are cached so that the application can access the data during a subsequent execution cycle. An OOI user creates a Virtual Laboratory (VL) and vouches for prospective VL members. –An OOI member credential is required to create a VL. (A provisional credential is not sufficient.) –The VL owner provides the names and addresses of invited VL members. –The CI sends an invitation (with a link) to join the VL. An application subscribes to a data stream. –The user reconfigures the application to receive a notification when a new data source comes on line. –The application parses the Resource Descriptor and determines the relevancy of the new data source. –The application subscribes to the data stream by sending a message to the CI. –The CI issues a tentative subscription token to the application pending user review. Etc.

National Center for Supercomputing Applications Example Derived IdM Requirements OOI accepts two types of identity credentials, strong credentials and weak credentials. –A strong credential is a long-lived credential. –A weak credential is a short-lived credential. OOI strong credentials are managed by a trusted third party. –Multiple external credential issuers must be supported. –Identity verification is required to obtain a long-lived member credential. –A strong identity vetting process must be defined (e.g., International participants must present a passport to obtain a long-lived credential). OOI weak credentials may be managed by OOI or by a trusted third party. –New users may obtain weak credentials by invitation from an OOI user possessing a long-lived, OOI member credential. OOI administrators require identifying and contact information (name, phone, etc.) for all users accessing OOI resources so that rogue users are quickly traceable to their true identity and can be prevented from harming the system or its operations. Etc.

National Center for Supercomputing Applications Next Steps Define refined IdM/IdF domain models –Linked with Governance and broader COI work –Leverage SAML/Liberty for non-science requirements

National Center for Supercomputing Applications Next Steps (cont) Map models to relevant standards and implementations –Leverage IdF/campus infrastructure as much as possible Some relevant technologies… Authentication: –Shibboleth: Web Browser IdF/SAML –PKI/GSI, MyProxy, GridShib: Thick-client IdF Delegation: –RFC 3820 Proxy Certificates: Delegation for PKI Policy Management: –Grouper, Signet, CoManage: Shibboleth-based VO management

National Center for Supercomputing Applications Thank you Questions?