Directory based Middleware Services

1. Directory based Middleware Services Keith Hazelton, Senior IT Architect, Univ. of Wisconsin-Madison Middleware Architecture Committee for Education, Internet2 Advanced CAMP, Boulder Colorado, 31-Jul-02

2. The directory architect’s new jobs • “Groups in LDAP” becomes support for Role-Based Access Control (RBAC) • The role of directories in authorization and policy tasks • Warm-up for this evening’s RBAC BoF • The repository of institutional information supports event-driven institutional processes • A class of metadirectory functions • A theme in yesterday’s Metamerge tutorial

3. The directory architect’s new jobs • Institutional boundaries become porous to directory-based information and process flows • Inter-directory flows • Warm-up for tonight’s “Affiliated Directory” BoF • Adds up to some mental calisthenics for the first morning of Advanced CAMP

4. Cascading phrases defining controlled access to resources Systems of record Identify Persons Who have Affiliations / Attributes That are mapped to Entitlements That determine eligibility for Services That are offered by Service Providers

5. Separation of policy from technical architecture and implementation • Ask the technologists • To build a system that can easily accommodate new sources, people, services, etc. • Ask the stakeholders • To agree on policies & procedures in terms of this cascading diagram • Yields a cleaner separation of the two activities • The two groups share a layer of language

6. Technology needs to support any & all mappings • Services can come & go • New populations can get added • New entitlements can be defined • Access policies can change • All without having to call the technologists back to reprogram • Systems can change without changing “contracts”

7. What is LDAP Server’s proper role in RBAC? • To provide an LDAP protocol gateway to this information for systems that need it • May involve moving & transforming data from one repository to another within the enterprise directory • Makes use of groups to represent affiliations & entitlements • Relational database as a more natural basis for group management, RBAC management tools

8. Tools for RBAC • The tools we need to manage RBAC have been identified by Tom Barton & MACE-Dir: • Grouper (group math service) • SAGE Service for Authorized Group Editing (with RIBot)

9. RBAC tools research • GROUPER (original incarnation at Brown) • A special LDAP server (OpenLDAP) engineered to handle group math operations against the enterprise directory for applications that are not group savvy. • Application -> get group BLAH -> GROUPER -> combine 15 groups and remove those in the exclusion group -> give back combined static object as group BLAH

10. A quick look at one SAGE-like tool • UW-Msn system for managing roles, objects and access rights, Steve Fosdal, Health Alert Network project • We will need to add terms to the policy expression as scenarios get more complicated • Drive the group representations into the LDAP Server via automated processes • Put the information where apps will expect it

11. Escaping meta- and affiliated-:Inter-directory issues in general • “Metadirectory,” “Affiliated directory:” Terms that are more trouble than they’re worth • Focus on the set of issues that come up when directories (and other info stores) need to interact • Sharing info across realms or domains is one class of scenarios • Information transformation on the way in & out of different repositories and stores is another

12. The primary clusters of Inter-directory issues • Shared language • syntax (SAML + schema) • semantics (of attributes, values, policy assertions) • Identity management • Access control questions • Who can do what to which information where • Registration & discovery • Summary: We need RBAC-enabled repositories

13. Medical Middleware scenario and Inter-directory requirements • Provider at site away from “staff home” accessing medical records • We can’t make real progress here until we solve • RBAC issue • Identity management issue • Shared language (or mapping) issue

14. Inter-directory issues • Shibboleth issue of who can see what personal information (policy) • Usability worries • Ken Klingenstein: It’s all in picking intelligent defaults

15. The triumph of Security Assertions Markup Language (SAML) • Will this be seen as on a par with the triumph of LDAP in the later 90’s? • Everyone in the vendor space agrees to support this • RBAC information carried in SAML assertions • The Shibboleth Attribute Authority points the way…

16. Inter-directory issues • SAML win is that it is now a standard tool • Attribute integrity solution in the form of signed SAML attribute assertions with accompanying data • Including effective dating info • Who sez? • How do I correct a value I know is wrong? • A separate SAML based conversation? What’s the update action in this case? • …and XACML (eXtensible Access Control Markup Language) for policy assertions?

17. A new kind of schema work • Express attribute values as URNs • URN:MACE:foo.edu:service_x_entitlement • Then inter-realm schema equivalence mappings can be formalized • Like the OID-based policy mapping in X.509 certs, but friendlier

18. A new kind of schema work • Define some shared principles to make the mappings & discussions easier • Top-down vs grass-roots: When to hammer it out on conference calls, when to go it alone (or with your close friends & associates)

19. An enlightening extreme case • Imagine a set of information in the wilderness. • What would make it self-contained? • If we can answer that, we should be able to share data safely • Does this make policy granularity too fine?

20. Proposal to start the conversation • Mandate SAML flows for inter-realm and inter-directory exchanges • Transform back to LDAP at destination if desired (connectors and scripts a la Metamerge) • BoFs can hammer on these & other issues about the future of Directory based middleware services

21. BASE CAMP Voting for “What to do next?” • 8 • 11 • 2 • 4 • 3 • 0 • 7 • 4 • 1 • 3 • 0 • 0 • 1 • 6 • 1 • 1 • 5 • 11 • 4 • 1 • 4 • 4 • 5 • 0 • 2 • 5 • 1 • 2 • 1 • Directory Policy • PKI Policy • Identity Mgmt Practices • Metadirectories • Dir of Dirs Higher Ed (DoDHE) • LDAP Analyzer • The Art of Directories/Databases • PKI-Lite and S/MIME • Early Harvest for App Developers • Digital Rights Management (DRM) • Outreach and Dissemination • N-Tier Systems (portals) • Filesystems • Selling it • Project Mgmt • eduOrg, eduPerson, edu(other …) • Shibboleth • Roles (RBAC) • GIG (Group Implementer’s Guide) • GROUPER, RI-Bot, SAGE • Blue Pages • LDAP-Recipe (next?) • Affiliated Directories • HEBCA, Bridge PKI, etc… • Video Middleware (commObject) • GRID AuthN campus integration • GRID AuthZ campus integration • Medical Middleware (MedMid) • Operational Issues (perf/mon)

22. What is in the directory space? • . • Directory Policy • Dir of Dirs Higher Ed (DoDHE) • LDAP Analyzer • Operational Issues (perf/mon) • The Art of Directories/Databases • Identity Mgmt Practices • Metadirectories • . • eduOrg, eduPerson, edu(other …) • Shibboleth • Roles (RBAC) • GROUP THERAPY • GIG (Group Implementer’s Guide) • GROUPER, RI-Bot, SAGE • Blue Pages • LDAP-Recipe (next?) • Affiliated Directories • HEBCA, Bridge PKI, etc… • Video Middleware (commObject) • GRID AuthN campus integration • GRID AuthZ campus integration

23. Certificate Parsing Server • Peter Gietz - a draft to describe X.509 certificates as plain old directory objects. Finding certificates becomes easy for directory aware applications. Use PKI operations on the cert you select to verify it. • David Chadwick - a Certificate Parsing Server (CPS). Like GROUPER but only works on add/delete/modify operations and stores cert objects as child objects as well as userCertificate attributes where they are now. • This should have a dramatic impact on Bridge CA model operations.

24. Q & A and discussion