1. Shibboleth 2.0 : An Overview for Developers Scott Cantor cantor.2@osu.edu The Ohio State University / Internet2 Scott Cantor cantor.2@osu.edu The Ohio State University / Internet2

2. 2 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

3. 3 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

4. 4 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

5. 5 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.

6. General Description of SAML 2.0 SSO Service provider sends XML message to a trusted identity provider through browser. Identity provider verifies identity of user and returns an XML 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

7. SAML 2.0 SSO Feature Set Federated, multi-domain use Carries attributes as well as identity 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

8. 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 8

9. 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

10. 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.)

11. Typical 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. getenv(“HTTP_DISPLAYNAME”) servletRequest.getAttribute(“displayName”) Request(“HTTP_DISPLAYNAME”) CGI.HTTP_DISPLAYNAME …

12. 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). 12

13. 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

14. Examples Require authentication and.edu faculty affiliation:.htaccess AuthType shibboleth ShibRequireSession On require affiliation ~ ^faculty@.+\.edu$ XML ^faculty@.+\.edu$ 14

15. 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”); 15

16. 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 16

17. 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 … 17