cis 8020 case study identity management architecture enabling shibboleth
DESCRIPTION
CIS 8020 Case Study Identity Management Architecture Enabling Shibboleth. Art Vandenberg [email protected] Account Rep, Information Systems & Technology Georgia State University November 10, 2009. Abstract - PowerPoint PPT PresentationTRANSCRIPT
1
CIS 8020Case Study
Identity Management ArchitectureEnabling Shibboleth
Account Rep, Information Systems & TechnologyGeorgia 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
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
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 (!)
System (type)System (type) Who Assigns?Who Assigns? Who Gets One?Who Gets One?
netid (alpha) Central IT PeopleuniversalUserID (num) Central IT Peopleaffiliate (AFF+num) Campus Sponsors guestsemail (first.last@…edu) Campus Units Faculty, staffstuMail (fLast#@…edu) Central IT Accepted studentssisID (SSN) Registrar Students & instructorshrID (SSN) HR Staff using HR/Payrollalumni ([email protected]) Alumni Assn Alumni and othersadsID (ADS#@fnd….edu) Marketing & Adv Graduates, other donorsOneCard (16 digit ISO#) Auxiliary Employees, students, affiliatesoperatorID (alphaNum) Controller ERP security principalspatronID (barcode number) Library Library patrons
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
DATA
SOURCES
APPL ICAT IONS
DIRECTORY ENABLING
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
• DIT: Not flat, no unique uid, no dc-namingo=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
Cn=Jan Smith, ou=ACS, ou=Information Systems, o=Georgia State University
and sub-Depts…
Same Jan?
Info per Dept
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 by function
Info for enterprise
Unique idacross 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)
• 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
19
object class inheritance (from Tim Howes et al., Understanding and Deploying LDAP Directory Services)
More attributesSuperior class
person
organizationalPerson
top
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.6NAME “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 managercn: Babs Jensen telephoneNumber: +1 650 555 1234objectclass: top userpassword: xxxxxx
person seeAlso: cn=Fred Jensen
• Object class attributes can be multi-valuededuPersonAffiliation: staff, alum
22
LDIF (LDAP Data Interchange Format) – add attributes of eduPerson
...dn: cn=schemachangetype: modify...add: attributetypesattributetypes: ( 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 educationhttp://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 Study
Enabling 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 preservationCampus Ids
Attribute AuthorityPrivilege management
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
Shibboleth Flow (circa 2004 Architecture doc)
Handle Service
Authentication System
Attribute Authority
WAYF (Where are you from?)
Web resource(http://www.site)
1. http://www.site
2.
3.
4.
5.
6.
9.
8.7.
10.
Service Provider
https://www.site
Inter-Site Transfer Service
Identity Provider Source Provider
Access Web Resource – EBSCO
University LibraryShibboleth Pilot
info page (c/o Laura Burtle)www.library.gsu.edu/shib/
1. EBSCO test URL
Redirect via WAYF
InQueueFederation
(for pilot testing)
2. Pick yourShib origin
(these are Inqueuesites recognized
by target WAYF)
Shibboleth Origin – Local Login
3. Use local authentication(CampusID/pw)
Successful Authentication
4. Authenticated user isbeing directed to web site…
(with Authorization checkingbehind the scenes)
Use EBSCO Web Resources
AccessingEBSCO research
Databases.
5. Do your thing.
4 steps:1. Pick url2. Pick origin3. Login4. Verification
Use resource
Access Web Resource – JSTOR
1. Now SelectBrowse JSTOR
(continuing currentbrowser session)
Access, no Re-login (Shib saves session)
Direct access tonext 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
JSTOR site knows it’s GSU
“Your access to JSTORis provided by
Georgia State University”(identity not passed,
but attributes may be)
OCLC / authorization attributes
OCLC needs no further authentication,but does require specific attributes
eduPersonAffiliation = [email protected]= urn:mace:oclc:org…
(eduPerson schema)
OCLC web resources
Appropriate attributespermit access...
OCLC recognizesGeorgia State member
(and contract)
45
Shibboleth Federationanimation/demo
• Federated identityhttp://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