Shibboleth 2.0:An Overview for DevelopersShibboleth 2.0:An Overview for Developers

Scott Cantorcantor.2@osu.eduThe Ohio State University / Internet2

Scott Cantorcantor.2@osu.eduThe Ohio State University / Internet2

2

ResourcesResources

Web Sitehttp://shibboleth.internet2.edu/

Documentation Wikihttps://spaces.internet2.edu/display/SHIB2

Self-Service Testing Facilityhttp://www.testshib.org/

SAML Specificationshttp://www.oasis-open.org/committees/security

3

DefinitionsDefinitions

• Shibboleth Project• An umbrella of activities around federated authentication and

access management managed by Internet2 and its international partners, still mostly an ad hoc group

• Shibboleth Specifications• Historical extensions to SAML 1.1, now superseded by SAML

2.0• Strong commitment to standardization of any technical

invention done on behalf of the project

• Shibboleth System• Internet2-developed open-source implementation of various

federation standards, specifications, and value-added components• Competitive with but also interoperating with many commercial

and open source implementations

4

Key ConceptsKey Concepts

• Federated Identity

• Attribute-Based Single Sign-On

• Management of Release of User Data

• Standards Based

• Variety of Policy and Management Models

• Flexible Integration

5

HistoryHistory

• Shibboleth 1.x spanned 4 major releases and several minor ones over a span of about 4 years.

• Near-constant changes in terminology, configuration.

• Following original standards track while contributing to the next generation of standards.

• Essentially zero changes to actual applications across the entire release history.

General Descriptionof SAML 2.0 SSOGeneral Descriptionof SAML 2.0 SSO

• Service provider sends XML <AuthnRequest> message to a trusted identity provider through browser.

• Identity provider verifies identity of user and returns an XML <Response> message with an error or a signed SAML assertion to application through browser.

• Assertion is optionally encrypted with a key controlled by service provider.

• Security of system derived from keys exchanged among parties or indirectly via a PKI.

• Lots of options and features, either further profiling or very comprehensive implementations.

6

SAML 2.0 SSO Feature SetSAML 2.0 SSO Feature Set

• Federated, multi-domain use• Carries attributes as well as identity• <AuthnRequest> features:• control over login methods (AuthnContext)• bypassing SSO (ForceAuthn)• requiring SSO (IsPassive)• control over identifier type (NameIDPolicy)• future control of forwardable assertions

• Single Logout protocol, front and back-channel• Variety of deployment and trust models

7

Shibboleth 2.0 Value AddShibboleth 2.0 Value Add

• Uniform multi-protocol features• Advanced metadata exchange/processing• Internal / external authentication handlers• Zero-programming model for application

integration• Advanced attribute features:• Integration with back-end stores• Extensible filtering at both ends• SP resolution architecture

• Clustering8

Shibboleth Application ModelShibboleth Application Model

• SP software integrated with web server (Apache, IIS, Sun/iPlanet, FastCGI), not applications

• Middleware consumes SAML assertions and filters/processes the claims while providing session mgmt (SAML token in, cookie out)

• Applications generally written in terms of processed attributes, but can access raw tokens

Shibboleth Application ModelShibboleth Application Model

• Interface between applications and SP is designed to foster independence:• environment variables when possible• request headers otherwise

• Applications with existing security or session models can use a trivial “stub” application to translate incoming attributes (store them in a database by session key, encrypt into cookie, map to local account or group, etc.)

Typical DeploymentTypical Deployment

1. Install SP software into web server.• Includes a keypair generator

2. Publish SAML metadata about service configuration.• SP can now generate mostly accurate metadata• Self-hosted or submitted to a federation operator for vetting and signing

3. Utilize access control functionality (e.g. Apache htaccess) based on attributes, if rules can be expressed externally to application.

4. Write application, consuming attributes when and where required as appropriate for the programming environment.1. getenv(“HTTP_DISPLAYNAME”)

2. servletRequest.getAttribute(“displayName”)

3. Request(“HTTP_DISPLAYNAME”)

4. CGI.HTTP_DISPLAYNAME

5. …

Application / SP IntegrationApplication / SP Integration

• As much as possible done through configuration at deployment time:• settings applied by host, path, query string,

regular expressions

• Advanced features like runtime control over login process available via redirection into SP handlers with parameters to supply or override settings.

• Communication back to application also via redirects (e.g. notification of logout).

12

Without programming…Without programming…

• all protocol and XML processing

• authorization based on attributes, SAML authentication context, time since login

• session management with IP address enforcement

• mapping of attributes to one or more headers, anything to REMOTE_USER

13

ExamplesExamples

• Require authentication and .edu faculty affiliation:• .htaccess

AuthType shibbolethShibRequireSession Onrequire affiliation ~ ^faculty@.+\.edu$

• XML<Path name=“myapp/secure” requireSession=“true”><AccessControl><RuleRegex require=“affiliation” ignoreCase=“true”>^faculty@.+\.edu$</RuleRegex></AccessControl>

</Path>

14

ExamplesExamples

• Request a passive login(e.g. initial access to a portal):response.sendRedirect(

“/Shibboleth.sso/Login?isPassive=1”);

• Request a login via client certificate from Ohio State:response.sendRedirect(

“/Shibboleth.sso/Login” +“?entityID=“ +“urn:mace:incommon:osu.edu” +“&authnContextClassRef=“ +“urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”);

15

Current StatusCurrent Status

• 2.0 out, 2.1 imminent• bug fixes, additional clustering option using

memcached

• SP has more or less complete SAML 2.0 support

• IdP TODO list includes single logout and NameID management protocols

16

Roadmap ItemsRoadmap Items

• Information Cards• Real-time user consent• User provisioning, “introduction” problem• Java SP• REST, WS-Trust, and SAML-based token

requests• N-Tier solutions building on the previous item,

perhaps OAuth, Keberos ticket delegation• Integration/glue for popular app frameworks• IdP package with embedded container• …

17