Presentation is loading. Please wait.

Presentation is loading. Please wait.

Art Vandenberg Account Rep, Information Systems & Technology

Similar presentations

Presentation on theme: "Art Vandenberg Account Rep, Information Systems & Technology"— Presentation transcript:

1 CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth
Art Vandenberg 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. 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.

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 Engage the attendees. What are other drivers for ID Management?

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

5 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, , 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…

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 Refer to Identifier worksheet, provided by Roadmap.

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 address library/departmental Pseudonymous ID Administrative systems ID 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).”

8 Identifiers, examples of (!)
System (type) Who Assigns? Who Gets One? netid (alpha) Central IT People universalUserID (num) affiliate (AFF+num) Campus Sponsors guests Campus Units Faculty, staff stuMail Accepted students sisID (SSN) Registrar Students & instructors hrID (SSN) HR Staff using HR/Payroll alumni Alumni Assn Alumni and others adsID 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.

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

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 Ditto: refer to Identifiers, Authentication, and Directories: Best Practices for Higher Education

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

12 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 ( ). 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, 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 , 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

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 LDAP 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, , online web services, hardware platforms, technical support)? DIRECTORY ENABLING

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

15 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 “”

16 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

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

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

19 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

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

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

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' SYNTAX ' ' 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: ( NAME 'eduPersonOrgDN' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY distinguishedNameMatch SYNTAX ' ' SINGLE-VALUE )

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

24 eduPerson objectClass
Recommended objectClass for higher education eduPerson attributes: eduPersonAffiliation eduPersonPrimaryAffiliation eduPersonOrgDN eduPersonOrgUnitDN eduPersonPrincipalName eduPersonPrimaryOrgUnitDN eduPersonNickname eduPersonEntitlement eduPersonScopedAffiliation 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 Redefinition implies need to unload data, change objectclass, reload. Compare to relational database tables - changing table column definition would require unload, rebuild, reload.

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 Take a moment to work through this. Key point - it’s easy, apply and get one.

26 OID arc - eduPersonAffiliation
From IANA = From eduPerson LDIF # is the toplevel OID for this [MACE] work # = MACE related work # = eduPerson # = attributes # = objectclass # = syntax (probably never used) # = eduOrg # = attributes # = objectclass # = 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…) 5923 .1 .1 .1 .1

27 Superior arc ( )? * IANA * Internet Private * OID assignments from Internet * US Department of Defense * 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.

28 Case Study Enabling Shibboleth

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

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

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. Policy Elements: must be addressed for Shibboleth implementations.

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 Policy Elements: must be addressed for Shibboleth implementations.

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 These components provide implementation of policy/technology for secure authN/AuthZ. LDAP Recipe Trust Federations – InQueue (exploring) – InCommon (production)

34 Shibboleth Flow (circa 2004 Architecture doc)
1. 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 ( Identity Provider Source 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)
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 = eduPersonEntitlement= urn:mace:oclc:org… (eduPerson schema)

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

45 Shibboleth Federation animation/demo
Federated identity UK’s Joint Information Systems Committee animation Shibboleth demo 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.

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

47 Shibboleth growth Concept 2003 Working groups, understanding use cases
NSF funding Pilots, standards Federations European & World initiatives Shibboleth in use: 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.

48 Questions? Discussion Thank you! Art Vandenberg

Download ppt "Art Vandenberg Account Rep, Information Systems & Technology"

Similar presentations

Ads by Google