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

9July 2003AuthZ CAMP 2 Copyright Tom Barton and Keith Hazelton 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.

9July 2003AuthZ CAMP 3 Outline 1.Current threads in MACE-Dir 2.(SAGE) 3.eduPersonXref Pipe up with questions or comments at any time!!

9July 2003AuthZ CAMP 4 MACE-Dir currents Internet2/MACE working group on directories Keith Hazelton, WG Chair eduPersonScopedAffiliation –Will be included in next rev of eduPerson –Driven by Shibboleth needs –Syntax like eduPersonPrincipalName (!?!) –Raises problems about who is authorized to assert what An “inter-realm metadirectory function” A field full of rat holes and land mines…

9July 2003AuthZ CAMP 5 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

9July 2003AuthZ CAMP 6 MACE-Dir currents eduPersonEntitlement –Values are URIs (URL or URN) –urn:mace: prefixed values proliferating after acceptance by IETF and upcoming registration with IANA –Gives us a way to make values unique in the entitlement namespace without elaborate registry mechanism urn:mace:wisc.edu:bucky-bundle urn:mace:oclc:org:autho:NNNN urn:mace:duke.edu:library:oclc:contract-NNN –If you want to get a namespace registered, contact eduPersonEntitlement attribute

9July 2003AuthZ CAMP 7 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

9July 2003AuthZ CAMP 8 MACE-Dir currents: Collaboration on Schema Work 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

9July 2003AuthZ CAMP 9 MACE-Dir currents: Collaboration on Schema Work 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

9July 2003AuthZ CAMP 10 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

9July 2003AuthZ CAMP 11 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

9July 2003AuthZ CAMP 12 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)

9July 2003AuthZ CAMP 13 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

9July 2003AuthZ CAMP 14 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

9July 2003AuthZ CAMP 15 SAGE: Interfaces & integration

9July 2003AuthZ CAMP 16 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)

9July 2003AuthZ CAMP 17 SAGE & authZ

9July 2003AuthZ CAMP 18 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 –???

9July 2003AuthZ CAMP 19 SAGE development process JOIN IN! Subgroup of MACE-Dir with biweekly conference calls –Calls announced on Scenarios doc released with NMI R3 Architectural design process underway –Loading zone concept –Trying to learn from experience AuthZ efforts at Stanford & MIT U of Arizona … & others In blue sky mode – inclusive attitude towards ideas – for a bit longer SAGE needs a new name! – –“Got AuthZ?” T shirt prize!

9July 2003AuthZ CAMP 20 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)

9July 2003AuthZ CAMP 21 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 VO 1 that belong to O 2 ? –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?

9July 2003AuthZ CAMP 22 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

9July 2003AuthZ CAMP 23 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

9July 2003AuthZ CAMP 24 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