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

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.

• 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 • http://www.vivoweb.org/

VO Assessment Tool

• Culture and management • Community – outreach, admin, etc• Users, Guests, and Contributors• Application Requirements• Access Control and Profiles• Existing Middleware infrastructure• https://spaces.internet2.edu/display/COmanage/

CO+Requirements+Assessment

Good theory, but what does this really look like?

• pubmed - http://www.ncbi.nlm.nih.gov/pubmed

nih research/collaboration - https://federation.nih.gov/FederationGateway

http://www.cilogon.org

https://spaces.internet2.edu/display/OpenID/Home

http://www.nasdaq.com

http://www.research.gov

http://www.educause.edu/

https://atlases.muni.cz/en/index.html

Wrapping up

• Tools are out there – decide what is appropriate for your VO

• Attributes are Important

• It all comes down to scalable access control