Federated Security and the Federal Government

Ken KlingensteinDirector, Internet2 Middleware and Security

Topics

What and why federated AAI• Federate what?

The basic ingredients• Shibboleth and SAML• GridShib and WS-Fed • Federations, international deployments and InCommon, a US R&E federation…• Federated identity and the network control plane: security, allocation, etc.• Federated identity and virtual organizations

Work with the US government• The Federal e-Authentication Initiative• Phase 1/2 – Certifying Shib, Shaping Policy Issues, etc• Phase 3/4 – SAML 2.0 Profile, USperson deliverables, interfederation peering

What is easy / What is hard What does it mean to Magic

Authentication and Authorization Infrastructure

Authentication – provides positive proof, at several possible strengths, of identity

Authorization – assign permissions to use resources, from web sites to supercomputer access, digital content to parking spaces

Infrastructure means:• A reliable, robust, ubiquitous, service• Initially to the R&E community but with applicability to other vertical

sectors• National in character, but of service to multi-national virtual

organizations• Built on either central, hierarchical or federated, enterprise models

Key Issues for AAI

In authentication, the key issues are strength of authentication (identity proofing, delivery of credential, repeated use of credential) and privacy/secrecy

In authorization, the key issues are permissions to use resources, delegation, audit and privacy

In infrastructure, the issues are making it real, ubiquity, robustness, ability to support a wide range of needs and uses, and funding

Federated model

Enterprises and organizations provide local LOA, namespace, credentials, etc.

Uses a variety of end-entity local authentication – PKI, username/password, Kerberos, two-factor, etc.

Enterprises within a vertical sector federate to coordinate LOA’s, namespaces, metadata, etc.

Internal federations within large complex corporations have been “discovered”.

Privacy/security defined in the context of an enterprise or identity service provider

A federation of what?

A key issue for MAGIC

The NMI-I2 work is a federation of enterprises• Within a market sector (R&E, Federal agencies, etc.)• With a national context (security regulations, privacy laws, pride, etc.)

Others talk of other entities federating• Virtual organizations or Grid PMA’s• Applications running at multiple sites

– A federation of courses, data sets, etc…

• A federation of individuals

Why does it matter

Regulation• Strength of identity proofing and LOA• Audit and compliance capabilities

Ease of use

Where the users live and travel

Use cases that are enterprise centric

Scale

Industry trends

Federating Software

Shibboleth – an open source privacy preserving standards-based system

Liberty Alliance – large commercial standards group in federated identity management

Liberty and Shib have essentially converged around SAML 2.0, with Liberty Alliance moving into services and Shib being refactored and expanded

WS-* - MS (with IBM) “standards” that is slowly emerging, with some interoperability with SAML and Shib

Shibboleth

An architecture, consisting of both a payload definition (using SAML) of attributes and a set of privacy-preserving methods of exchanging such payloads.

A project that has managed the development of the architecture and code

A code package, running on a variety of systems, that implements the architecture.

(Note that other code sets are under development)

Shibboleth v1.3

Planned Availability -- July, 2005• Currently in beta

Major New Functionality• Full SAML v1.1 support -- BrowserArtifact Profile and AttributePush• Support for SAML-2 metadata schema• Improved Multi-Federation Support• Support for the Federal Gov’t’s E-authn Profile• Native Java SP Implementation• Improved build process

WS* Interop -- Status

Agreements to build WS-Fed interoperability into Shib• Contracts signed; work to begin AFTER Shib v1.3• WS-Federation + Passive Requestor Profile + Passive Requestor Interoperability

Profile

Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed; no further discussions

Devils in the details• Can WS-Fed-based SPs work in InCommon without having to muck up federation

metadata with WS-Fed-specifics?• All the stuff besides WS-Fed in the WS-* stack

What is GridShib?

NSF Middleware Initiative (NMI) Grant:“Policy Controlled Attribute Framework”

Allow the use of Shibboleth-transported attributes for authorization in NMI Grids built on the Globus Toolkit v4

2 year project started December 1, 2004 Participants

• Von Welch, UIUC/NCSA (PI)• Kate Keahey, UChicago/Argonne (PI)• Frank Siebenlist, Argonne• Tom Barton, UChicago

Why?

Attribute-based authorization has shown itself to be useful in large grids with far-flung participants in several types of roles

• Identity-based approach scales poorly

Shibboleth is well supported and becoming widely deployed

SAML is used by larger identity federation world, not just Shibboleth. Integrating SAML support into Grids opens the door to leveraging this large technology space

GridShib Integration Principles

No modification to typical grid client applications• Modifications only to Grid Services and security clients (e.g. grid-

proxy-init)

Leverage shibboleth’s attribute marshaling capability and release policies

Leverage strategic investment that campuses make in Identity Management operations

GridShib Progress

Developers hired February 2005 Substantial resolution of GridShib’s Shibboleth usage profile Shibboleth IdP plugin nearing completion

• Maps externally-issued X.509 identity certificates to local identifiers

SAML attribute marshaling in GT4 runtime nearing completion Common attribute format internal to GT4 runtime to support

access policies spanning SAML and X.509 PMI attribute sources

• Uses XACML Request Context

Initial GridShib release for closed alpha deployment• Readiness by end of June• Overlays GT 4.0 and Shib 1.3

Potential Early Adopters

Focused efforts to understand and evaluate potential use of GridShib in:

• caBIG, Cancer Bioinformatics Grid• UK eScience Grid • LOOKING, Laboratory for the Ocean Observatory Knowledge

Integration Grid• University of Southern California• University of Alabama at Birmingham• SURAgrid

Distributed Authorities

Grid Service

Session authentication

credential

Attribute Authority

Home Org

Virtual Org

Affiliated Org

Authorities

Grid user

Signet, Grouper

Project objectives

Priority 1: Pull mode operation• Globus services contact Shibboleth to obtain attributes about identified

user• Support both GT4.x Web Services and pre-WS code

Priority 2: Push mode operation• User obtains Shib attributes and push to service• Allows role selection

Priority 3: Online CAs• Pseudonymous operation• Integration with local authentication services

Timeline

December 1, 2004: formal start February 1, 2005: Developers on board and coding Mid-Summer 2005: closed alpha release

• pull model with user identified

Fall 2005: public releases• Production pull model with user identified• Beta push model with user identified• Implementation of simple policy description language• Targeting GT 4.1.x and Shibboleth 1.3

2006: Integration with online CAs

LDAP

Getting Attributes into a Site’s Attribute Authority

uid: jdoeeduPersonAffiliation: …isMemberOf: …eduPersonEntitlement: …

SIS

HR

On-site Authorities

Loaders PersonRegistry

GroupRegistry

GrouperUI

PrivilegeRegistry

Off-site Authorities

SignetUI

Attribute Authority

Core Business Systems

Shib/GridShib

using Shibboleth

Federations

Persistent enterprise-centric trust facilitators

Sector-based, nationally-oriented

Federated operator handles enterprise I/A, management of centralized metadata operations

Members of federation exchange SAML assertions bi-laterally using a federated set of attributes

Members of federation determine what to trust and for what purposes on an application level basis

Steering group of members sets policy and operational direction for federation

Federations redux

created to support community• interesting ones are multi-IdP, multi-SP• embodies agreements on many levels

– membership, technology, assurance, key mgt, legal, attributes, privacy, appropriate use, etc

facilitates member federated interactions• many potential sub-communities and their apps• operational support

– key/config distribution, IdP discovery, etc

• doesn't preclude non-fed arrangements

Federations happening

i.e., SAML-based (or similar) federations• in Europe, natural extension of HE NREN services

– Switzerland, Finland, Netherlands, UK, Spain, France, etc

• in US– InCommon Federation in higher ed

– also state-level planning, vertical apps such as student loan management

– US government E-Authentication Program

– also much non-fed or pre-fed deployment among fed members

InCommon federation

Federation operations – Internet2Federating software – Shibboleth 1.2 and above Federation data schema - eduPerson200210 or later and

eduOrg200210 or later Federated approach to security and privacy, with policies posted

by members in common formatsBecame fully operational 9/04; currently around 15 membersPrecursor federation, InQueue, has been in operation for about

two years and will feed into InCommon; approximately 250 members

http://www.incommonfederation.org

InCommon Members 7/1/05

Cornell University Dartmouth Georgetown University Ohio University Penn State University of California, Irvine University of California, San Diego The University of Chicago University of Rochester University of Southern California University of Washington University of California, Office of the President The Ohio State University University of California, Los Angeles Internet2 SUNY Buffalo Elsevier ScienceDirect OCLC WebAssign OhioLink - The Ohio Library & Information Network

InCommon Uses

Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.)

Institutions working with outsourced service providers, e.g. grading services, scheduling systems, software sales

Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.

(Shared network security monitoring, federal research trust peering, interactions between students and federal applications, wireless network access, peering with international activities, etc.)

InCommon pricing

Goals• Cost recovery• Manage federation “stress points”

Prices• Application Fee: $700 (largely enterprise I/A, db)• Yearly Fee

– Higher Ed participant: $1000 per identity management system

– Sponsored participant: $1000

– All participants: 20 Resourceproviderids included; additional resourceproviderids available at $50 each per year, available in bundles of 20

InCommon Management

Operational services by I2• Member services • Backroom (CA, WAYF service, etc.)

Governance • Steering Committee – drawn from CIO level leadership in the

community - sets policies, priorities, etc.• Project manager – Internet2

Contractual and policy issues were not easy and will evolve

Initially a LLC; likely to take 501(c)3 status in the long term

Trust in InCommon - initial

Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures• Enterprises read the procedures and decide if they want to become members• Contracts address operational and legal issues

Origins and targets establish trust bilaterally in out-of-band or no-band arrangements (using shared posting of practices)

• Origins must trust targets dispose of attributes properly• Targets must trust origins to provide attributes accurately• Risks and liabilities managed by end enterprises, in separate ways

– Collaborative apps are generally approved within the federation

– Higher risk apps address issues through contractual and legal means

Members Trusting Each Other:Participant Operational Practice Statement

Basic Campus identity management practices in a short, structured presentation

• Identity proofing, credential delivery and repeated authn• Provisioning of enterprise-wide attributes, including entitlements

and privileges

Basic privacy management policies• Standard privacy plus• Received attribute management and disposal

No audit, unclear visibility of policies

InCommon Progress

Relatively straightforward• Syntax and semantics of exchanged attributes (Eduperson)• Set up and operation of federation• Selling the concept and value

More challenging• Having applications make intelligent use of federated identity• Handling indemnification• Finding scalable paths for LOA components

Interfederation

an immediate consequence of federation• brand-new federations don't have well-defined boundaries or

service scopes• it's the Internet, we're all connected• many interesting SPs are global, e.g. Elsevier

Interfederation workshop, Oct 2004• Upper Slaughter, UK (a nicer walled garden?)• many countries, including CERN• many agreements on direction, future work

... but it's a nice garden

Interfederation models

parallel universes• members simply participate in many if needed• consistent with fundamental pairwise nature of app-level relationships• scaling, diversity not addressed

peering• transitive assurance, legal, policy, maybe ops• too tight a coupling?

league of federations?• some historical examples ...

Federal eAuthentication

Key driver for e-government, operating under the auspices of GSA

Leveraging key NIST guidelinesSetting the standard for a variety of federated identity

requirements• Identity proofing• SAML bindings• Credential assessment• Risk assessment

Technical components driven through the InterOp Labhttp://www.cio.gov/eAuthentication/

eAuthentication Key Concepts

Approved technologies

The Federal “e-Authentication Federation”

Credential assessment framework

Trusted Credential Service providers

Agency Applications (outward facing, agency to agency and agency to citizen…)

InCommon E-Auth alignment

promote interop for widespread higher-ed access to USG applications

• grants process, research support, student loans ...

process• project started Oct 2004, thru Sept 2005• compare federation models• propose alignment steps• validate with federation members, via concrete application trials• implement via next e-auth, InCommon phases

Validation steps

universities undergo trial by CAF• assess whether compliance is likely across HE• U Washington, Penn State, Cornell• pretty darned close: 50% all-OK, others do-able

deploy access to a real USG app• summer 2005• requires E-Auth acceptance of univs as CSPs• app will modify existing provisioning process• practical feedback to alignment recommendations

US person

motivated by InCommon desire for attribute-based authorization

modeled on Internet2 eduPerson spec

framework on which agency/app definitions can be built

not just SAML• generic information model, mapped to LDAP, SAML, XML

provisioning

ambitious? yes ...

Federations and PKI

The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term)

Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable – adding privacy (secrecy), ease of verification, addition of role, etc.

The analytic framework (evaluation methodologies for risk in applications and strength of credentials) and infrastructure developed for PKI is useful for federations.

The same entity can offer both federation and PKI services

A Few Other Items

Signet

Diagnostics

Integration

Virtual organizations

What’s It Mean For Magic

Federated identity• Get agencies to participate in “Fed-fed”• Assess the applications• Agree on LOA approaches• Build agencyPerson as a subordinate class to USPerson

Understand the tools and services becoming available to virtual organizations

• Virtual organization service centers• Registries

Trust-mediated transparency and other security issues