1. VO Identity, Attributes, and Infrastructure: Some Basics

2. 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 things I want people to take away from this: the tools are out there, in varying levels of maturity, to enable better collaborations. At the end of the day, it’s all about using those tools, using attributes, taking advantage of federation activities, to do scalable access control.

3. 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
The good, the bad, and the ugly

4. SAML federations worldwide - scope

5. SAML federations worldwide – a bit of size
Some countries have a disproportionate number of SP and IdP, thanks to full government support (see the UK, SWITCH)

6. 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.
We are already starting to see aspects of this in the world today, though there are certainly still gaps as VO struggle with what to base their access control on – federated identity or social identity.

7. 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

8. 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
Higher bar to entry in to a collaboration, especially if the home institution is not in a federation

9. 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
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…

10. 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
Some interesting integrations recently suggest best practices

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

12. Attributes Federationperson Eduperson The Classics
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

13. 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…

14. 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?

15. 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
The terminology differs somewhat between the federated identity and the social identity worlds, but you can certainly see a theme in concepts

16. 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.

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

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

25. Good theory, but what does this really look like?
pubmed - nih research/collaboration
See in particular the login and discovery services on these sites, and how for some, it doesn’t even seem like you are logging in – your browser is passing along the appropriate cookie that says you were already authenticated against the appropriate service. SSO.

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