Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth Art Vandenberg Account Rep, Information Systems & Technology.

Similar presentations

Presentation on theme: "1 CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth Art Vandenberg Account Rep, Information Systems & Technology."— Presentation transcript:

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

2 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 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 4 Systems Integration Goal Enterprise-wide, policy-driven identity and access management infrastructure that supports –Scalability –Consistency –Integration –Collaboration

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

6 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 7 Identifiers, aspects of Identifier characteristics –ReadabilityProvisioning –PersistenceUniqueness –IntelligencePublic visibility Identifier types –UID (uuid/guid)person registry ID –Account loginnetid –ssn (student, emp)publicly visible ID – addresslibrary/departmental –Pseudonymous IDAdministrative systems ID

8 8 Identifiers, examples of (!) System (type) Who Assigns? Who Gets One? netid (alpha)Central ITPeople universalUserID (num)Central ITPeople affiliate (AFF+num)Campus Sponsorsguests UnitsFaculty, staff stuMail ITAccepted students sisID (SSN)RegistrarStudents & instructors hrID (SSN)HRStaff using HR/Payroll alumni AssnAlumni and others adsID & AdvGraduates, other donors OneCard (16 digit ISO#)AuxiliaryEmployees, students, affiliates operatorID (alphaNum)ControllerERP security principals patronID (barcode number)LibraryLibrary patrons

9 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 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 11 ID Management - underlying data elements Directories Metadirectory & Application Enabling Director Information Tree architecture ObjectClasses OIDS

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


14 14 Directory Information Tree (DIT) Design for interoperability, discovery –DC (domain component) naming –Leverage Domain Name System to provide uniqueness Ou=people, dc=yourSchool, dc=edu –Collaboration across higher education:

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

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

17 17 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 its important Choose distinguishedName (DN) carefully UID (rather than commonName: Jim Smith, Jim Smith?) DN should have domain component (dc) Structure can facilitate interoperation

18 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 19 object class inheritance (from Tim Howes et al., Understanding and Deploying LDAP Directory Services) More attributes Superior class person organizationalPerson top inetOrgPerson

20 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: ( NAME person DESC Standard ObjectClass SUP top MUST ( objectclass $ sn $ cn ) MAY ( aci $ description $ seeAlso $ telephoneNumber $ userpassword ) )

21 21 objectClasses, example of person entry for Babs Jensen RequiresAllows (naming info)(descriptive, contact info) sn: Jensendescription: directory manager cn: Babs JensentelephoneNumber: objectclass: topuserpassword: xxxxxx personseeAlso: cn=Fred Jensen Object class attributes can be multi-valued eduPersonAffiliation: staff, alum

22 22 LDIF (LDAP Data Interchange Format) – add attributes of eduPerson... dn: cn=schema changetype: modify... add: attributetypes attributetypes: ( NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX ' ' ) attributetypes: ( NAME 'eduPersonPrincipalName' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX ' ' SINGLE-VALUE )...

23 23 LDIF - add objectClass of eduPerson... dn: cn=schema changetype: modify... add: objectclasses objectclasses: ( NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation $ eduPersonNickname $ eduPersonOrgDN $ eduPersonOrgUnitDN $ eduPersonPrimaryAffiliation $ eduPersonPrincipalName $ eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN $ ))...

24 24 eduPerson objectClass Recommended objectClass for higher education eduPerson attributes: eduPersonAffiliation eduPersonPrimaryAffiliation eduPersonOrgDNeduPersonOrgUnitDN eduPersonPrincipalNameeduPersonPrimaryOrgUnitDN eduPersonNicknameeduPersonEntitlement eduPersonScopedAffiliation

25 25 OID policy OID arc - A unique Object Identifier Must have for local attributes/objectclasses –Enables interoperability Managed hierarchy ISO and ITU Can be obtained from a number of sources –To get one from IANA, fill out a form at No fee; turnaround relatively quick –To get one from ANSI, go to One- time fee; turnaround can take several weeks

26 26 OID arc - eduPersonAffiliation From IANA = IANA From eduPerson LDIF # is the toplevel OID for this [MACE] work #.1 = MACE related work #.1.1 = eduPerson # = attributes # = objectclass # = syntax (probably never used) #.1.2 = eduOrg # = attributes # = objectclass # = syntax (probably never used) add: attributetypes attributetypes: ( NAME 'eduPersonAffiliation… )

27 27 Superior arc ( )? * IANA * Internet Private * OID assignments from Internet * US Department of Defense *1.3 - ISO Identified Organization *1 - ISO assigned OIDs *Top of OID tree

28 28 Case Study Enabling Shibboleth

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

30 30 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 (cant 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 31 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.

32 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 33 Architecture/Policy components 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 eduPerson schema – attributes for interoperation LDAP Recipe Cf. PubCookie – or other single signon methods Trust Federations – InQueue (exploring) – InCommon (production) OpenSAML for secure transmission

34 34 Shibboleth Flow (circa 2004 Architecture doc) Handle Service Authentication System Attribute Authority WAYF ( Where are you from ?) Web resource ( Service Provider Inter-Site Transfer Service Identity ProviderSource Provider

35 Access Web Resource – EBSCO University Library Shibboleth Pilot info page (c/o Laura Burtle) 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) Direct access to next Shibboleth site – (no WAFY, no login) 2. Do your thing. 1 (NOT 4) steps: 1. Pick url [2. NA] [3. NA] [4. NA] Use resource

42 JSTOR site knows its 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 = eduPersonEntitlement= urn:mace:oclc:org… (eduPerson schema)

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

45 45 Shibboleth Federation animation/demo Federated identity UKs Joint Information Systems Committee animationanimation Shibboleth demo

46 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:

47 47 Shibboleth growth Concept 2003 Working groups, understanding use cases NSF funding Pilots, standards Federations European & World initiatives Shibboleth in use:

48 48 Questions? Discussion Thank you! Art Vandenberg

Download ppt "1 CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth Art Vandenberg Account Rep, Information Systems & Technology."

Similar presentations

Ads by Google