cis 8020 case study identity management architecture enabling shibboleth

1

CIS 8020Case Study

Identity Management ArchitectureEnabling Shibboleth

Art VandenbergAvandenberg@gsu.edu

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 (alpha@alum.edu) 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 = member@gsu.edueduPersonEntitlement= 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

48

Questions? Discussion

Thank you!

Art Vandenbergavandenberg@gsu.edu