External Identity and Authorization in GENI

Topics Federated identity and virtual organizations ABAC Creating and transporting attributes Applying to GENI Demo

Federated identity Builds on deployed authentication services Identity Provider (IdP) services at universities etc. IdPs handle logins (single sign-on) and assert attributes Can supply roles, permissions, common attributes (name, organization, affiliations, citizenship, capabilities, etc.) Uses SAML and metadata (aka Shibboleth) International trust fabric now being deployed on Internet- scale, first in R&E but expanding to other sectors Greater than 150M world-wide, 5M US, exponential growth

Duke Shibboleth Identity Provider (IdP) HTTPS XMLRPC / SOAP Users and “hands-free” tools Web Service Portal (SP) Authenticated user identity Attributes for authorization

Virtual Organizations Research and scholarly efforts, sharing both domain and collaborative resources and tools. Typically cross-cutting institutionally and internationally, with high-profile participants. Often have education and outreach requirements Want to leverage both institutional and collaborative personas (the sum is greater than the parts) GENI and its clusters are nested VOs. GENI technologies may enable VO network capabilities

Advantages Institutions maintain the accounts (they do it anyway) Secure privacy-preserving login Single sign on (SSO) Expiration/revocation! Institutions can hold their users accountable Supplies attributes for access control (e.g., ABAC) Standard attributes (student, faculty, etc.) Groups: easy to create and maintain Course enrollment, research group, etc. Use COmanage for Virtual Organizations (e.g., GENI)

ABAC No fun to maintain 200K accounts Use federated identity Not much fun to maintain an access control list of 200K identities Use attributes Group membership is a good access control attribute Easy to create and maintain Easy for users to understand and administer Solves 80% of the use cases Finer-grain controls are needed for the rest

SFA observations (from an ignorant bystander) Move from v1 to v2 adds another option – external authn/z - to security built-in via X.509 identity and attribute certs V2 does a good thing but… Does not help integration, convergence, deployability, scale, robustness, etc. On what scales is it meso-scale? Devices? Experiments? Users? Can we fix things later with “another level of indirection?”

Duke’s Shibboleth IdP says: “The user is authenticated as a Duke professor who is a member of the group cs.geni.test”.

Code snipped from portal source: get session attributes.

Config snippet from the portal’s web.xml descriptor. It says: “let OIOSAML filter access to this Web portal” with the configured IdP bindings.

“Remove Chase from the group cs.geni.test”.

On next login, Duke’s Shibboleth IdP says: “The user is authenticated as a Duke professor who is not a member of any group.”

Allocation policy considers group membership attributes of requester (ABAC).

Attribute-Based Access Control (ABAC) This simple example illustrates ABAC. The attributes are asserted by an IdP. The resource broker policy trusts and understands attributes from this source. The policy uses the attributes to make a policy decision. Authorization Resource Control Shibboleth and ABAC work together.

A Few Points about SFA 2.0 SFA 1.0 Specified identity/trust mechanisms and attributes. SFA 2.0 Mechanisms of SFA 1.0 are optional They are instances of an open framework. Shibboleth+ABAC is SFA-compliant. SFA server policies may choose which IdPs and attributes to consider.

COmanage and GENI CO is a platform supporting the work of VOs, using enterprise tools (including Shib and Grouper) reassembled for VO use COmanage is a platform that allows federated identities to be gathered, assigned attributes and fed to applications Consistent identity and group management across apps Collaboration apps (wikis, listprocessors, IM, videoconferencing, file shares, etc) Domain apps (grids, ssh-based, etc.) Provides scalable, secure, federated, flexible A/A to apps A GENI cluster, or GENI itself, could be well-served on a COmanage instance

COManage Elements Dashboard (including invitation/registration) Shib SP GrouperSTS Shib IdP LdapPC / SPML provisioning Applications Data Store

Flows Dashboard (including invitation/registration) Shib SP GrouperSTS Shib IdP LdapPC / SPML provisioning Applications Data Store Users Portal/Gateway SP Collabmins (RA’s, PI’s, sysadmins, etc.) A/A A/AA/A

Sample Flows of attributes Enterprise Data Store Project comanage RelyingParty Enterprise

What’s in a COmanage data store Enterprise AttributesProject/VO attributes Federated IdPI groups Enrolled classesWiki editing permissions Display nameInstrument permissions CitizenshipVO certificates Enterprise affiliation…

Collabmin GUI

Demo 1 Using enterprise-based identity to assign GENI privileges Enterprise authentication Enterprise located groups Transported to portal by SAML, consumed and carried within ORCA

Demo 1 basics On the user side, Duke identities (PI’s, RA’s, students) are assigned ORCA permissions through standard Duke group management tools On the ORCA web portal side, Shib relying party code was added to the Java server. It consumes assertions from Duke Shib identity provider Those attributes are fed to an ORCA policy engine, which creates ORCA native credentials and sends them on Users going to the ORCA portal are redirected to authenticate at Duke (unless already authenticated)

Demo 2 Using enterprise identity and VO attributes to control ORCA Enterprise asserts identity VO asserts groups and privileges Integrated into the larger VO science and collaboration environment Permissions (fine-grain authz) also possible