Jack Suess, CIO University of Maryland, Baltimore County April 5, 2009

What’s the Problem?

Shibboleth Federations InCommon Federation 2

       Multiple usernames and passwords for users Multiple copies of personal data held by third parties Duplication of effort across multiple institutions Service and resource providers having to interface with multiple systems Difficulty in sharing resources between institutions Anytime, anywhere access to resources Compliance with legislation (FERPA, GLB …)

 Scaling  Enabling identity holder to authenticate  Enabling service provider to control authorization  Providing security and privacy  Ensuring accuracy and timeliness of account and identity data

 Internet2 partnered with Middleware Architecture ◦ Committee for Education (MACE) Leading international identity architects  ◦ Ongoing work in the great challenges of digital ◦ identity Extending access beyond an organization to facilitate ease of use and collaboration while maintaining security and privacy  Shibboleth Single Sign-on and Federating Software  InCommon Federation Among other things….

 Open source standards-based web single sign-on package (supports SAML v1.1, SAML v2)  Supports the Federated Identity model ◦ Identity Provider (IdP) authenticates the browser user and provides Attribute Assertions describing the user ◦ Service Provider (SP) validates the Assertions, makes an Access Control decision, and provides Resources ◦ Each player identified by a unique entityID value  Leverages local identity management system 7

     Enables access to both campus and external applications Protects users’ privacy Helps your service partners Integrates well with other SAML2 software Adoption by 20+ other Higher Education/Research federations around the world 8

       Access Application/Service Provider Site Identify Home Site Redirect to Home Site Shibboleth IdP Authenticate locally IdP determines which attributes to release Redirect back to Application, carrying Attribute Assertions SP site uses Assertions to determine access rights, and to personalize 9

Identity isn’t always released ◦ Elsevier Science Direct – license number and opaque ◦ ◦ identifier for personalization (optional) Microsoft Dreamspark – affiliation Apple iTunesU – course number But identity is needed by some ◦ WebAssign – name and course number Defined in eduPerson schema and increasingly elsewhere

The Challengin g Way

Home

Circle University [email protected]

Dr. Joe Oval Psych Prof.

SSN 456.78.910

Password #1 ?

?

?

?

Service Providers

    A group of member organisations who agree to a set of rules An independent body managing the trust relationships between members ◦ ◦ End user organisations ◦ Act as identity providers (IdPs) and optionally service providers (SPs) Authenticate end users Release information (attributes) about individuals to service providers Service and resource providers (SPs) ◦ Accept information (attributes) and use to authorize (or not authorize) access

 Common data/Attributes to exchange  ◦ ◦ ◦ ◦ Shared technology, policy, process Rules of engagement Information about how to connect Specifies accuracy, integrity, and use of attributes Problem resolution  Registration mechanism for members  Maintain member information  Trouble shooting, ongoing development

The Federated Way

!

Home

Circle University [email protected]

Dr. Joe Oval Psych Prof.

SSN 456.78.910

Password #1

1. Single sign on 2. Services no longer manage user accounts & personal data stores 3. Reduced help-desk load 4. Standards-based technology 5. Home org and user controls privacy

The Role of the Federation

1. Agreed upon attribute vocabulary & definitions: member of, role, unique identifier, courses, …

Verified By the Federation Home !

Password #1

2. Criteria for identity management practices (user accounts, credentialing, etc.), privacy stewardship, interop standards, technologies 3. Trusted exchange of participant information 4. Trusted “notary” for all universities and partners

Verified By the Federation Verified By the Federation Verified By the Federation

 ◦ ◦ ◦ ◦ US Research and Education Federation www.incommon.org

Separate entity with its own governance Operations managed by Internet2 Members are degree granting accredited organization and their partners

   ◦ ◦ 135 members representing 2.8 million individuals.

◦ 96 higher education institutions, 6 government agencies or non-profit laboratories, and 33 corporations (public and non-profit) Agree to a common participation agreement that allows each to inter-operate with the others InCommon sets basic practices for identity providers and service providers. ◦ Focus so far on campus identity management processes and attributes 19 19

 National Science Foundation  ◦ National Institutes of Health Piloting InCommon Silver for NIST LoA 2 services  Research.gov

 TeraGrid

 Ease user account management  Higher security  Privacy maintained  Greatly reduced integration work for each service provider  Policy driven release of identity  Emerging tools provide option for user consent in real time, as attributes are released  Standards

 Accurate implementation of licence conditions  Users take better care of credentials  Organizations take better care of assertions  Information about individuals always up to date ◦ Authentication is performed by the IdP ◦ Can authorize just-in-time per institution, role, and/or entitlement or other characteristic  Reduced user support requirements

 Used by InCommon to exchange attribute information  Standard schema used in identity management systems across HE, not just in InCommon  Defined by MACE-Directories working group  New needs arising as service providers diversify

 InCommon Identity Assurance Profiles ◦ Bronze compatible with NIST Level of Assurance 1 ◦ Silver compatible with NIST Level of Assurance 2  Specifies criteria used to assess identity providers ◦ Identity Assurance Assessment Framework ◦ Written for and by HE community to enhance NIST 800-63 24 24

 A true standard of practice  An audit independent of campus IT  Additional legal addendum and fees   A Silver designation for the IdM system (or subsystem) A Silver attribute sent with each user’s attributes (Silver is per user per occurrence)  Being piloted

technically

with NIH & 3 campuses 25

Verified By the Federation InCommon Federal Compliant Assurance Levels Silver Bronze Silver InCommon Metadata By the

College A

Verified

IdP: name, key, url, contacts, etc.

SP1: name, key, url, contacts, etc.

SP2: name, key, url, contacts, etc.

University B

Affiliation

IdP: name, key, url, contacts, etc.

SP1: name, key, url, contacts, etc.

Title University C IdP: name, key, url, contacts, etc.

Partner 1 SP1: name, key, url, contacts, etc.

Partner 2 SP1: name, key, url, contacts, etc.

SP2: name, key, url, contacts, etc.

Partner 3 …

Silver Verified By the Federation Verified By the Federation

Steering Committee Advisors Lois Brooks, Stanford University – Chair Steve Cawley, University of Minnesota Joel Cooper, Carleton College Clair Goldsmith, University of Texas System Ken Klingenstein, Internet2 (ex officio), University of Colorado Tracy Mitrano, Cornell University Kevin Morooney, Penn State Chris Shillum, Elsevier Jack Suess, University of Maryland, Baltimore County Mike Teets, OCLC Renee Frost, Internet2, University of Michigan Norma Holland, EDUCAUSE (ex officio) David Wasley, retired, UCOP

Role

Manages the business and affairs of InCommon and its Federation, including oversight and recommendations on issues arising from the operation and management of the InCommon Federation .

RL "Bob" Morgan, University of Washington – Co-Chair Renee Shuey, Penn State – Co Chair Tom Barton, University of Chicago Scott Cantor, The Ohio State University Steven Carmody, Brown University Paul Caskey, University of Texas System Michael Gettes, MIT Keith Hazelton, University of Wisconsin – Madison Ken Klingenstein, Internet2/InCommon Steering Committee Mike LaHaye, Internet2 David Walker, University of California-Davis David Wasley, retired, UCOP

Role

Provides recommendations relating to the operation and management of InCommon with respect to technical issues.

Collaboration  InC-Library, InC-Student, InC-NIH, InC-Research, InC-Apple, Dreamspark National and International standards   Co-wrote SAML spec TAC members involved in WS-Fed, OASIS, Terena, ISOC, and Liberty Alliance and other standards and federation organizations Development  Interfederation, Privacy and Consent, Evolution of Federations

 ◦ Jack Suess [email protected]

 ◦ ◦ ◦ ◦ Resources http://www.incommonfederation.org

/ http://www.incommonfederation.org/assurance/ http://middleware.internet2.edu/ http://csrc.nist.gov/publications/PubsSPs.html