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: –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: 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: org/shibboleth!84e411ea-7daa-4a57-bbf6- b5cc52981b73 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: 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 – eduperson htmlhttp://software.internet2.edu/eduperson/internet2-mace-dir- eduperson html isMemberOf – membership htmlhttp://macedir.org/specs/internet2-mace-dir-ldap-group- membership html InCommon Federation Attribute Overview – InCommon Federation Attribute Summary –