Federated Administration:The Cutting Edge

Topics

Federations: The Basics• Business drivers and the basic model• Technical Considerations and the marketplace• Policy Considerations

A Leading Edge Corporate Experience – Bob Chmura• Liberty Alliance• General Motors

A Leading Edge Public Experience• Shibboleth and InCommon • International federations and inter-federation issues

Where this may lead…open discussion

Unified field theory of Trust

Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc.

• Passports, drivers licenses • Future is typically PKI oriented

Federated enterprise-based; leverages one’s security domain; often role-based

• Enterprise does authentication and attributes• Federations of enterprises exchange assertions (identity and attributes

Peer to peer trust; ad hoc, small locus personal trust• A large part of our non-networked lives• New technology approaches to bring this into the electronic world.• Distinguishing P2P apps arch from P2P trust

Virtual organizations cross-stitch across one of the above

Federations Associations of enterprises that come together to exchange

information about their users and resources in order to enable collaborations and transactions

Enroll and authenticate and attribute locally, act federally.

Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings

Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision.

Several federations now in construction or deployment

Business drivers - corporate

Need to link consumer identities among disparate service providers

Link corporate employees through a company portal to outsourced employee services transparently

Allow supply chain partners to access each others internal web sites with role based controls

Business drivers – R&E

Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so

Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then

Federate (multilateral) those enterprise deployments with interrealm attribute transports, trust services, etc. and then

Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we

Be cautious about the limits of federations and look for alternative fabrics where appropriate.

Requirements for federations

Federation operations

Federating software• Exchange assertions• Link and unlink identities

Federation data schema

Federation privacy and security requirements

Non web services can also leverage federations

Federating Software Comparison

Liberty Alliance • V 1.1 of their functional specs released; 2.0 under discussion• Federation itself is out of scope• Open source implementations not emphasized• Current work is linked identities

Shibboleth• V1.2 released; 1.3 and 2.0 under development• Most standards-based; pure open source in widening use

• Current work is attribute release focused; linking identities in 2.0.• Can Shibboleth and Liberty converge? SAML 2.0 is key

WS-*• Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem

space, but which need to closely interact with each other to do so.• Standards process and IPR issues uncertain• Will need considerable convention and detail to resolve into a working instantiation

• Can Shibboleth/InCommon interoperate with WS-*? Under active discussion with Microsoft

Policy Basics for federations

Enterprises that participate need to establish a trusted relationship with the operator of the federation; in small or bilateral federations, often one of the participants operates the federation

Participants need to establish trust with each other on a per use or per application basis, balancing risk with the level of trust

Participants need to agree on the syntax and semantics of the information to be shared

Privacy issues must be addressed at several layers

All this needs to be done on a scalable basis, as the number of participants grow and the number of federations grow

Federal guidelines of relevance

NIST Guideline on Risk Assessment Methodologies

NIST Guideline on Authentication Technologies and their strengths

Federal e-Authentication

A Leading Edge Corporate Experience

Public Sector:Shibboleth and its federations

Shibboleth status

InCommon• Uses• Management• Policies• Shared schema

Other Shibboleth-based federations

Interfederation issues

Shibboleth Status

Open source, privacy preserving federating software Being very widely deployed in US and international universities Target - works with Apache(1.3 and 2.0) and IIS targets; Java

origins for a variety of Unix platforms. V1.3 likely to include portal support, identity linking, non web

services (plumbing to GSSAPI,P2P, IM, video) etc. Work underway on intuitive graphical interfaces for the powerful

underlying Attribute Authority and resource protection Likely to coexist well with Liberty Alliance and may work within the

WS framework from Microsoft. Growing development activities in several countries, providing

resource manager tools, digital rights management, listprocs, etc. http://shibboleth.internet2.edu/

The Point of Privacy

Kudos for Shibboleth!

Liberty Alliance Has Missed the Point eWeek November 24, 2003 By  Jim Rapoza  http://www.eweek.com/article2/0,4149,1396027,00.asp

What I'd like to see the group do is add more mechanisms to make it easy for third-party developers to create tools that give users total control over how their data is shared. A good model for this is the Internet2 group's Shibboleth ID management specification, which was designed mainly for academic institutions. In Shibboleth, users have built-in controls that give them final say over how their data is controlled.

Federated administration

O

TO

T

T T

A CMCM A

VOVO

T

Campus 1Campus 2

Federation

Shibboleth-based federations

InQueue

InCommon

Club Shib

SWITCH

NSDL

------------------------------------

State networks

Medical networks

Financial aid networks

Life-long learning communities

InCommon federation

Federation operations – Internet2

Federating software – Shibboleth 1.1 and above

Federation data schema - eduPerson200210 or later and eduOrg200210 or later

Became operational April 5, with several early entrants to help shape the policy issues.

Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon

http://incommon.internet2.edu

InQueue Origins2.12.04

Rutgers University

University of Wisconsin

New York University

Georgia State University

University of Washington

University of California Shibboleth Pilot

University at Buffalo

Dartmouth College

Michigan State University

Georgetown

Duke

The Ohio State University

UCLA

Internet2

Carnegie Mellon University

National Research Council of CanadaColumbia UniversityUniversity of VirginiaUniversity of California, San DiegoBrown UniversityUniversity of MinnesotaPenn State UniversityCal Poly PomonaLondon School of EconomicsUniversity of North Carolina at Chapel HillUniversity of Colorado at BoulderUT ArlingtonUTHSC-HoustonUniversity of MichiganUniversity of RochesterUniversity of Southern California

InCommon Uses

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

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

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

InCommon Management

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

Governance • Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry

Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR).

• Project manager – Renee Frost (Internet2)

Membership open to .edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc…)

Contractual and policy issues being defined now… Likely to take 501(c)3 status in the long term

Trust pivot points in federations

In response to real business drivers and feasible technologies

increase the strengths of Campus/enterprise identification, authentication practices

Federation operations, auditing thereof

Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof

Relying party middleware infrastructure in support of Shib

Moving in general from self-certification to external certification

Trust in InCommon - initial

Members trust the federated operators to perform its activities well

• The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties

• Enterprises read the procedures and decide if they want to become members

Origins and targets trust each other bilaterally in out-of-band or no-band arrangements

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

InCommon Trust - ongoing

Use trust Build trust cycle

Clearly need consensus levels of I/A

Multiple levels of I/A for different needs• Two factor for high-risk• Distinctive requirements (campus in Bejing or France, distance ed,

mobility)

Standardized data definitions unclear

Audits unclear

International issues

Balancing the operator’s trust load

InCommon CA• Identity proofing the enterprise• Issuing the enterprise signing keys (primary and spare)• Signing the metadata• Could be outsourced

InCommon Federation• Aggregating the metadata• Supporting campuses in posting their policies• Less easy to outsource, especially the organic aspects

InCommon Federation Operations

InCommon_Federation_Disaster_Recovery_Procedures• An outline of the procedures to be used if there is a disaster with the InCommon

Federation.

Internet2_InCommon_Federation_Infrastructure_Technical_Reference

• Document describing the federation infrastructure.

Internet2_InCommon_secure_physical_storage• List of the physical objects and logs that will be securely stored.

Internet2_InCommon_Technical_Operations_steps• This document lists the steps taken from the point of submitting CSR, Metadata,

and CRL to issuing a signed cert, generation of signed metadata, and publishing the CRL.

Internet2_InCommon_Technical_Operation_Hours• Documentation of the proposed hours of operations.

InCommon CA Ops

CA_Disaster_Recovery_Procedure_ver_0.14 • An outline of the procedures to be used if there is a disaster with the CA.

cspguide • Manual of the CA software planning to use.

InCommon_CA_Audit_Log_ver_0.31 • Proposed details for logging related to the CA.

Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compromise_ver_0.2

• An outline of the procedures to be used if there is a root key compromise with the CA.

Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61 • Draft of the PKI-Lite CPS.

Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21 • Draft of the PKI-Lite CP.

Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federation_System_Technical_Reference_ver_0.41

• Document describing the CA.

InCommon Key Signing Process 2. Hardware descriptions

        a. Hardware will be laptop and spare laptop with no network capabilities, thumb drive, CDRW drive, media for necessary software 3. Software descriptions         a. OS, OpenSSL, CSP, Java tools for meta data 4. Log into computer 5. Generation of the CA Private Root key and self-signing 6. Generation of the Metadata signing key 7. Generate CSR for Internet2 origin 8. Signing of new metadata sites and trusts files 9. Backup copies of all private keys and other operational backup data are generated. 10. Verify CD's and MD5 checksum 11. Write down passphrase and put in envelopes and sign envelopes 12. Securely store CA hardware and contents of local safe in safe 13. Log that these actions occurred on the log in safe and then close and lock the safe 14. Put thumb drive into secure db and copy data onto secure db 15. Take private key password archive and other contents to Private Key Password safe deposit box and record in log that this was done. 16. Take operational data archive to Operation Data safe deposit box and record in log that this was done.

InCommon Process Tech Review

As a technical review group, we, the undersigned, reviewed the processes and the following components documenting the operations of InCommon, and discussed them with the Internet2 Technical and Member Activities staff. To the best of our knowledge and experience, with no warranty implied, we believe the operational processes and procedures Internet2 provided are acceptable to begin the operations of InCommon.

• Scott Cantor, OSU• Jim Jokl, UVa• RL Bob Morgan, UW• Jeff Schiller, MIT

The Research and EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clustersOther

potential USR+E feds

State of Penn Fin Aid Assoc

NSDL

Slippery slope- Med Centers, etc

Indiana

International Activities

International eduPerson and object class registry

Swiss Shibboleth-based Federation (SWITCH-AAI)

UK scaffolding• JISC issued solicitation extending our NMI-EDIT work; see (

http://www.jisc.ac.uk/c01_04.html)• Working on virtual organizations, digital rights management, etc• Federation in the works

Australian interest• Planning a solicitation based on our work• Widespread use of Shibboleth and development of GUI’s

Upper Slaughter, England

International federation peering

Shibboleth-based federations being established in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others

International peering meeting slated for October 14-15 in Upper Slaughter, England

Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function

Leading trust to Slaughter…

Next Steps

Federated software alignment and interoperability

Fully establishing persistent federations

End-user ARP management tools (Autograph)

Coordination of federation policy underpinnings

Escalating levels of trust