Internet2 Middleware Drinking Kool-Aid From A Fire Hose or Sniffing Glue-Ware

1. Internet2 MiddlewareDrinking Kool-Aid From A Fire HoseorSniffing Glue-Ware Michael R. Gettes Principal Technologist Georgetown University gettes@Georgetown.EDU http://www.georgetown.edu/giia/internet2

2. “Middleware is the intersection of what the Network Engineers and the Application Programmers don’twant to do” - Ken Klingenstein Chief Technologist, Univ. of Colorado, Boulder Director, Internet2 Middleware Initiative Lead Clergy, MACE PS of LC Middleware makes “Transparently use” happen

3. Internet2 Middleware • If the goal is a PKI, then you need to consider: • Identifiers (SSNs and other untold truths) • Identification & Authen process (“I & A”) • Authentication systems (Kerberos, LDAP, etc) • Lawyers, Policy & Money (lawyers, guns & $$$) • Directories (and the applications that use them) • Certificate Mgmt System (CMS) Deployment • CA Certficate, Server Certificates, Client Certificates • Authorizations (a real hard problem, Roles, etc)

4. Internet2 Middleware • Building Application/System Infrastructure • What is missing in Internet 1 • Not “Network Security” (wire level) • Assumes the wire is insecure • Assumes the Application is insecure • If security was easy, • everyone would be doing it. • http://middleware.internet2.edu

5. National Science FoundationNMI program • $12 million over 3 years • www.nsf-middleware.org • Middleware Service Providors, Integrators, Distributors • GRID (Globus) • Internet2 + EDUCAUSE + SURA • May 2002 – first set of deliverables from all parties

6. MACE • Middleware Architecture Committee for Ed. • IT Architects – meet often – no particular religious affiliations • MACE-DIR – eduPerson, Recipe, DoDHE • MACE-SHIBBOLETH – global AuthN/Z • MACE-PKI  HEPKI (TAG/PAG/PKI-Labs) • MACE-WebISO – Web Initial Sign-on • VID-MID – Video Middleware (H.323/SIP) • MACE-FDRM – Federated Digital Rights Management • NMI - NSF Middleware Initiative

7. RL “Bob” Morgan, Chair, Washington Steven Carmody, Brown Michael Gettes, Georgetown Keith Hazelton, Wisconsin Paul Hill, MIT Ken Klingenstein, Colorado Mark Poepping, CMU Jim Jokl, Virginia David Wasley, UCOP Von Welch, ANL/Grid Scott Cantor, Ohio St Bruce Vincent, Stanford Euro: Brian Gilmore & Ton Verschuren, Diego Lopez MACE-ochists

8. A Map of Middleware Land

9. MACE-DIR • Keith Hazelton, Chair, Wisconsin • eduPerson objectclass • LDAP-Recipe • Dir of Dirs for Higher Education (DoDHE) • Shibboleth project dir dependencies • Meta Directories – MetaMerge • Groups (Dynamic vs. Static; Management) • Afilliated Directories (Stitched, Data Link) • http://middleware.internet2.edu/directories

10. MACE-DIR:eduPerson 1.0 (1/22/01 release) • MACE initiated (Internet2 + EDUCAUSE) • Globally interesting useful attributes • Get community buy-in, must use it also • eduPersonAffiliation (DoDHE), eduPersonPrincipalName (Shibboleth) • “Less is more”, how to use standard objectclasses • http://www.educause.edu/eduperson

11. eduPerson 1.5 object class • Included as part of the NSF Middleware Initiative (NMI) Release 1.0 May 7th, 02 • eduPerson 1.0 is the production version, 1.5 status is “released for public review” (RPR) • Next NMI release will include final 1.5 based on review period discussions

12. eduPerson 1.5 object class • Changes from 1.0: • Introductory section added • RFC2252 style definitions included for the eduPerson object class itself and for each of the eduPerson attributes. • Notes on additional attributes from existing object classes, existing notes clarified, syntax and indexing recommendations updated.

13. eduPerson 1.5 object class • Two new attributes: • eduPersonPrimaryOrgUnitDN • eduPersonEntitlement • Simple case: value is the name of a contract for licensed resource • http://xstor.com/contract1234 • Values of eduPersonEntitlement can be URLs or URNs

14. eduPerson 1.5 object class • eduPersonEntitlement • Values of eduPersonEntitlement can be URLs or URNs • http://www.w3.org/Addressing/ • RFC2396 Uniform Resource Identifiers • RFC2141 Uniform Resource Names • URNs to allow federation of name creation without name clashes. • urn:mace:brown.edu:foo • mace-submit@internet2.edu for information on URN registration

15. eduOrg 1.0 • eduOrg 1.0 released as “Experimental” object class • Basic organizational info attributes from X.520 • Telecomm, postal, locale • eduOrgHomePageURI • eduOrgIdentityAuthNPolicyURI • eduOrgLegalName • eduOrgSuperiorURI • eduOrgWhitePagesURI

16. LDAP-Recipe positioning and the NMI R1 • A special case document • Pre-existed NMI and MACE document standards for format and naming. • Will conform to NMI/MACE naming and future process for acceptance. • Content??? Well, we shall see…

17. LDAP-RecipeVersion 1.5 (pre May 7, 2002) • Directory Tree • Schema (Design, upgrading, maint) • AuthN (binding and pw mgmt) • eduPerson attr discussion (select) • Access Control • Replication • Name population

18. LDAP-RecipeVersion 2.0 (NMI R1 May 7, 2002) • Groups, Groups, Groups • Static, Dynamic, app issues, builds on “NMI Groups Doc” • E-Mail Routing considerations • Attribute firewalling, Sendmail, app issues • eduPersonOrgDN and eduPerson{Primary}OrgUnitDN • Original Intent for eduPerson 1.0 and Primary • RDN Issues (a must read) • Software reference (small, needs to grow)

19. MACE-DIR:Directory of Directoriesfor Higher Education • Web of Data vs. Web of People • Prototype: April, 2000 (by M. Gettes) • Highly scalable parallel searching • Interesting development/research problems • Configs, LDAP libraries, Human Interface • Realized the need to: • Promote eduPerson & common schema • Promote good directory design (recipe) • Work proceeding – Sun Microsystems Grant • http://middleware.internet2.edu/dodhe

20. MACE-DIR:DoDHE and LDAP Analyzer • Todd Piket, Michigan Tech • Web based tool to empirically analyze a directory • eduPerson compliance • Indexing and naming • LDAP-Recipe guidance (good practice) • Beta: http://morpheus.dcs.it.mtu.edu/~tcpiket/dodhe

21. MACE-Dir Futures • Technical Advisory Board • eduOrg, eduPerson, edu??????? • Shibboleth and other related work • Roles (RBAC) • Group Implementations (Eileen Shepard, BC; Tom Barton, Memphis) • Blue Pages • LDAP-Recipe (next?) • Affiliated Directories (Rob Banz, UMBC) • pkiUser/pkiCa, Bridge CA, etc… • Video Middleware (commObject{Uri} OCs) • GRID interoperability • Directory Policy

22. MACE-Dir Futures (continued) • EduOrg “blue page” entries • EduOrgUnit 1.0 object class and attributes • Affiliated directories scenarios • Identity management in Health Sciences • Assembling info on the fly • Data/Metadata bundles as units of exchange • Exploring with our Technical Advisory Board

23. MACE-SHIBBOLETH • Steven Carmody, Brown, Chair • A Biblical pass phrase – “password” • Get it right or “off with your head” • Inter-institutional Authentication/Authorization • Web Authorization of Remote Sites with Local Credentials • Authentication via WebISO • October, 2002 – Version 1.0 with NMI • http://middleware.internet2.edu/shibboleth

24. MACE-WEBISOWeb Initial Sign-on • Based on University of Washington “pubcookie” implementation • Washington will developing and steward with external funding • JA-SIG uPortal, Blackboard, WebCT, Shibboleth – will do or are highly likely to do. • http://www.washington.edu/computing/pubcookie

25. VID-MIDVideo Middleware • Authentication and Authorization of H.323 sessions. • Client to Client • Client to MCU • Directory enabled • How to find video enabled people? • What is necessary to describe video capabilities? • Will likely extend to IP Telephony and so on…

26. PKI is 1/3 Technical and 2/3 Policy? Policy Technical

27. HEPKI • TAG – Technical Activities Group • Jim Jokl, Chair, Virginia • Mobility, Cert Profiles, PKI-Lite, etc, etc, lots of techno • PAG – Policy Activities Group • Default Chair, Ken Klingenstein, Colorado • Knee-deep in policy, HEBCA, Campus, Subs+RP • PKI Labs (AT&T)– Neal McBurnett, Avaya • Wisconsin-Madison & Dartmouth • Industry, Gov., Edu expert guidance • http://www.educause.edu/hepki

28. Multiple CAs in FBCA Membrane • Survivable PKI • Cross Certificates allow for “one/two-way policy” • Directories are critical in BCA world.

29. A Snapshot of the U.S. Federal PKI DOD PKI Illinois PKI CANADA PKI Federal Bridge CA NASA PKI Higher Education Bridge CA University PKI NFC PKI

31. Bridge CAs • Higher Education Bridge CA – FBCA peering • We have a draft HEBCA CP (Net@EDU PKI WG) FBCA Compatible • How many HEBCAs? (EDUCAUSE!) • Do we really understand PKI implementations with respect to policy needs? (proxy certificates, relying party agreements, name constraints, FERPA, HIPAA, who eats who?) • BCA seems to be the most promising perspective. Will each person be a BCA? • Does ALL software (Client/Server) need to be changed? • Mitretek announces new BCA deployment model 2/15/2001 • Scalable & deployable • Server plug-ins make client changes less likely

32. Medical P K I H i e r a r c h y The PKI Puzzle By David Wasley, UCOP

33. domainComponent (DC=) Naming • Traditional X.500 naming: • cn=Michael R Gettes, ou=Server Group, ou=UIS, o=Georgetown University, c=US • domainComponent (DC) naming: • uid=gettes,ou=People,dc=georgetown,dc=edu • HEPKI is issuing guidance and advice on DC= naming

34. Attributes for PKI • Store them in a Certificate? • Attributes persist for life of Certificate • No need for Directory or other lookup • The Certificate itself becomes the AuthZ control point • Store them in a Directory? • Very light-weight Certificates • Requires Directory Access • Long-term Certificate, Directory is AuthZ control point. • How many Certificates will we have? • Pseudonymous Certificates

35. We’re Building A“Bridge Over The River PKI”

36. Shibboleth Update Steven Carmbody, Brown University Project Leader, Shibboleth Michael R. Gettes, Georgetown University

37. Shibboleth ArchitectureConcepts - High Level Browser Pass content if user is allowed Target Web Server Authorization Phase Authentication Phase First Access - Unauthenticated Target Site Origin Site

38. Shibboleth ArchitectureConcepts (detail) Browser Target Web Server Authorization Phase Authentication Phase Success! Entitlements Attribute Server Ent Prompt Req Ent Second Access - Authenticated Auth OK Pass entitlements for authz decision Web Login Server Redirect User to Local Web Login Pass content if user is allowed Authentication Ask to Obtain Entitlements First Access - Unauthenticated Target Site Origin Site

39. Shibboleth Architecture

40. Shibboleth Components

41. local authn server - assumed part of the campus environment web sso server - typically works with local authn service to provide web single sign-on resource manager proxy, resource manager - may serve as control points for actual web page access attribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tables attribute repository - an LDAP directory, or roles database or…. Where are you from service - one possible way to direct external users to their own local authn service attribute mapper - converts user entitlements into local authorization values PDP - policy decision points - decide if user attributes meet authorization requirements SHAR - Shibboleth Attribute Requestor - used by target to request user attributes Descriptions of services

42. Shibboleth Flows Draft

43. Shibboleth Architecture -- Managing Trust • TRUST Shib engine Attribute Server Target Web Server Browser Target Site Origin Site

44. Personal Privacy • Web Login Server provides a pseudononymous identity • An Attribute Authority releases Personal Information associated with that pseudnonymous identity to site X based on: • Site Defaults • Business Rules • User control • myAA • Filtered by • Contract provisions My AA Site Defaults Contact Provisions Browser User

45. Managing ARPs

46. Middleware Marketing

47. Shibboleth Inter-Realm AuthZ We all get Web SSO for Local Authentication and an Enterprise Authorization Framework with an Integrated Portal that will all work inter-institutionally! Local Web SSO Pressures Drivers of Vapor Convergence eduPerson 1.0 OKI/Web Authentication JA-SIG uPortal Authen

48. Middleware Inputs & Outputs Licensed Resources Embedded App Security Grids OKI JA-SIG & uPortal Inter-realm calendaring futures Shibboleth, eduPerson, Affiliated Dirs, etc. Enterprise authZ Campus Web SSO Enterprise Directory Enterprise Authentication Legacy Systems

49. Errata--ica

50. The Liberty Alliancewww.project-liberty.org • Sun Microsystems, American Express, United Airlines, Nokia, MasterCard, AOL Time Warner, American Airlines, Bank of America, Cisco, France Telecom, Intuit, NTT DoCoMo, Verisign, Schlumberger, Sony … • Initiated in September 2001. • Protect Privacy, Federated Administration, Interoperability, Standards based but requires new technology, hard problems to solve, a Network Identity Service • Funny, doesn’t this stuff sound familiar?