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

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

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 “gsu.edu”

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