shibboleth 2.0 : an overview for developers scott cantor [email protected] the ohio state university...
TRANSCRIPT
Shibboleth 2.0:An Overview for DevelopersShibboleth 2.0:An Overview for Developers
Scott [email protected] Ohio State University / Internet2
Scott [email protected] 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