170 likes | 303 Views
Shibboleth 2.0 : An Overview for Developers. Scott Cantor cantor.2@osu.edu The Ohio State University / Internet2. Resources. Web Site http://shibboleth.internet2.edu/ Documentation Wiki https://spaces.internet2.edu/display/SHIB2 Self-Service Testing Facility http://www.testshib.org/
E N D
Shibboleth 2.0:An Overview for Developers Scott Cantor cantor.2@osu.edu The Ohio State University / Internet2
Resources Web Site http://shibboleth.internet2.edu/ Documentation Wiki https://spaces.internet2.edu/display/SHIB2 Self-Service Testing Facility http://www.testshib.org/ SAML Specifications http://www.oasis-open.org/committees/security
Definitions • 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
Key Concepts • Federated Identity • Attribute-Based Single Sign-On • Management of Release of User Data • Standards Based • Variety of Policy and Management Models • Flexible Integration
History • 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 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.
SAML 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
Shibboleth 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 • Clustering
Shibboleth 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 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 Deployment • Install SP software into web server. • Includes a keypair generator • 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 • Utilize access control functionality (e.g. Apache htaccess) based on attributes, if rules can be expressed externally to application. • Write application, consuming attributes when and where required as appropriate for the programming environment. • getenv(“HTTP_DISPLAYNAME”) • servletRequest.getAttribute(“displayName”) • Request(“HTTP_DISPLAYNAME”) • CGI.HTTP_DISPLAYNAME • …
Application / 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).
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
Examples • Require authentication and .edu faculty affiliation: • .htaccess AuthType shibboleth ShibRequireSession On require affiliation ~ ^faculty@.+\.edu$ • XML <Path name=“myapp/secure” requireSession=“true”> <AccessControl> <RuleRegex require=“affiliation” ignoreCase=“true”>^faculty@.+\.edu$</RuleRegex> </AccessControl> </Path>
Examples • 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”);
Current 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
Roadmap 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 • …