VO Identity, Attributes, and Infrastructure: Some Basics

Topics Quick terminology and reference model Attributes of attributes VOs, Identity and Access Control Assessment tools VO authentication/authorization Demo of real world examples

The Current World A rapidly growing, maturing federated identity infrastructure, increasingly integrated with federal identity and security initiatives A peered set of trust anchors (IGTF) that provided X.509 certificates to a number of virtual organizations and shared science resources Ad hoc ssh keys being shared Proliferation of usernames/passwords, with accompanying security implications Widespread usage of shared accounts, with accompanying audit and security implications A set of theoretically interoperable OpenID providers serving large masses of social and low-risk applications Non-scalable access control mechanisms

SAML federations worldwide - scope

SAML federations worldwide – a bit of size

The evolved model The trust infrastructure An international peering of SAML R&E federations, with common attributes and LOA, with some careful integration of other identity approaches (e.g. OpenID). Privacy preserving real time interrealm authentication and attribute exchange The collaboration/VO IdM overlay Services that provide integrated VO identity and access management to both domain and collaboration apps Leverages trust infrastructure, enterprise and VO attributes, etc.

Internet identity Two forms of Internet identity have experienced exponential growth in the last few years Federated identity leverages organizational identity, rich attributes and multiple levels of assurance Social identity, represented by Google, MSN, Yahoo!, AOL, Facebook, etc. provide convenient and lightweight identities for many popular sites Activities are moving beyond web applications, national borders, and beyond vertical sectors into ubiquity

Why (not) federated identity? + Not everyone can have one Home institutions do the vetting of the individual Federations establish a certain minimum level(s) of assurance Federation is seen as institutionally hard but can actually save the institution money and its users time − Not everyone can have one Higher bar to entry in to a collaboration, especially if the home institution is not in a federation

Why (not) social identity? + Everyone can have one Do not need to rely on home institutions to “do the right thing” if Google, Facebook, Twitter already have accounts ready − Everyone can have one No assurance of identity; little confidence in authentication Higher burden on the individual to keep info such as home institution and research area up to date (if that’s important to the VO) Extensive conversation about trust/security/privacy issues – OpenID was not created with a trust framework in mind Don’t interoperate and Facebook doesn’t play with others…

Integration of forms of Internet identity The trick is to use the right identity for the community being served, the needs being served and the risks of exposure For the official work of the researcher, domain, collaboration, administration, federated identity offers the security, privacy, and roles needed For the outreach work of the research, for the stateful access to public materials, etc., OpenID supports the general audience and simple technology

Attributes are important They define access control They provide the handle for further automation They are a useful taxonomy for identity information

Attributes Federationperson National level info – identifiers, locations, languages, etc. Not for InCommon, yet Eduperson Authenticated member of ePPN, ePTId, affiliation, primary affiliation, entitlements The Classics Orgperson –Inetorgperson – names, address, physical addresses, phone numbers, faxes, titles, etc

Attributes and the real world Regardless of which standard… They don’t necessarily get populated They get improperly updated The vocabulary doesn’t stay controlled It is getting better…

Scalable access control via attributes Allows us to avoid the pain of… Dealing with access control on a per application level Dealing with access control on a person-by-person level Think about the workflows Do you need to have citizenship established before further access is granted? Do you need particular training to be completed before further attributes are assigned?

Federated identity terms (Shibboleth/SAML) IdP – identity providers Provides authN, basic attributes SP – service providers/relying parties (RP) Consumes attributes from IdPs (maybe several) to make access control decisions Federation Collection of IdPs and SPs with a federated operator that has established a legal basis for trust Addresses policies, practices, indemnification, incident handling, schema, etc. Sources of authority Definitive source of assigning values to attributes Can be a role at the institution or in the VO

Social identity terms (OpenID) End-user The entity that wants to assert a particular identity. Identifier or OpenID The URL or XRI chosen by the end-user to name the end-user's identity.URLXRI OpenID provider A service that specializes in registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services). Relying party The site that wants to verify the end-user's identifier; other terms include "service provider" or the now obsolete "consumer". User-agent The program (such as a browser) used by the end-user to communicate with the relying party and OpenID provider.

Other important Internet identity concepts Addressing non-web apps OAuth Project Moonshot and the IETF Abfab (“Application Bridging, Federated Authentication Beyond”) WG User attribute management For privacy and consent For scalability in use Discovery Interfederation and metadata exchange

Virtual Organizations Multi-institutional, usually multi-national collaborations Frequently centered on unique instruments (e.g. CERN, Sloan), data repositories (e.g. medical records, economic data), etc Examples: hard sciences - LIGO, ATLAS, NEON, OOI, iPlant social sciences and humanities - Bamboo, CLARIN Use standard collaboration tools and domain tools, often in an integrated fashion SSH to manage an instrument that populated a DB that a web browser accesses

VOs are… International by nature A less privileged crust than enterprises Some VOs are deep first and then wide NEON Some are as much wide as deep iPlant Some are mostly wide ESWN

VOs and Identity Management Permit or deny access control to wiki pages, calendars, computing resources, version control systems, domain apps, etc. Add or remove people from groups Create new subgroups, identify overlapping memberships, etc. Add people to mailing lists, wikis, etc Ad hoc calendaring Create and delete/archive users, accounts, keys Identify group membership on a given date Usage reporting

VO IdM versus Enterprise IdM Both may be authoritative for certain information about individuals, however… Enterprise IdM will get that authoritative data from centralized sources of record such as PeopleSoft, Kuali VO will create the information through internal processes or user input Examples: Enterprise IdM = Name, institutional affiliation VO IdM = VO group membership, VO reporting

Integration of identity and access control Identity and access control (groups) need to integrate across three science environments Command-line-managed instruments generate data feeds that populate data bases Using web browsers, scientists access the database, mark events, set data feeds, etc. Other communities come in through science gateways and portals Federated identity and domestication of applications is needed Automated provisioning and deprovisioning a big win

Single Profile As VOs get more data-centric in nature, profiles are the automated way to match users with new data sources, and a simple access control mechanism The controlled vocabulary/ontology aspects of profiles needs active management tools as well as storing the profiles and managing releases. Some of the new NSF data nets are using multiple profiles; single profile is the next single sign-on…. VIVO is an important building block for answers here

VO Assessment Tool Culture and management Community – outreach, admin, etc Users, Guests, and Contributors Application Requirements Access Control and Profiles Existing Middleware infrastructure rements+Assessment

Good theory, but what does this really look like? pubmed - nih research/collaboration

Wrapping up Tools are out there – decide what is appropriate for your VO Attributes are Important It all comes down to scalable access control