eduPerson and Federated K-12 Activities

InCommon/Quilts Pilot Group

February 27, 2014

Keith Hazelton

UW-Madison, InCommon/I2

eduPerson Is an Attribute Schema

• What is an Attribute Schema?

• A documented list of attributes with rules about their names, their values and their meanings

• eduPerson focuses on attributes about people in the context of teaching, learning and research

• When are attribute schema useful?– For institutional directories of person information in LDAP format

– For federated access scenarios…

Attribute Schema for Federated Access• Whenever an organization wants its members to get access to third

party digital resources and services

• In federated scenarios, the organization offers an Identity Provider (IdP) serving its members/users while third party resources and services are represented as Service Providers (SPs)

Federated Flows (A)

Request

Federated Flows (A)

Request

Redirect

Federated Flows (A)

Request

Redirect

Login Prompt

Federated Flows (B)

Authenticate

Federated Flows (B)

Assert Attributes

Authenticate

Federated Flows (B)

Deliver Content

Assert Attributes

Authenticate

Federated Flows (B)

Deliver Content

Assert Attributes

Authenticate

Interests of the Parties re Attributes

• Why the Service Provider (SP) wants user attributes– To determine if the user should be granted access to the online

service or resource

– (Often) To uniquely identify the user

– (Sometimes) To personalize the service or communicate with the user

• What the IdP is concerned about– To release information that facilitates the user’s access to online

resources to which they are entitled

– To limit the release of user information in the interest of privacy

Leveraging eduPerson in K-12 Scenarios

• There may be K-12 specific attribute needs, but re-use what you can from eduPerson

Leveraging eduPerson in K-12 Scenarios

• To support SP access control decisions

• Basic institutional affiliation: faculty, staff, student, alum,…– If faculty or staff or student, “member” is also asserted;

– eduPersonScopedAffiliation: member@foo.edu

– Caveat: The list of values is not extensible except through revisions to eduPerson specification: useful but not flexible

Leveraging eduPerson in K-12 Scenarios

• To support SP access control decisions

• If you need to specify other affiliations or groupings, use isMemberOf– Define a group and give it an identifier, put users in the

appropriate group(s)

– IdP Asserts isMemberOf values for each group the user belongs to

– isMemberOf: apCalculusAB:student

– isMemberOf: wi:madison:memorialhigh:sophomore

– Very flexible, but IdP and SP both need to agree on what to define, populate, assert

Leveraging eduPerson in K-12 Scenarios

• To support SP access control decisions

• Groups are sets of people

• An alternative conceptual approach: An entitlement or permission granted to a user

• eduPersonEntitlement: calendarApp

• eduPersonEntitlement: acme:contract:1432

• Very flexible, but IdP and SP both need to agree on what to define, assign, assert

Leveraging eduPerson in K-12 Scenarios

• Support pseudonymous access whenever possible– Groups and entitlements don’t identify individuals

• If the SP has a valid need to uniquely identify users– Determine if the SP needs service-specific and service-local user

records (think learning tool with performance tracking)

– If so, a provisioning model is probably required

– Institution will need to facilitate creation/update of user records at the SP side

– MUCH less standardized than federated attribute assertion model

– Out of scope for today

Leveraging eduPerson in K-12 Scenarios

• Support pseudonymous access whenever possible– Groups and entitlements don’t identify individuals

• If the SP has a valid need to uniquely identify users but provisioning is not required

• Pass identifiers in the IdP-SP attribute assertion

• Candidate identifiers from eduPerson– eduPersonPrincipalName

– eduPersonTargetedID

– eduPersonUniqueID (new in 2013 edition of eduPerson)

Leveraging eduPerson in K-12 Scenarios

• eduPersonPrincipalName as an identifier

• Example value: hazelton@wisc.edu

• Characteristics: globally unique, persistent

• Drawbacks: – Some institutions re-use values as people turn over; can lead to

inappropriate grants of access

– Reveals identity

Leveraging eduPerson in K-12 Scenarios

• eduPersonTargetedId as an identifier

• Example value: https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73

• Characteristics: globally unique, persistent, privacy preserving, not reassignable

• Drawbacks: – Not widely enough supported by IdPs

Leveraging eduPerson in K-12 Scenarios

• eduPersonUniqueId as an identifier

• Example value: 28c5353b8bb34984a8bd4169ba94c606@foo.edu

• Characteristics: globally unique, persistent, not reassignable

• Drawbacks: – New, no known IdP production support yet

– Reveals identity

Is a k12Person schema needed?

• k12GradeLevel has come up in conversation; Use as a hypothetical example

• Are there use cases? Which Service Providers might base access policies on grade level?

• Could be accomplished by agreeing on a shared set of group identifiers, one per grade level, and then passing appropriate values per user via the isMemberOf attribute

• If not, then a new schema needs to be created to carry k12GradeLevel

• MACE-Dir would be willing to host and facilitate this work

Recommendations

• Keep it simple– Focus on supporting one or a couple of real-world IdP/SP use

cases

– Identify the minimal attribute information needed to support the use cases

– Expect to iterate: design, implement, try, review, revise design…

– Don’t attempt to boil the ocean

• Encourage representative IdPs and SPs to collaborate and drive the work efforts– Common failing of schema efforts has been to drive solely from

the IdP side

References and Links

• eduPerson– http://software.internet2.edu/eduperson/internet2-mace-dir-edup

erson-201310.html

• isMemberOf– http://macedir.org/specs/internet2-mace-dir-ldap-group-members

hip-200507.html

• InCommon Federation Attribute Overview– http://www.incommon.org/federation/attributes.html

• InCommon Federation Attribute Summary– http://www.incommon.org/federation/attributesummary.html