Shibboleth Architecture and Requirements

1. Shibboleth Architecture and Requirements Shibboleth A New Approach to Web Based Access Control (and beyond…) EuroCAMP

2. Overview • Introduction to Shibboleth • Key concepts in the code • Deploying Shibboleth

3. What is Shibboleth? • An Architecture and Protocol • A set of profiles based on the OASIS SAML 1.1 standard • A Project sponsored by Internet2/MACE • Charged with defining the Shibboleth Arch, developing an open source implementation, and supporting the deploy of Shibboleth through the Higher Ed environment • Develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services • An Implementation of the Shibboleth Architecture • Developed by the I2/MACE Shibboleth Project • There are other independent implementations

4. 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 interrealm trust fabrics: federations and virtual organizations • Leverage campus expertise and build rough consensus • Influence the marketplace; develop where necessary • Support for heterogenity and open standards

5. Attribute-based Authorization • IP Address-based approach • The resource checks the browser's IP address against a table. Browsers using an IP address assigned to campus X are given campus X’s authorizations • Most campuses run proxy servers, to allow access from off-campus • Identity-based approach • The identity of a prospective user is passed to the controlled resource and is used to determine whether to permit access. • This approach requires the user to trust the resource to protect privacy. • Attribute-based approach • Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. Identity MAY be an attribute… • This approach does not degrade privacy.

6. Shibboleth Status • V1.2.1 available fall 2004 • In production use by commercial information providers (eg Elsevier SD, OCLC) • Growing international takeup (countrywide deploys in HE underway in Switzerland, Finland, UK, and others…) • Deploy rate on US campuses accelerating…. • Production Federations now available • Recent meeting of “League of Federations” • On track for certification by US Federal E-Authn Initiative

7. What are federations? • An association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions. • Built on the premise of • “Enroll and authenticate and attribute locally, act federally.” • Federation provides only modest operational support and consistency in how members communicate with each other • Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision. • Over time, this will all change…

8. Shibboleth -- Next Steps • Plan for a Multi-Federation World • Improved management tools • Shibboleth 1.3 early 2005 • Reduces reliance on inflexible PKI validation code • e-Auth, compliance • WS-Fed compliance in 1.3.x • Shibboleth 2.0, using SAML 2.0, represents greatly enhanced functionality; work begins after 1.3 is released • Shibboleth project will be segmented and expanded • Extended beyond the web; some flows may not use all existing components in the same way

9. Benefits to Campuses • Much easier Inter-Domain Integration • With other campuses • With off-campus vendor systems • Integration with other campus systems, intra-domain • LMS • Med School…… • Ability to manage access control at a fine-grained level • Allows personalization of services, without releasing identity • Implement Shibboleth once… • And then just manage attributes that are released to new targets

10. Benefits to Services/Vendors • Shibboleth is built on open standards • Unified authentication mechanism from the vendor perspective • Much more scalable • Much less integration work required to bring a new customer online. • Ability to implement fine-grained access control (e.g. access by role), allowing customer sites to effectively control access by attributes and thus control usage costs, by not granting access unnecessarily • Once the initial Shibboleth integration work has been completed on the vendor’s systems • The incremental cost of adding new customers is relatively minimal • In contrast to the current situation -- requiring custom work for each new customer • Ability to offer personalization • If your customers have Shibboleth implemented, easy implementation of service for them

11. WAYF Service Provider Web Site Identity Provider 5 3 2 4 6 1 7 Credentials 8 ACS HS Handle User DB Handle Resource Resource Manager 9 Handle AA AR Attributes 10 Attributes © SWITCH The Architecture of Shibboleth

12. Shibboleth: The Project, the Architecture, and the Code • Project encompasses design, direction • Architecture describes what a Shibboleth implementation should do • Code is “An” implementation of the architecture • In the code, some logical architectural components combined; others don’t exist; some exist in strange form • RM functionality exists in several places

13. Shibboleth as Implemented by Internet2 • Java IdP, C++ SP for Apache and IIS, Java SP in development • Extremely flexible and modular • Built on included OpenSAML; supports SAML 1.0, 1.1, and will support 2.0 • Supports SAML Browser/POST profile • SAML Artifact Profile will be supported in v1.3 • Other implementations exist

14. Key Concepts • SAML • Attributes in an Inter-Realm Context • Metadata and ProviderIDs • Credentials and Relying Parties • Attribute Release Policies (ARP’s) • Attribute Acceptance Policies (AAP’s)

15. SAML • Security Assertion Markup Language • Codified by OASIS’ SSTC with participation from MACE and other bodies • Defines XML schema for Authentication and Attribute Assertions, Queries and Responses, and profiles of use like Web SSO • Defines bindings to protocols for transport • Many vendor implementations support SAML 1.x • v2.0 expands to include concepts from Liberty Alliance and Shibboleth

16. Shibboleth vs SAML • Shibboleth is a profile of SAML • Shibboleth Architecture document describes how Shibboleth uses SAML • Shibboleth extends SAML, defining a new NameIdentifier (the Handle) • 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

17. Attributes in an Inter-Realm Context • Provided by IdP, validated and evaluated by SP • Converted to SAML form for transport • Federations guide usage of common attributes and values, e.g. eduPerson, courseID • Others defined within bilateral relationships • Who can assert which attributes? • What level of assurance is there that this data is accurate?

18. LDAP to SAML as performed by AA LDAP: objectclass: eduPerson dn: uid=magneto, ou=people, dc=supervillain, dc=edu eduPersonAffiliation: staff SAML: <Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <AttributeValue Scope=”supervillain.edu"> staff </AttributeValue> </Attribute>

19. Metadata and ProviderIDs • A ProviderID is the basic atom of inter-realm policy and trust; the molecule is the enterprise • URI (urn:mace:inqueue:supervillain.edu, or https://dspace.osu.edu/shibboleth) • Each SP or IdP deployment may encompass multiple logical "providers" • XML-based "metadata" about providers in a federation is exchanged to configure and secure interactions • Must be carefully defined; defines distributed use of enterprise Shibboleth infrastructure • Care must be taken when defining ProviderIDs for single or multiple federation use

20. Credentials and Relying Parties • Metadata includes references to (or actual) the credentials used by providers within a federation to sign XML or create SSL connections • A Relying Party is the other end in a transaction, and may represent an individual provider or a collection of providers • Configuration of software enables decisions about behavior and credentials to be made per-relying-party, allowing flexibility

21. Attribute Release Policies (ARPs) • Policies at the IdP governing the release of attributes to various service providers (based on an SP's ProviderID, which is its "name") • ARPs limit attributes released to a relying party on a global or per-user basis • Can match individual SPs or regular-expression-based matches; supports both positive and negative attribute rules

22. ARP Example <Rule> <Target> <AnyTarget/> </Target> <Attribute name=“urn:mace:dir:attribute-def:eduPersonScopedAffiliation”> <AnyValue release=“permit”/> </Attribute> </Rule>

23. Attribute Acceptance Policies (AAPs) • AAPs filter received attributes before they are used by applications or as part of access control decisions • Also enforces privacy by limiting information available in the Shibboleth runtime to applications based on what they need • Partial answer to who can assert which attributes • Collectively define the set of attributes available to the resource manager to make access decisions

24. The Attribute Exchange • AA • Finds all relevant ARPs, based on relying party’s ProviderID • Computes “effective ARP” • Obtains attribute values for this user from the Attribute Repository • Uses effective ARP to filter values • SAML transports attributes; processed by AAPs • Together, help define total set of information in a Shibboleth exchange

25. Apache mod_shib mod_ssl OpenSSL Simplified (Apache-based) Service Provider Architecture AR WAYF Origin MySQL Session DB

26. Shibboleth Service Provider Deploy • Shibboleth is implemented as: • A set of plugins to Apache/IIS • Handle “no authenticated session yet” situation • Create authenticated sessions • Separate Attribute Requester (AR) process to maintain session info and offload most heavy lifting and SAML processing • (optional, for web farm deploys) database to hold session info • pluggable interfaces enable customization of most core behavior

27. Service Provider Request Mapping Architecture Web Server Webapps, pages, files, etc. AAPs and access decisions Lazy Session Initiation ProviderID Foo pID Bar Attribute Release, Policy Atom App Alpha App Beta App Theta Sessions, Most Settings URL 1 URL 2 URL 3 URL 4 Externally Visible Resources Resource Requests

28. Applications, ProviderIDs, and Webapps • Decouples internal applications and session boundaries from externally visible services • Access controls can be defined at many granularities • Rules must be simple right now or enforced by application code examining HTTP headers • More complicated rules engines (XACML, SPOCP, complex XML booleans) under consideration/development • Much of this should be hidden from users

29. Lazy Sessions • Allows an application to call for a Shibboleth session when needed • Alternative to having web server/servlet container trigger session creation based on url path • Invoked using a special redirect URL • Rest of session establishment occurs as usual • Session might expire, but application is responsible for dealing with that

30. Attribute Consumption and Use • Exported via HTTP header variables • Other information about the authenticated session available in header values • Simple RM functionality included for Apache; using .htaccess, <Location> blocks, etc., require attribute values. Limited policy expression.

31. System Requirements • Built successfully on OS X 10.3, Solaris 2.8+, Debian, RedHat 7.2, 7.3, 9, Fedora, Enterprise, Windows NT/2000/XP/2003 • Binaries available for Windows; RPM’s available for Fedora and compatibles • Apache 1.3 or 2.0 with SSL Support, or IIS 4.0+ • OpenSSL • Several prerequisite packages must be built from source or installed via RPM

32. Logging & Auditing • All transactions can be logged; flat-file logging and log4j/log4cpp-based appenders both supported • Multiple logging levels • The user’s privacy is preserved; so is their identity • Federation may help define practices: some information storage requirements for SPs may require co-operation from IdPs. • Decision logic may be hidden at either the IdP or SP by constructive use of attributes

33. Typical Shibboleth + Application Deploy Scenarios • Everything behind the front door is protected • Web server does Authn + Authz; application serves data • Existing Session/Authn infrastructure • Only "front door/login" protected via Shib, application session created as a result, with subsequent requests tied to application session • One URL for all resources; parameters specify which resource is desired • Application does Authz processing after identifying desired resource • One URL for all resources; parameters specify which resource is desired; some resource is public and some is protected • Application does Authz processing after identifying desired resource

34. Federations in Practice • Define policies and practices that members promise to adhere to • Defines attribute & trust rules • May issue certificates to participants • Distributes 3 configuration files: • ca-bundle.crt (legacy-format trust list) • sites.xml (metadata) • trust.xml (trust configuration) • May provide a WAYF Service

35. Service Providers -Costs of Integrating with Shibboleth • Implementation • Resources, systems • What is your current environment? • Web server farm implementation? • Pilot • Going to Production • Integrating with existing front door • Integrating into web server farm • Supporting Deep Linking

36. InCommon Federation Membership • Service Provider Charges • I2 member $700 initial processing fee • $1K annual membership fee (includes 20 providerIds) • Additional providerIds available in packages of 20

37. Potential Savings After Integrating With Shibboleth • No more customized support for Authn Systems • No more maintenance of IP address tables • No more maintenance of userids and passwords • Lower help desk costs

38. Level of involvement from vendor participants • Comments and feedback about issues related to integration of Shibboleth with the vendor's target arch • (optional) participation in InCommon governance...... • (optional) participation in discussions including Shib architects and other vendors about improving the user experience with Shibboleth-enabled targets (eg with cross-site deep-linking transfers) • Participation in Shibboleth Academic SIG group

39. Deployment Resources • http://shibboleth.internet2.edu • http://inqueue.internet2.edu • Origin: • http://shibboleth.internet2.edu/guides/deploy-guide-origin-1.2.1.html • http://shibboleth.internet2.edu/guides/identity-provider-checklist.html • Target: • http://shibboleth.internet2.edu/guides/deploy-guide-target-1.2.1.html • shibboleth-users@internet2.edu