Directories Update: Status & Next Steps Tom Barton, University of Chicago Keith Hazelton, University...

Directories Update: Status & Next Steps

Tom Barton, University of Chicago

Keith Hazelton, University of Wisconsin

9July 2003 AuthZ CAMP 2

Copyright Tom Barton and Keith Hazelton 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.


Outline

1. Current threads in MACE-Dir2. (SAGE)3. eduPersonXref

Pipe up with questions or comments at any time!!


MACE-Dir currents

Internet2/MACE working group on directoriesKeith Hazelton, WG Chair• eduPersonScopedAffiliation

– Will be included in next rev of eduPerson– Driven by Shibboleth needs– Syntax like eduPersonPrincipalName

• [email protected]• [email protected]• [email protected] (!?!)

– Raises problems about who is authorized to assert what• An “inter-realm metadirectory function”• A field full of rat holes and land mines…


MACE-Dir currents

• eduPersonAffiliation – Cautious and stringently limited expansion of controlled

vocabulary for• prospect• parent

– …and maybe no more than that– There’s value in having a local attribute with more values– … and value in agreeing across institutions on syntax &

semantics; but maybe not a single shared attribute– Upcoming survey of local practices for affiliation identifiers

and of fooEduPerson object classes more generally


MACE-Dir currents:Collaboration on Schema Work

• Person schema activities are flourishing– norEduPerson– funetEduPerson– swissEduPerson– DEEP survey questions on schema needs– &, of course, eduPerson– & further afield, WALAP activity in Australia– …& interest from East Asia heard at last JGN conference



• What to work toward?• (In order of increasing difficulty and decreasing probability of

success)– Agreement on a list of interesting attributes– Common syntax and semantics across schema for given attribute

type• A kind of inter-federation diplomatic activity

– Agreement on inclusion in a standard schema• eduPerson?• Next release of X.520?• Other candidates?

– Processes for ongoing schema coordination

• Even common syntax & semantics would boost interoperability in attribute mapping



• How will we do the work?• Internet2 is hosting a concentrated series of

conference calls to start in fall– Scheduled to accommodate Europe & US (one set of calls)– …and Pacific -- US (a second, parallel set of calls)

• Charter is to tackle the identified work items– Time permitting, move on to organizational object schema

• If successful, follow-ons on Dir -- AuthN/Z links possible


MACE-Dir currents

• Registration of attribute definitions– The problem: In contexts such as SAML assertions it is

desirable (necessary?) to carry attributes whose types are defined outside of SAML. So, a means to refer to these attribute types is needed.

– Potential solution: Registry of MACE-related attribute defs• urn:mace:dir:attribute-def references• Some way to find these – to be determined• Probably require docs defining XML representation of

eduPersonPrincipalName, eduPersonScopedAffiliation, eduPersonEntitlement to be referred to by the urn:mace:dir registration documentation


MACE-Dir currents

• isMemberOf– Indication of group membership by forward reference, i.e., a

mapping from member objects to groups– To be proposed to the ITU as an annex to X.520 and X.521– Raises question of how Internet2/MACE should relate to the ITU

• eduCourse– Course identifiers & schema for their storage in LDAP directories– Representation in Shibboleth ARQs & ARMs (an IMS profile?)– Work has moved to a new WG: MACE-courseID

• Grace Agnew (Rutgers), WG chair

• Privacy metadata– Gather practices in managing privacy via directory constructs and

produce food for thought white paper


MACE-Dir currents

• LDAP Recipe– To be revved with NMI R4 to describe

eduPersonScopedAffiliation and H.350 and reflect interesting practices in local affiliation & local person objectclasses

• Utilities– Look (Directory Service Agent performance monitoring tool)

• Fait accompli

– LDAP Analyzer (LDAP Recipe compliance tool)• To be revved with NMI R4 to account for

eduPersonScopedAffiliation and H.350

– SAGE (groups/roles manager)


SAGE• Operational issues attending deployments of groups:

– Distributed administration• Automated update from source systems• Ad hoc maintenance by individuals or processes

– Polymorphism of membership information• group → members and member → groups mappings• … and maintaining referential integrity

– Provisioning of group information in multiple locations• E.g., enterprise LDAP directory, NOS directory, RDBMS, flat

file– Orderly removal of stale groups (aging)– Partial orderings of groups (e.g., subgroups)– Direct vs. indirect membership – Referring to set theoretic combinations of groups– Meeting security, privacy, & visibility requirements


SAGE

• SAGE will provide tools to help manage those issues• Same tools should also enable management of roles

– Partial ordering → role hierarchy– Direct vs. indirect membership → assigned vs. authorized roles– Multiple partial ordering (or membership) attributes

• For associating permissions, obligations, & constraints to objects used as roles

• Client & consumer interfaces:– code library– web services– limited batch interface

• Automation (i.e., metadirectory) interface:– LDAP “loading zone” concept currently under discussion


SAGE: Interfaces & integration


SAGE loading zone (LZ)

• The LZ is a selection of a distinguished LDAP metadirectory consumer– Changed LZ entries feed automated joining & leaving, and

other group metadata– No need for new source feeds or extensions to existing ones– No assumption on nature of extant metadirectory processes– Minimal impact on existing policies & procedures

• Issues– How best to detect arrival of new info at the LZ– How to efficiently determine changes to group info entailed

by a chunk of LZ changes (cf. slide 14)


SAGE & authZ


SAGE policy & rules engine

• Need a means of representing:– Rules for joining and leaving each (class of) group– Rules for updating additional, class-specific info (e.g.,

course metadata for course groups)– Security internal to SAGE (SAGE roles)

• Requirements:– Support large number of groups– Not peculiar to each implementation site (=> not in code)– Would be nice to use a technology likely to also be used by

other infrastructure services• Contenders:

– XACML profile– ???


SAGE development processJOIN IN!

• Subgroup of MACE-Dir with biweekly conference calls– Calls announced on [email protected]

• Scenarios doc released with NMI R3• Architectural design process underway

– Loading zone concept– Trying to learn from experience

• AuthZ efforts at Stanford & MIT• CourseBuilder @ U of Arizona• … & others• In blue sky mode – inclusive attitude towards ideas – for a bit longer

• SAGE needs a new name!– http://www.eurekify.com/ – “Got AuthZ?” T shirt prize!


Identity in Os, FOs, & VOs

• Definitions– O: Organization.

• University of Chicago• American Physical Society

– FO: Federated Organization.• InCommon• University of Chicago!

– VO: Virtual Organization.• GriPhyN• American Physical Society!

– *O: any of the above– Identity: all information about an object (person)


Some basic questions

• A single person’s identity may contain information associated with several Os, FOs, and/or VOs. – How to enroll in *Os?

• Both administrative & elective methods, at least– How to enumerate the affiliates of a *O?

• Is there a need for more than a constrained enumeration, e.g., all affiliates of VO1 that belong to O2?

– How should one *O’s infrastructure store knowledge of its members’ affiliations with other *Os?

• Or should there be some Big Directory Of Everything?

• Once we’ve figured out how to integrate identity across *Os, will we already know how to authenticate, authorize, and audit in that environment?


eduPersonXref

• A locus and specification for storing references to identity information housed elsewhere– Avoids problems attendant with storing in one *O’s

infrastructure actual identity info authoritatively housed within another *O’s infrastructure.

• Reference(s) followed at runtime to retrieve actual info

– Agnostic with regard to means of enrollment• References might be maintained …

– administratively (e.g., multi-campus system, feed from professional society)

– electively (e.g., Liberty-style)– or both ways.

– Facilitates constrained enumeration of *O affiliates


eduPersonXref proposal• Elements: orgZone, type, specifier

– orgZone: label for the authoritative organization• DNS zone name

– type: protocol or method to follow the reference• LDAP• Maybe DSML, “SHAR”, ODBC, …

– specifier: type-specific binding• For LDAP type: LDAP URL

– possibly merge type & specifier elements by ensuring that supported types are registered as URI schemes


eduPersonXref examples

• Example. Steven Carmody engages in a shib session in which he authenticates to brown.edu. He goes to the IEEE target site where his IEEE affiliation would grant him further privs, if it was known.

• In directory.brown.edu entry with brownUUID=825df2cd-efb4-63c1-58d5-df9cab59112d (Steven

Carmody), find

eduPersonXref:ieee.org,ldap,ldaps://directory.ieee.org:389/dc=ieee,dc=org?ieeeAffiliation?sub?(ieeePVID=scarmody17)

• Security: relies on use of some pre-existing trust infrastructure to be granted authorization to retrieve referenced info.– E.g. Shib AA follows a reference by reliance on FO OOB artifacts

Directories Update: Status & Next Steps Tom Barton, University of Chicago Keith Hazelton, University...

Documents

Transcript of Directories Update: Status & Next Steps Tom Barton, University of Chicago Keith Hazelton, University...