Deploying Shibboleth

Michael R Gettes

Duke University

Seminar 08P

What is Shibboleth? (Biblical)

• A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce “sh”, called the word sibboleth. See --Judges xii.

• Hence, the criterion, test, or watchword of a party; a party cry or pet phrase.

Webster's Revised Unabridged Dictionary (1913)

What is Shibboleth? (modern era)

•An initiative to develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services

•A project delivering an open source implementation of the architecture and framework

•Deliverables:–Software for Identity Provider–Software for Service Providers–Operational Federations (scalable trust)

So… What is Shibboleth?

•A Web Single-Signon System (SSO)?

•An Access Control Mechanism for Attributes?

•A Standard Interface and Vocabulary for Attributes?

•A Standard for Adding Authn and Authz to Applications?

Shibboleth Goals

• Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions

• Provide security while not degrading privacy.–Attribute-based Access Control

• Foster inter-realm trust fabrics: federations and virtual organizations

• Leverage campus expertise and build rough consensus• Influence the marketplace; develop where necessary• Support for heterogeneity and open standards

Attribute-based Authorization

• Identity-based approach–The identity of a prospective user is passed to the controlled resource and is used to determine (perhaps with requests for additional attributes about the user) whether to permit access.

–This approach requires the user to trust the target to protect privacy.

• Attribute-based approach–Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision.

–This approach does not degrade privacy.

How Does it Work?

Hmmmm…. It’s magic. :-)

The Environment

System

s of R

ecord

Identity Mgmt SystemApps / Resources

Grouper Signet Shibboleth

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

High Level Architecture

• Federations provide common Policy and Trust

• Service and Identity Provider site collaborate to provide a privacy-preserving “context” for Shibboleth users

• Identity Provider site authenticates user, asserts Attributes

• Service Provider site requests attributes about user directly from Identity Provider site

• Service Provider site makes an Access Control Decision

• Users (and Identity Provider organizations) can control what attributes are released

Technical Components• Identity Provider Site – Required Enterprise Infra

–Authentication–Attribute Repository

• Identity Provider Site – Shib Components–Handle Server–Attribute Authority

• Service Provider Site - Required Enterprise Infra–Web Server (Apache or IIS)

• Service Provider Site – Shib Components–Assertion Consumer Service - ACS–Attribute Requester - AR–Where Are You From Service - WAYF–Resource Manager

Res

ou

rce

WAYF

Identity ProviderService Provider

Web Site

1

ACS

I don’t know you.Not even which home

org you are from.Redirect your request

to the WAYF32

Please tell me where are you from?

HS

5

6

I don’t know you.Please authenticateUsing WEBLOGIN

7

User DB

Credentials

OK, I know you now.Redirect your requestto the target, together

with a handle

4

OK, I redirect yourrequest now to

the Handle Service of your home org.

AR

Handle

Handle8

I don’t know theattributes of this user.Let’s ask the Attribute

Authority

Handle9AA

Let’s pass over the attributes the userhas allowed me to

release

Attributes 10

Res

ou

rce

Man

ag

er

Attributes

OK, based on theattributes, I grant

access to the resource

http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Demo/Brown-demo.html

Demo!

Shibboleth Architecture (still photo, no moving parts)

Res

ou

rce

WAYF

Identity ProviderService Provider

Web Site

1

ACS

32

HS

5

6

7

User DB

Credentials

4

AR

Handle

Handle8

Handle9AA

Attributes 10

Res

ou

rce

Man

ag

er

Attributes

© SWITCH

Shibboleth Architecture -- Managing Trust

Service Provider

Web Server

Browser

TRUSTAttributeServer

Shibengine

Shibboleth DeploymentCommon Threads

Michael Gettes

Duke University

Seminar 08P (part 2)

Shibboleth as Part of the MACE IAM Model

Verb Objects

Reflect Data of interest from systems of record into registry, identity databases and maybe directories

Join Identity information across systems

Manage Credentials, group memberships, affiliations, privileges, services, policies

Provide Identity and Access info via

- run-time request/response

- provisioning into App/Service storesAuthenticate (AuthN) Claimed identities

Authorize (AuthZ) Access or denial of access

Log Usage for audit

Key Concepts - Shibboleth in Your Environment

• Federated Administration– Identity Provider Site– Service Provider Site

• Standards Based– Based on OASIS SAML specification– Interoperates with Many Vendor Products

• Attribute-Based Single Sign-On– Attributes Describe the Browser User, used for Access Control– Identity may be an attribute, but is optional– Location Independent -- NOT IP Based

• But location can be an Attribute

• Management of Privacy– Done via Attribute Release Policies (ARPs)– Site, Groups, and the User can control release of Attributes

Key Concepts - Shibboleth in Your Environment

• Framework for a Variety of Policy and Management Models

– Federations– Bilateral

• Extensible Authentication and Attribute Sharing– Federation defines syntax and semantics of common

Attribute/Value pairs– Two parties can define custom attributes

The Shibboleth System is…• an open source SAML-based Web SSO package

– Provides both intra- and inter-campus Web SSO– Implements the SAML Browser/POST and Browser/Artifact profiles– Is software that the campus installs -- NOT a service– Consultants are available to provide support

• relies on pre-existing authentication and attribute sources.– Authentication done against existing system– Attributes obtained from existing System

• portable to a variety of platforms and web server environments.• designed to SAML-enable applications.• minimal rather than all-encompassing in its scope to make

integration with existing environments and technology possible.• free to use and customize.

The Shibboleth System is NOT…

• Usable in non-Browser scenarios (without a lot of hard thinking)

• an identity management system.• a directory or database.• a complete soup-to-nuts solution for authentication and

attribute management.• a world-class SSO system (largely because it’s SAML

1.x-based at this stage).• hard to deploy once you have a general template for

how to proceed.

Shibboleth vs SAML

• The Shibboleth implementation includes a trust fabric implementation based on PKI

• The Shibboleth implementation includes a framework and metadata for identifying IdPs and SPs

• The Shibboleth implementation includes a mechanism (ARPs) to manage the release of attribute information to SPs

Shibboleth as Web Single SignOn System

• Originally described as solution for cross-domain Single SignOn– Library Use Case

• Just as useful for intra-domain SSO– Provides single solution

• Shibboleth/SAML currently is not defined for use outside of Web SSO…

Shibboleth - Interoperating with Vendor Products

• Interop testing done at Burton Catalyst summer 2005

• Successfully interop’ed – Using SAML 1.1– With several vendor products

• IBM (SAML 1.0 only), Sun, HP and Trustgenix (same code), CA/Netegrity, and BMC

– But NOT using the Shibboleth profile

Delivery of Attributes

• Why?– Growing number of applications need attributes

• Direct access to ldap, business DBs?• Shibboleth provides applications with standard, easy to use

interface• Shibboleth provides management interface for policy

– Applications are using attributes:• For access control• To build user profiles• To obtain a persistent identifier for each user• Differentiating constituencies (applicants vs alums vs

(faculty, student, staff)

Delivery of Attributes

• Identify Attribute Sources– Publicly available (ldap?)– Confidential (ldap, SQL)

• Identify Which Attributes are Available– Involvement of stakeholders?– Process to update this list…

• Define New Business Processes– How does an SP Request an Attribute?– Who decides whether they can have it?

Delivery of Attributes

• Define New Policies– SPs responsibility with respect to received

attributes• Proper handling• Who at the site has access to the log files….

– Dare we speak the word -- auditing?

• New Technical Roles– Who reconfigures the IdP:

• Attribute Authority connectors• Attribute definitions• Attribute Release Policies

Delivery of Attributes

• Help Desk– Problem resolution flow, when user denied access to

departmentally-based application– Who can see whether user has correct attributes?

• Students working on the help desk?• Staff supporting IdM?

– Process for getting the user the correct attributes…• Does user contact the “System of Record” Office?

– Contact Points in the departments that are using the SSO?

Levels of Assurance (LoA)

• Classify the requirements of an application

• Assign confidence levels for the ID Proofing and Electronic Authentication Processes

• Define mapping between Reqs and Confidence – As simple as a number (Levels 1,2,3,4).

– Define confidence in terms of application requirements and you can use the same value for both.

• An ID of LoA 4 can access Apps at 1-4

What is a Federation?

A collection of organizations, having implemented some form of Identity Management, where Credential Service Providers (CSP, Universities) and Service Providers (SP, Content Providers) agree to “rules of engagement” (policy and attributes) using federating software (Shibboleth, SAML, PKI)

What is a Federation? (Continued)

• Sounds simple? It can be. It can be made really complex, really fast.

• www.nmi-edit.org for more info• CSPs and SPs retain control over their

environments (identity data and access ctrl)• www.InCommonFederation.org

– Approx 37 participants (9/06), Launched 4/2005

• Inqueue.internet2.edu– Testing/Playground for InCommon– >225 participants (9/06) and GOING AWAY!

Shibboleth and Federation

• It’s real, uses SAML• Open source, freely available• Takes between 3 hours and 3 years to

install -- depending on IdM infra• In production at many schools

– For internal apps & external Univ vendors

• shibboleth.internet2.edu• www.incommonfederation.org

Federated Authentication

• Why?– Scholarship is now done via the Net..

• Both teaching and Research

– Access to Federated websites offered by US Federal Gov’t agencies (and lots of other Federal gov’ts!)

• Grant management• Student Financial Aid

– Access to Partners is• Simplified• More flexible• Under better control

– More secure…. (but why?)

Low Hanging Fruit

• Find the low hanging fruit for services needing shibboleth.– IIS support (Duke did not have it until Shib)– External Services to your Institution– Willing partners, working with “friends” in the

beginning makes for successful deployment.

• Keep it simple, in the beginning

Technology Threads

• Web versus …

• Easy is usually not - spend time with SPs to make sure they really understand. Give SPs test IDs so they don’t have to run IdP.

• SAML under the covers

• Details are solvable - but only until known

• Assumptions will kill you.

Policy Threads

• You can make this as complex as you like• It’s not about Shib - it’s about Apps gaining

access to attributes - only the attributes the Apps need.

• Privacy? Yes.• Limiting Data Exposure? Yes.• Distributing versus Distributed Data• More dynamic/responsive services

– 1 Hour turn-around for NetID provisioning @ Duke

SPs - Selling It!

• If you take the time to sell Shib to your SPs it benefits us all. We win and they win!– No more one-off solutions for each sale– SPs don’t need to issue identities/passwords– Less Help Desk support for password issues– Open Source and Open Standards– SAML based - ties into futures for AuthN/AuthZ where

SP won’t need to change– Federated Model -- forward looking for Higher Ed– Don’t pay for the development - HE already did the

hard work in this space and SPs reap benefits

Adoption in the GlobalHigher Education Space

• Finland• Sweden• Denmark• Germany• Switzerland• Greece• The Netherlands

• Belgium• France• Spain• The UK• Australia• New Zealand?• The US

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Additional Slides Not Presented

The Europeans Prioritized Vendor List

• Elsevier Science Direct• EBSCO• JSTOR• OVID (OvidWeb and WebSPIRS)• Thomson Science• Springer (Metapress)• Exlibris (Metalib, sfx)• EZProxy• Wiley• Taylor and Francis• Thomson Gale• Blackwell• Institute of Physics Publishing• Proquest• Muse (Johns Hopkins)• Nature (Highwire)• OUP Oxford University Press• American Chemical Society

Other Vendors…

• TurnItIn• Music (Napster, CDigix)• MSDN Academic Allliance

– http://msdn.microsoft.com/academic/

• American Education Services– http://www.aessuccess.org/

• The US Federal Government E-Authentication Initiative

– http://www.cio.gov/eauthentication/

Yet More Others…

• GridShib– http://gridshib.globus.org/

• LionShare– http://lionshare.its.psu.edu/

InCommon -- the US Higher Ed / Research Federation

• http://www.incommonfederation.org/• U.S. Higher Ed and its Partners

–Self-organizing–Heterogeneous

• Policy Entrance bar intentionally set low–IC doesn’t impose lots of rules and standards–Access to E-Authn may change this….

InCommon Requirements• Common Attributes• Software Guidelines

– www.incommonfederation.org/ops/softguide.html

• Transparency of Policy and Practices• Legal Agreement

– No Indemnification– Limited Liability– General Liability Insurance

• Annual Fee

What Does InCommon Provide

• Trust Management–Private Certificate Authority–Revocation Process

• Metadata management and distribution• WAYF

• Business relationships between members are separate

New Business Processes• ARP Management

– Local users/groups requesting Attribute Release to remote SPs

– See ShARPE

• How do local SPs apply for membership in IC?• How to ensure policy adherence of local SPs…

– Role of central IT/audit

• Help desk – problem resolution in a Federated world– Responding to remote sites reporting suspected abuse

Shibboleth 2.0• Advances with SAML 2.0 specification

– Convergence with commercial Liberty and SAML products– Interoperable privacy mechanisms now in the standard (transient and

federated/persistent IDs)– Single Logout– NameID Change/Term Management– Enhanced Client or Proxy (ECP) Profile

• Advances with Shibboleth 2.0– Authentication processing “in the box”

• Shibboleth 2.1 -- N-tier?– New Liberty Spec and “errata” to SAML 2.0

– Composed into https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/WebServices