1 / 48

CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth

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

clare
Download Presentation

CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CIS 8020Case StudyIdentity Management ArchitectureEnabling Shibboleth Art Vandenberg Avandenberg@gsu.edu Account Rep, Information Systems & Technology Georgia State University November 10, 2009

  2. 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.

  3. 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

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

  5. Drivers Constituent Requirements Institutional Goals Policy &Governance Standards Budget Project Management Practices Ability to Implement Technology Staff Skills/Expertise Products Identity Environment Identity Management

  6. 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

  7. 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

  8. Identifiers, examples of (!)

  9. 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

  10. 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

  11. ID Management -underlying data elements • Directories • Metadirectory & Application Enabling • Director Information Tree architecture • ObjectClasses • OIDS

  12. Directories Georgia State University: Building an Identity Management Infrastructure for the eUniversity, NMI-EDIT Case Study Series, October 2004

  13. DIRECTORY ENABLING DATA SOURCES APPL ICAT IONS

  14. 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

  15. o=Georgia State University ou=Information Systems Info per Dept ou=ACS ou=UCCS and sub-Depts… cn=Mae Jones cn=Art Vann Same Jan? cn=Jan Smith cn=Jan Smith cn=Fran West Cn=Jan Smith, ou=ACS, ou=Information Systems, o=Georgia State University • DIT: Not flat, no unique uid, no dc-naming

  16. dc=edu dc=gsu Info for enterprise ou=people ou=unit Info by function ou=acs uid=avann ou=uccs uid=jsmith Unique id across enterprise uid=jsmith2 uid=jsmith2, ou=people, dc=gsu, dc=edu • DIT: Flat, unique uid, dc-naming

  17. Structure can facilitate interoperation 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)

  18. 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

  19. object class inheritance (from Tim Howes et al., Understanding and Deploying LDAP Directory Services) top More attributes Superior class person organizationalPerson inetOrgPerson

  20. 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 ) )

  21. 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

  22. 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' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE ) ...

  23. 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 $ )) ...

  24. eduPerson objectClass • Recommended objectClass for higher education http://www.educause.edu/eduperson/ • eduPerson attributes: eduPersonAffiliation eduPersonPrimaryAffiliation eduPersonOrgDN eduPersonOrgUnitDN eduPersonPrincipalName eduPersonPrimaryOrgUnitDN eduPersonNickname eduPersonEntitlement eduPersonScopedAffiliation

  25. 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

  26. 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’… ) 1.3.6.1.4.1. 5923 .1 .1 .1 .1

  27. 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

  28. Case StudyEnabling Shibboleth

  29. Shibbolethbuilding upon identity management • Given a good enterprise directory, unique id, middleware basis… • Consider a need for LIBRARY • Authenticated / authorized access to Vendor Database

  30. Web Authentication/AuthorizationPrivacy 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)

  31. ShibbolethSingle 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

  32. 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

  33. 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 LDAP Recipe Trust Federations – InQueue (exploring) – InCommon (production)

  34. https://www.site Shibboleth Flow (circa 2004 Architecture doc) 1. http://www.site Authentication System Inter-Site Transfer Service 2. WAYF (Where are you from?) 4. 6. 3. Handle Service 5. Service Provider 7. 8. 10. Attribute Authority 9. Web resource (http://www.site) Identity Provider Source Provider

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

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

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

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

  39. 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

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

  41. 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.

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

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

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

  45. Shibboleth Federationanimation/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

  46. 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/

  47. 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

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

More Related