CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth Art Vandenberg Avandenberg@gsu.edu Account Rep, Information Systems & Technology Georgia State University November 10, 2009

Abstract A key component of security plans is well-managed, centralized access to services that protect online resources and user privacy while enabling ease of use. Shibboleth is an implementation of a solution of identity management infrastructure for web-based resources. Reprise the abstract. Abstract: A key component of security plans is well-managed, centralized access to services that protect online resources and user privacy while enabling ease of use. This seminar presents the policy, procedural, and management issues involved in implementing this critical infrastructure and will review the institutional requirements and policies, common service model, and implementation steps involved in setting up an identity management infrastructure. Participants will leave with a CD of tools, documents, and related materials. This session is offered with support from the NMI-EDIT Consortium of Internet2, EDUCAUSE, and SURA.

Identity Management Goals Deliver services to customers, correctly & securely Provide online service for entire life cycle Simplify end user experience Facilitate provisioning of those services by IT Integrate across traditional applications & data Operate inter-organizational, collaborative environments - students, research, staff, affiliates Engage the attendees. What are other drivers for ID Management?

Systems Integration Goal Enterprise-wide, policy-driven identity and access management infrastructure that supports Scalability Consistency Integration Collaboration

Identity Environment Drivers Constituent Requirements Institutional Goals Constituent Requirements Drivers Policy & Governance Standards Practices Products Technology Project Management Budget Staff Skills/Expertise Ability to Implement Identity Management Picture worth a thousand words. Standards: LDAP, SSL, authentication, Unix, Windows… Practices: documents, project management, resource management Products: Sun, IBM, Novell, AD… Also, ERP systems, Mail, networks Institutional Goals: Campus Strategic plan, IT plan, objectives Drivers: enrollment, new programs, email, security, collaboration, …? Constituent reqs: Students, faculty, staff, Management, parents, Federal, State Budget: $$$, central/distributed, public/private, research? Project Mgmt: Ad hoc, PM maturity, dedicated or shared Staff skill: what they know now, what you need, training, hands-on options…

Identifiers for authentication Motivation for Enterprise Identifier Strategy Foundation: userids, authN, authZ, directories… Moving from stovepipes to enterprise focus “Unified name space” enables support for multiple apps Implications: Unique ids (enterprise-wide, not application) Policies needed for creation, assignment, use of ids Process needed to manage identifiers Reconciliation of multiple identities Refer to Identifier worksheet, provided by Roadmap.

Identifiers, aspects of Identifier characteristics Readability Provisioning Persistence Uniqueness Intelligence Public visibility Identifier types UID (uuid/guid) person registry ID Account login netid ssn (student, emp) publicly visible ID Email address library/departmental Pseudonymous ID Administrative systems ID http://www.opengroup.org/onlinepubs/9629399/apdxa.htm#tagcjh_20 Ref on UUID: “Universal Unique Identifier “This appendix specifies the syntax and semantics of the DCE variant of Universal Unique Identifiers (UUIDs). “A UUID is an identifier that is unique across both space and time1, with respect to the space of all UUIDs. A UUID can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects across a network. “The generation of UUIDs does not require a registration authority for each single identifier. Instead, it requires a unique value over space for each UUID generator. This spatially unique value is specified as an IEEE 802 address, which is usually already applied to network-connected systems. This 48-bit address can be assigned based on an address block obtained through the IEEE registration authority. This UUID specification assumes the availability of an IEEE 802 address.” “Footnote 1. To be precise, the UUID consists of a finite bit space. Thus the time value used for constructing a UUID is limited and will roll over in the future (approximately at A.D. 3400, based on the specified algorithm).”

Identifiers, examples of (!) System (type) Who Assigns? Who Gets One? netid (alpha) Central IT People universalUserID (num) affiliate (AFF+num) Campus Sponsors guests email (first.last@…edu) Campus Units Faculty, staff stuMail (fLast#@…edu) Accepted students sisID (SSN) Registrar Students & instructors hrID (SSN) HR Staff using HR/Payroll alumni (alpha@alum.edu) Alumni Assn Alumni and others adsID (ADS#@fnd….edu) Marketing & Adv Graduates, other donors OneCard (16 digit ISO#) Auxiliary Employees, students, affiliates operatorID (alphaNum) Controller ERP security principals patronID (barcode number) Library Library patrons Example can help illustrate the reality: there are a lot of identifiers. They have different characteristics and requirements. Identity Management has fundamental, core requirement to provide for identifier reconciliation. It is extremely important to start with inventory. NB: Dec 10, 2004: Burton Group facilitates discussion of Identify Management for Georgia State and Georgia Tech - Core of all day session? Inventory Identifiers, understand characteristics, application drivers. It is fundamental.

Identifiers and Authentication Password, kerberos, PKI –– solutions are available Password most prevalent, so how handle? Precrack password and enforce minimum length To age or not to age? Resets managed First password assignment - how to handle securely? US Mail a one-time PW; require in person & photo ID For remote, require departmental rep, supervisor + fax Server side pw management Lock after repeat fail attempts; no clear text store; audit trails; Root/superAdmin separated from users Authentication and Directories in next slides. Focus somewhat on two slides which shows directory trees (visual will help)… talk through differences in DIT models, switching back and forth to point out issues. Best advice: read Identifiers, Authentication, and Directories: Best Practices for Higher Education on which this is based. There is lot of detail in the document that we can’t get into here, but idea is to give a mini-tour of the content which they should then study when they go back to campus.

Authentication - Policy Implications Policies cannot be separate from ID/AuthN Policy decisions may include: Distinct passwords for internal/external or for different levels of security Rethinking value of single sign-on… (reduced sign-on) Best practice recommendation to work in secure environment may imply technical requirement (SSL…) Deciding who assigns Identifiers Format, persistence, reuse of identifiers Ditto: refer to Identifiers, Authentication, and Directories: Best Practices for Higher Education

ID Management - underlying data elements Directories Metadirectory & Application Enabling Director Information Tree architecture ObjectClasses OIDS As you wrap up (and maybe during discussion if the opportunity arises) note that a campus’ local circumstances may call for variation from Roadmap. This can be ok – especially if one recognizes the variation and why it’s needed. (Perhaps you have a situation that calls for tactical versus strategic approach… as long as you know the consequences.)

Directories Enterprise Directory– usually single campus, published from a database (could be person registry) that “JOINs” campus Enterprise Resource Planning (ERP) systems: HR, student, campus-wide services (email). Example at GSU: legacy IDMS for Human Resource/Payroll; SCT Banner Student & Financial Aid; legacy “CSO” directory; Student Rec Center Affiliates; PantherCard Affiliates… Center of the enterprise, used for Directory Pages, email addresses, account management, access controls Metadirectory– is it actual or logical? (Can be both). It’s definitely about Integration Process: registries to store and resolve Ids, directories to support mail, Network Operating System (cf. NDS, AD…*) Nice analogy: Registries are nouns Directories are adjectives Metadirectories are verbs Start with person registry, publish to application directory (mail? Lookup pages?…You choose based on priority. GSU did Student Email, then PantherCard to support Rec Center entry… later Campus Directory) Border Directory– A way to limit/manage/control external sharing. *Application Specific– ERP, NOS, mail… Issue: tradeoff between ONE/MANY. But a good architecture at least ensures consistency, even if many. NOTE: Re AD question. OK, so Novell has NDS, implemented via LDAP… but the CAMPUS DIR is a separate eDIR instance (“LAN support is quite different from flat LOOKUP space.” Georgia State University: Building an Identity Management Infrastructure for the eUniversity, NMI-EDIT Case Study Series, October 2004

DATA APPL ICAT IONS DIRECTORY ENABLING SOURCES Use this diagram to speak from. Overall concept of Middleware: Data sources (business ERP, other sources) enter from left Requires joins, ID resolution, assignment of enterprise identifiers Data targets (applications, services) exit at right Transformation rules may apply (cf. convert 10 digits to phone#) Middle is Enterprise Directory Service comprised of: Metadirectory (person registry, intelligence & business rules) Physical directories Other consumers (cf. GSU has demographic reports that join person data to Panthercard data via services of person registry.) Note there may be feedback loop, such as: CampusID assigned in person registry, passed to student email LDAP Email assigned in person registry, passed back to SCT Banner Student Campus ISO number assigned in person registry, passed to Peoplesoft Not all implementations have actual person registry. But then how assign UID? Maybe id of system of record (such as using ERP ID). Key to the above: How will it be done? What is existing infrastructure (network, ERP systems, email, online web services, hardware platforms, technical support)? DIRECTORY ENABLING

Directory Information Tree (DIT) Design for interoperability, discovery DC (domain component) naming Leverage Domain Name System to provide uniqueness www.yourSchool.edu Ou=people, dc=yourSchool, dc=edu Collaboration across higher education: yourSchool.edu Use this slide to set up next two. Consensus from previous workshop: people want to “chalk talk” directory trees structure. So the “Schema Flat as possible, UID unique, dc-naming” will come out in diagrams on next slides.

DIT: Not flat, no unique uid, no dc-naming o=Georgia State University ou=Information Systems ou=ACS ou=UCCS cn=Art Vann cn=Jan Smith cn=Fran West cn=Mae Jones Cn=Jan Smith, ou=ACS, ou=Information Systems, o=Georgia State University Info per Dept and sub-Depts… Same Jan? Chalk talk (laser pointer would be nice?) Non-flat meaning levels can continue… and imagine if it was Georgia State University College of Arts & Sciences Department of Modern Languages Modern Greek Non-unique universal identifier (in this case using CN, don’t confuse with that fact that there is uid as an attribute). Note possible confusion of 2 named same Jan Smith and Jan Smith: still works as unique in this tree… but problems later: same person with dual appointment? Just coincidence? What if related but the Jan Junior’s nickname is JJ and if not used for cn, then confusing… No dc-naming. So how do you unambiguously locate? And if you were doing some application that was LDAP enabled, could you find DNS SRV record for LDAP? (I.e. DNS doesn’t use “Georgia State University” – rather “gsu.edu”

DIT: Flat, unique uid, dc-naming dc=edu dc=gsu ou=people ou=unit uid=avann uid=jsmith uid=jsmith2 ou=acs ou=uccs uid=jsmith2, ou=people, dc=gsu, dc=edu Info for enterprise Info by function Contrast this DIT schema design: Tree depth is limited, less maintenance if people change (while minimal, still has some logical, if not physical, impact on understandability and locating data). Unique id (it could have been CN… point is that we’ve accounted for uniqueness across whole tree). Can definitively locate via DNS. (And note that we can accommodate UNITs, or GROUPS… in same DIT) Unique id across enterprise

Directory Information Tree (DIT) Best Practice Design to improve interoperability Schema Flat as possible - minimizes update overhead UID unique across tree - resolve identity! Accounts are person attributes (not a separate node of tree) Use dc naming: …dc=yourSchool, dc=edu Naming - why it’s important Choose distinguishedName (DN) carefully UID (rather than commonName: Jim Smith, Jim Smith?) DN should have domain component (dc) Use this slide to summarize the previous two. Consensus from previous workshop: people want to “chalk talk” directory trees structure. So the “Schema Flat as possible, UID unique, dc-naming” will come out as important from previous “chalk talk” slides. Structure can facilitate interoperation

object Classes object classes group related information, typically, modeling some real-world object such as a person, printer, or network device. object classes enable passing of information object classes include: An OID that uniquely identifies the class A name that also uniquely identifies the class A set of mandatory attributes A set of allowed attributes Basic structure of LDAP. This is a terms and definitions section. (compare to relational databases: you need the basic table, column, row concepts in order to work productively.) The hierarchical concepts in LDAP map to relational concepts in RDMS. These parallels need to be handled at a high level. Interested participants encouraged to read more deeply.

organizationalPerson object class inheritance (from Tim Howes et al., Understanding and Deploying LDAP Directory Services) More attributes Superior class top person Here we have a concept that will be trivial to those familiar with object-oriented programming, and potentially challenging for people seeing it the first time. For RDBMS folks, we can call children objects sub records. organizationalPerson inetOrgPerson

object Classes, standards for Representation of object classes is defined in X.501 (ITU-T Recommendation X.501) person schema definition (cf. Sun ONE/iPlanet) objectclasses: ( 2.5.6.6 NAME “person” DESC “Standard ObjectClass” SUP “top” MUST ( objectclass $ sn $ cn ) MAY ( aci $ description $ seeAlso $ telephoneNumber $ userpassword ) ) Schema definition helps define components. OID is official, unique name (and usually only officially standard way to ref… except from some special attributes like “sn”, “cn”… [find Gettes ref from a MACE dir session…]) DESC: standard objectclass / abstract, structural, auxiliary MUST and MAY distinction Also see: UCDavis detail doc for schema based on eduPerson. http://216.239.39.104/search?q=cache:8iP8AE7ZAXwJ:vpiet.ucdavis.edu/advancedprojects/directory_schema.pdf+%22standard+objectclass%22+defined+vs+structural&hl=en&ie=UTF-8

objectClasses, example of person entry for Babs Jensen Requires Allows (naming info) (descriptive, contact info) sn: Jensen description: directory manager cn: Babs Jensen telephoneNumber: +1 650 555 1234 objectclass: top userpassword: xxxxxx person seeAlso: cn=Fred Jensen Object class attributes can be multi-valued eduPersonAffiliation: staff, alum Walk through this, taking your time. Note Requires “naming info” vs. allowed “descriptive, contact info” i.e. MUST attributes vs. MAY attributes Touch on multi-valued - not like RDBMS where multi-values is poor practice in table design.

LDIF (LDAP Data Interchange Format) – add attributes of eduPerson ... dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) attributetypes: ( 1.3.6.1.4.1.5923.1.1.1.6 NAME 'eduPersonPrincipalName' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) These are attributes. When implementing objectclass - need to define attributes first. Note the EQUALITY element. Important for searching and matching. SYNTAX defines type; “15 is string” “12 is distinguishedName” attributetypes: ( 1.3.6.1.4.1.5923.1.1.1.3 NAME 'eduPersonOrgDN' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE )

LDIF - add objectClass of eduPerson ... dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation $ eduPersonNickname $ eduPersonOrgDN $ eduPersonOrgUnitDN $ eduPersonPrimaryAffiliation $ eduPersonPrincipalName $ eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN $ )) Note: life is interesting. Novell has error on this (trailing $ separator…) Go figure. Point is: things are slightly different. Might be good time to note that LDAP is a protocol, not implementation. So vendor implementations may vary. Concepts - (link to Roadmap for detail…) LDIF text file ldapmodifiy command ldapmodify to add attributes/objectlcass ldapmodify to add entries

eduPerson objectClass Recommended objectClass for higher education http://www.educause.edu/eduperson/ eduPerson attributes: eduPersonAffiliation eduPersonPrimaryAffiliation eduPersonOrgDN eduPersonOrgUnitDN eduPersonPrincipalName eduPersonPrimaryOrgUnitDN eduPersonNickname eduPersonEntitlement eduPersonScopedAffiliation http://snad.ncsl.nist.gov/snad-staff/tebbutt/x5eg/subsubsection2_4_4_5_2.html National Institute of Standards and Technology, 1995 Auxiliary Object Class Each entry, while belonging to only a single structural object class, may belong to zero or more auxiliary object classes. Auxiliary object classes serve as a means to provide multiple inheritance to Directory entries, that is to say, to combine the attributes from two or more superclass chains into a single entry. This is useful in the case where a common group of attributes is desired in entries from various object class hierarchies. For example, the attributes of an object class Bank Account Holder might be included into entries of structural object classes as varied as Residential Person, Personnel Manager, Business Organization and Government Department. Should note the distinction of auxiliary objectclasses. Auxiliary provides flexibility since one can define auxiliary and it can be used by any objectclasses - without having to specifically redefine. If you remove an attribute from the object definition, restart LDAP and then try to update the object, an update failure will occur: "Object Violation". (from http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-DefineObjectsAndAttributes.html#OBJECT) Redefinition implies need to unload data, change objectclass, reload. Compare to relational database tables - changing table column definition would require unload, rebuild, reload.

OID policy OID arc - A unique Object Identifier Must have for local attributes/objectclasses Enables interoperability Managed hierarchy ISO http://www.iso.ch/ and ITU http://www.itu.ch/ Can be obtained from a number of sources To get one from IANA, fill out a form at http://www.iana.org/cgi-bin/enterprise.pl No fee; turnaround relatively quick To get one from ANSI, go to http://web.ansi.org/public/services/reg_org.html One-time fee; turnaround can take several weeks Take a moment to work through this. Key point - it’s easy, apply and get one.

OID arc - eduPersonAffiliation From IANA = 1.3.6.1.4.1 From eduPerson LDIF # 1.3.6.1.4.1.5923 is the toplevel OID for this [MACE] work # .1 = MACE related work # .1.1 = eduPerson # .1.1.1 = attributes # .1.1.2 = objectclass # .1.1.3 = syntax (probably never used) # .1.2 = eduOrg # .1.2.1 = attributes # .1.2.2 = objectclass # .1.2.3 = syntax (probably never used) add: attributetypes attributetypes: ( NAME 'eduPersonAffiliation’… ) Use this slide to go over oid arc. May go to IANA hotlink and see the Private Enterprise Numbers. NOTE: not all assigned are listed (question of updates…) 1.3.6.1.4.1. 5923 .1 .1 .1 .1

Superior arc (1.3.6.1.4.1.5923)? * 1.3.6.1.4.1 - IANA * 1.3.6.1.4 - Internet Private * 1.3.6.1 - OID assignments from 1.3.6.1 - Internet * 1.3.6 - US Department of Defense * 1.3 - ISO Identified Organization * 1 - ISO assigned OIDs * Top of OID tree Just so they can see that there is some “authority” behind this OID Arc scheme.

Case Study Enabling Shibboleth

Shibboleth building upon identity management Given a good enterprise directory, unique id, middleware basis… Consider a need for LIBRARY Authenticated / authorized access to Vendor Database Case study of how appropriate identity management infrastructure is necessary for Shibboleth - and, if in place, can position campus for improved services to its campus customers.

Web Authentication/Authorization Privacy Preserving Security Access to digital library resources (vendor databases) Some solutions have policy & technology limits: IP-based access – spoofable, limiting Proxy server – slightly better Group accounts – obvious drawbacks (can’t id exactly) Additional management of accounts & passwords management hassles, synchronization complexity extra accounts for users lag time setting up a new person (faculty, student, or employee) Current solutions highlight the inadequacy of current identity management - especially in effective scaling of inter-organizational solutions.

Shibboleth Single Sign-on and Federating Software specifically addresses the challenges of Multiple passwords required for multiple applications Scaling the account management of multiple applications Security issues associated with accessing third-party services Privacy Interoperability within and across organizational boundaries Enabling institutions to choose their authentication technology Enabling service providers to control access to their resources. http://shibboleth.internet2.edu/about.html Policy Elements: must be addressed for Shibboleth implementations.

Shibboleth Pilot Solution (2004) University Library Provides secure access (not proxied) Leverages local enterprise authentication Access is based on role attributes (finer grained) Enables access from anywhere on web Reduces logins Stronger authentication (not IP) Addresses user privacy POLICY Elements: Trust Federation; Privacy preservation Campus Ids Attribute Authority Privilege management Policy Elements: must be addressed for Shibboleth implementations.

Architecture/Policy components OpenSAML for secure transmission Sun Solaris for Shibboleth Origin Apache, Tomcat, J2SE Origin site (Identity Provider) requirements Handle Server single signon (SSO) or web initial signon (WebISO) Attribute Authority repository (mySQL or LDAP) Target site (Source Provider) requirements Inter-Site Transfer Service Service Provider WAYF Resource Manager Cf. PubCookie – or other single signon methods eduPerson schema – attributes for interoperation These components provide implementation of policy/technology for secure authN/AuthZ. LDAP Recipe Trust Federations – InQueue (exploring) – InCommon (production)

Shibboleth Flow (circa 2004 Architecture doc) https://www.site 1. http://www.site Authentication System Inter-Site Transfer Service 2. WAYF (Where are you from?) 4. 3. 6. Handle Service 5. Service Provider 7. Emphasis is on the identity management components for Authentication and attribute authority. If local institution has their Origin identity management in place, they can participate effectively in Shibboleth solutions. 8. 10. Attribute Authority 9. Web resource (http://www.site) Identity Provider Source Provider

Access Web Resource – EBSCO University Library Shibboleth Pilot info page (c/o Laura Burtle) www.library.gsu.edu/shib/ 1. EBSCO test URL

Redirect via WAYF InQueue Federation (for pilot testing) 2. Pick your Shib origin (these are Inqueue sites recognized by target WAYF)

Shibboleth Origin – Local Login 3. Use local authentication (CampusID/pw)

Successful Authentication 4. Authenticated user is being directed to web site… (with Authorization checking behind the scenes)

Use EBSCO Web Resources Accessing EBSCO research Databases. 5. Do your thing. 4 steps: 1. Pick url 2. Pick origin 3. Login 4. Verification Use resource

Access Web Resource – JSTOR 1. Now Select Browse JSTOR (continuing current browser session)

Access, no Re-login (Shib saves session) 1 (NOT 4) steps: 1. Pick url [2. NA] [3. NA] [4. NA] Use resource Direct access to next Shibboleth site – (no WAFY, no login) 2. Do your thing.

JSTOR site knows it’s GSU “Your access to JSTOR is provided by Georgia State University” (identity not passed, but attributes may be)

OCLC / authorization attributes OCLC needs no further authentication, but does require specific attributes eduPersonAffiliation = member@gsu.edu eduPersonEntitlement= urn:mace:oclc:org… (eduPerson schema)

Appropriate attributes OCLC web resources Appropriate attributes permit access... OCLC recognizes Georgia State member (and contract)

Shibboleth Federation animation/demo Federated identity http://shibboleth.internet2.edu/federations.html UK’s Joint Information Systems Committee animation Shibboleth demo http://shibboleth.internet2.edu/demo/shib_demo.html Just the discussion of what the federated model implies for campus vs federation policies highlights the importance of clearly defining one’s own policies as a pre-requisite to having an agreed to federation policy. An initial step is the dialog that brings out the compares/contrasts and pros/cons of federation members’ existing Identity Management infrastructure.

Shibboleth Success Factors Addresses an important aspect of security – privacy Leverages enterprise directory to implement Policy Federation Policy model resonates with shared libraries concepts Standards based More on Shibboleth: http://shibboleth.internet2.edu/ Libraries have been in the business of providing shared access to limited resources - with highest respect for intellectual freedom and privacy. Burton Group report (limited to subscribers) provides excellent analysis of Shibboleth model, architecture and marketplace.

Shibboleth growth Concept 2003 Working groups, understanding use cases NSF funding Pilots, standards Federations European & World initiatives Shibboleth in use: http://shibboleth.internet2.edu/shib-in-use.html Just the discussion of what the federated model implies for campus vs federation policies highlights the importance of clearly defining one’s own policies as a pre-requisite to having an agreed to federation policy. An initial step is the dialog that brings out the compares/contrasts and pros/cons of federation members’ existing Identity Management infrastructure.

Questions? Discussion Thank you! Art Vandenberg avandenberg@gsu.edu