Presentation on theme: "Art Vandenberg Account Rep, Information Systems & Technology"— Presentation transcript:
1CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth Art VandenbergAccount Rep, Information Systems & TechnologyGeorgia State UniversityNovember 10, 2009
2AbstractA 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.
3Identity Management Goals Deliver services to customers, correctly & securelyProvide online service for entire life cycleSimplify end user experienceFacilitate provisioning of those services by ITIntegrate across traditional applications & dataOperate inter-organizational, collaborative environments - students, research, staff, affiliatesEngage the attendees. What are other drivers for ID Management?
4Systems Integration Goal Enterprise-wide, policy-driven identity and access management infrastructure that supportsScalabilityConsistencyIntegrationCollaboration
5Identity Environment Drivers Constituent Requirements Institutional GoalsConstituent RequirementsDriversPolicy & GovernanceStandardsPracticesProductsTechnologyProject ManagementBudgetStaff Skills/ExpertiseAbility toImplementIdentity ManagementPicture worth a thousand words.Standards: LDAP, SSL, authentication, Unix, Windows…Practices: documents, project management, resource managementProducts: Sun, IBM, Novell, AD… Also, ERP systems, Mail, networksInstitutional Goals: Campus Strategic plan, IT plan, objectivesDrivers: enrollment, new programs, , security, collaboration, …?Constituent reqs: Students, faculty, staff, Management, parents, Federal, StateBudget: $$$, central/distributed, public/private, research?Project Mgmt: Ad hoc, PM maturity, dedicated or sharedStaff skill: what they know now, what you need, training, hands-on options…
6Identifiers for authentication Motivation for Enterprise Identifier StrategyFoundation: userids, authN, authZ, directories…Moving from stovepipes to enterprise focus“Unified name space” enables support for multiple appsImplications:Unique ids (enterprise-wide, not application)Policies needed for creation, assignment, use of idsProcess needed to manage identifiersReconciliation of multiple identitiesRefer to Identifier worksheet, provided by Roadmap.
7Identifiers, aspects of Identifier characteristicsReadability ProvisioningPersistence UniquenessIntelligence Public visibilityIdentifier typesUID (uuid/guid) person registry IDAccount login netidssn (student, emp) publicly visible IDaddress library/departmentalPseudonymous ID Administrative systems IDRef 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).”
8Identifiers, examples of (!) System (type)Who Assigns?Who Gets One?netid (alpha)Central ITPeopleuniversalUserID (num)affiliate (AFF+num)Campus SponsorsguestsCampus UnitsFaculty, staffstuMailAccepted studentssisID (SSN)RegistrarStudents & instructorshrID (SSN)HRStaff using HR/PayrollalumniAlumni AssnAlumni and othersadsIDMarketing & AdvGraduates, other donorsOneCard (16 digit ISO#)AuxiliaryEmployees, students, affiliatesoperatorID (alphaNum)ControllerERP security principalspatronID (barcode number)LibraryLibrary patronsExample 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.
9Identifiers and Authentication Password, kerberos, PKI –– solutions are availablePassword most prevalent, so how handle?Precrack password and enforce minimum lengthTo age or not to age? Resets managedFirst password assignment - how to handle securely?US Mail a one-time PW; require in person & photo IDFor remote, require departmental rep, supervisor + faxServer side pw managementLock after repeat fail attempts; no clear text store; audit trails;Root/superAdmin separated from usersAuthentication 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.
10Authentication - Policy Implications Policies cannot be separate from ID/AuthNPolicy decisions may include:Distinct passwords for internal/external or for different levels of securityRethinking value of single sign-on… (reduced sign-on)Best practice recommendation to work in secure environment may imply technical requirement (SSL…)Deciding who assigns IdentifiersFormat, persistence, reuse of identifiersDitto: refer to Identifiers, Authentication, and Directories: Best Practices for Higher Education
11ID Management - underlying data elements DirectoriesMetadirectory & Application EnablingDirector Information Tree architectureObjectClassesOIDSAs 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.)
12DirectoriesEnterprise 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 controlsMetadirectory– 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 nounsDirectories are adjectivesMetadirectories are verbsStart 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
13DATA APPL ICAT IONS DIRECTORY ENABLING SOURCES Use this diagram to speak from. Overall concept of Middleware:Data sources (business ERP, other sources) enter from leftRequires joins, ID resolution, assignment of enterprise identifiersData targets (applications, services) exit at rightTransformation rules may apply (cf. convert 10 digits to phone#)Middle is Enterprise Directory Service comprised of:Metadirectory (person registry, intelligence & business rules)Physical directoriesOther 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 LDAPassigned in person registry, passed back to SCT Banner StudentCampus ISO number assigned in person registry, passed to PeoplesoftNot 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
14Directory Information Tree (DIT) Design for interoperability, discoveryDC (domain component) namingLeverage Domain Name System to provide uniquenessOu=people, dc=yourSchool, dc=eduCollaboration across higher education: yourSchool.eduUse 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.
15DIT: Not flat, no unique uid, no dc-naming o=Georgia State Universityou=Information Systemsou=ACSou=UCCScn=Art Vanncn=Jan Smithcn=Fran Westcn=Mae JonesCn=Jan Smith, ou=ACS, ou=Information Systems, o=Georgia State UniversityInfo per Deptand sub-Depts…Same Jan?Chalk talk (laser pointer would be nice?)Non-flat meaning levels can continue… and imagine if it wasGeorgia State UniversityCollege of Arts & SciencesDepartment of Modern LanguagesModern GreekNon-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”
16DIT: Flat, unique uid, dc-naming dc=edudc=gsuou=peopleou=unituid=avannuid=jsmithuid=jsmith2ou=acsou=uccsuid=jsmith2, ou=people, dc=gsu, dc=eduInfo for enterpriseInfo by functionContrast 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 idacross enterprise
17Directory Information Tree (DIT) Best Practice Design to improve interoperabilitySchemaFlat as possible - minimizes update overheadUID unique across tree - resolve identity!Accounts are person attributes (not a separate node of tree)Use dc naming: …dc=yourSchool, dc=eduNaming - why it’s importantChoose distinguishedName (DN) carefullyUID (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
18object Classesobject classes group related information, typically, modeling some real-world object such as a person, printer, or network device.object classes enable passing of informationobject classes include:An OID that uniquely identifies the classA name that also uniquely identifies the classA set of mandatory attributesA set of allowed attributesBasic 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.
19organizationalPerson object class inheritance (from Tim Howes et al., Understanding and Deploying LDAP Directory Services)More attributesSuperior classtoppersonHere 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.organizationalPersoninetOrgPerson
20object 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, auxiliaryMUST and MAY distinctionAlso see: UCDavis detail doc for schema based on eduPerson.
21objectClasses, example of person entry for Babs JensenRequires Allows(naming info) (descriptive, contact info)sn: Jensen description: directory managercn: Babs Jensen telephoneNumber:objectclass: top userpassword: xxxxxxperson seeAlso: cn=Fred JensenObject class attributes can be multi-valuededuPersonAffiliation: staff, alumWalk through this, taking your time.Note Requires “naming info” vs. allowed “descriptive, contact info”i.e. MUST attributes vs. MAY attributesTouch on multi-valued - not like RDBMS where multi-values is poor practice in table design.
22LDIF (LDAP Data Interchange Format) – add attributes of eduPerson ...dn: cn=schemachangetype: modifyadd: attributetypesattributetypes: (NAME 'eduPersonAffiliation'DESC 'eduPerson per Internet2 and EDUCAUSE'EQUALITY caseIgnoreMatchSYNTAX ' ' )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 )
23LDIF - add objectClass of eduPerson ...dn: cn=schemachangetype: modifyadd: objectclassesobjectclasses: (NAME 'eduPerson'AUXILIARYMAY ( 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 fileldapmodifiy commandldapmodify to add attributes/objectlcassldapmodify to add entries
24eduPerson objectClass Recommended objectClass for higher educationeduPerson attributes:eduPersonAffiliation eduPersonPrimaryAffiliationeduPersonOrgDN eduPersonOrgUnitDNeduPersonPrincipalName eduPersonPrimaryOrgUnitDN eduPersonNickname eduPersonEntitlementeduPersonScopedAffiliationNational Institute of Standards and Technology, 1995Auxiliary Object ClassEach 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".(fromRedefinition implies need to unload data, change objectclass, reload. Compare to relational database tables - changing table column definition would require unload, rebuild, reload.
25OID policy OID arc - A unique Object Identifier Must have for local attributes/objectclassesEnables interoperabilityManaged hierarchy ISO and ITUCan be obtained from a number of sourcesTo get one from IANA, fill out a form at No fee; turnaround relatively quickTo get one from ANSI, go to One-time fee; turnaround can take several weeksTake a moment to work through this.Key point - it’s easy, apply and get one.
26OID 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: attributetypesattributetypes: (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…)5922.214.171.124.1
27Superior arc ( )?* IANA* Internet Private* OID assignments from Internet* US Department of Defense* ISO Identified Organization* 1 - ISO assigned OIDs* Top of OID treeJust so they can see that there is some “authority” behind this OID Arc scheme.
29Shibboleth building upon identity management Given a good enterprise directory, unique id, middleware basis…Consider a need for LIBRARYAuthenticated / authorized access to Vendor DatabaseCase 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.
30Web Authentication/Authorization Privacy Preserving Security Access to digital library resources (vendor databases)Some solutions have policy & technology limits:IP-based access – spoofable, limitingProxy server – slightly betterGroup accounts – obvious drawbacks (can’t id exactly)Additional management of accounts & passwordsmanagement hassles, synchronization complexityextra accounts for userslag 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.
31Shibboleth Single Sign-on and Federating Software specifically addresses the challenges of Multiple passwords required for multiple applicationsScaling the account management of multiple applicationsSecurity issues associated with accessing third-party servicesPrivacyInteroperability within and across organizational boundariesEnabling institutions to choose their authentication technologyEnabling service providers to control access to their resources.Policy Elements: must be addressed for Shibboleth implementations.
32Shibboleth Pilot Solution (2004) University Library Provides secure access (not proxied)Leverages local enterprise authenticationAccess is based on role attributes (finer grained)Enables access from anywhere on webReduces loginsStronger authentication (not IP)Addresses user privacyPOLICY Elements:Trust Federation;Privacy preservationCampus IdsAttribute AuthorityPrivilege managementPolicy Elements: must be addressed for Shibboleth implementations.
33Architecture/Policy components OpenSAML for secure transmissionSun Solaris for Shibboleth OriginApache, Tomcat, J2SEOrigin site (Identity Provider) requirementsHandle Serversingle signon (SSO) or web initial signon (WebISO)Attribute Authorityrepository (mySQL or LDAP)Target site (Source Provider) requirementsInter-Site Transfer ServiceService ProviderWAYFResource ManagerCf. PubCookie– or other single signon methodseduPerson schema– attributes for interoperationThese components provide implementation of policy/technology for secure authN/AuthZ.LDAP RecipeTrust Federations– InQueue (exploring)– InCommon (production)
34Shibboleth Flow (circa 2004 Architecture doc) https://www.site1.Authentication SystemInter-Site Transfer Service2.WAYF (Where are you from?)4.3.6.Handle Service5.Service Provider7.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 Authority9.Web resource(http://www.site)Identity ProviderSource Provider
35Access Web Resource – EBSCO University LibraryShibboleth Pilotinfo page (c/o Laura Burtle)1. EBSCO test URL
36Redirect via WAYF InQueue Federation (for pilot testing) 2. Pick your Shib origin(these are Inqueuesites recognizedby target WAYF)
37Shibboleth Origin – Local Login 3. Use local authentication(CampusID/pw)
38Successful Authentication 4. Authenticated user isbeing directed to web site…(with Authorization checkingbehind the scenes)
39Use EBSCO Web Resources AccessingEBSCO researchDatabases.5. Do your thing.4 steps:1. Pick url2. Pick origin3. Login4. VerificationUse resource
40Access Web Resource – JSTOR 1. Now SelectBrowse JSTOR(continuing currentbrowser session)
41Access, no Re-login (Shib saves session) 1 (NOT 4) steps:1. Pick url[2. NA][3. NA][4. NA]Use resourceDirect access tonext Shibboleth site –(no WAFY, no login)2. Do your thing.
42JSTOR site knows it’s GSU “Your access to JSTORis provided byGeorgia State University”(identity not passed,but attributes may be)
43OCLC / authorization attributes OCLC needs no further authentication,but does require specific attributeseduPersonAffiliation =eduPersonEntitlement= urn:mace:oclc:org…(eduPerson schema)
44Appropriate attributes OCLC web resourcesAppropriate attributespermit access...OCLC recognizesGeorgia State member(and contract)
45Shibboleth Federation animation/demo Federated identityUK’s Joint Information Systems Committee animationShibboleth demoJust 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.
46Shibboleth Success Factors Addresses an important aspect of security – privacyLeverages enterprise directory to implement PolicyFederation Policy model resonates with shared libraries conceptsStandards basedMore 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.
47Shibboleth growth Concept 2003 Working groups, understanding use cases NSF fundingPilots, standardsFederationsEuropean & World initiativesShibboleth 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.