Shibboleth Architecture and Shibboleth Requirements A New Approach to Web Based Access Control (and beyond…) Euro. CAMP
Overview • Introduction to Shibboleth • Key concepts in the code • Deploying Shibboleth
What is Shibboleth? • An Architecture and Protocol – A set of profiles based on the OASIS SAML 1. 1 standard • A Project sponsored by Internet 2/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 I 2/MACE Shibboleth Project – There are other independent implementations
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
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 offcampus • 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.
Shibboleth Status • V 1. 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 EAuthn Initiative
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…
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
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
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
The Architecture of Shibboleth WAYF Identity Provider 5 4 3 2 Service Provider Web Site 6 1 7 Credentials Handle ACS Handle User DB 9 AA Attributes Handle 10 AR Attributes © SWITCH Resource 8 Resource Manager HS
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
Shibboleth as Implemented by Internet 2 • Java Id. P, C++ SP for Apache and IIS, Java SP in development • Extremely flexible and modular • Built on included Open. SAML; supports SAML 1. 0, 1. 1, and will support 2. 0 • Supports SAML Browser/POST profile • SAML Artifact Profile will be supported in v 1. 3 • Other implementations exist
Key Concepts • • • SAML Attributes in an Inter-Realm Context Metadata and Provider. IDs Credentials and Relying Parties Attribute Release Policies (ARP’s) Attribute Acceptance Policies (AAP’s)
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 • v 2. 0 expands to include concepts from Liberty Alliance and Shibboleth
Shibboleth vs SAML • Shibboleth is a profile of SAML – Shibboleth Architecture document describes how Shibboleth uses SAML – Shibboleth extends SAML, defining a new Name. Identifier (the Handle) • The Shibboleth implementation includes a trust fabric implementation based on PKI • The Shibboleth implementation includes a framework and metadata for identifying Id. Ps and SPs • The Shibboleth implementation includes a mechanism (ARPs) to manage the release of attribute information to SPs
Attributes in an Inter-Realm Context • Provided by Id. P, validated and evaluated by SP • Converted to SAML form for transport • Federations guide usage of common attributes and values, e. g. edu. Person, course. ID • Others defined within bilateral relationships • Who can assert which attributes? • What level of assurance is there that this data is accurate?
LDAP to SAML as performed by AA LDAP: objectclass: edu. Person dn: uid=magneto, ou=people, dc=supervillain, dc=edu edu. Person. Affiliation: staff SAML: <Attribute. Name="urn: mace: dir: attribute-def: edu. Person. Scoped. Affiliation" Attribute. Namespace="urn: mace: shibboleth: 1. 0: attribute. Namespace: uri"> <Attribute. Value Scope=”supervillain. edu"> staff </Attribute. Value> </Attribute>
Metadata and Provider. IDs • A Provider. ID 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 Id. P 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 Provider. IDs for single or multiple federation use
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 perrelying-party, allowing flexibility
Attribute Release Policies (ARPs) • Policies at the Id. P governing the release of attributes to various service providers (based on an SP's Provider. ID, 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-expressionbased matches; supports both positive and negative attribute rules
ARP Example <Rule> <Target> <Any. Target/> </Target> <Attribute name=“urn: mace: dir: attributedef: edu. Person. Scoped. Affiliation”> <Any. Value release=“permit”/> </Attribute> </Rule>
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
The Attribute Exchange • AA – Finds all relevant ARPs, based on relying party’s Provider. ID – 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
Simplified (Apache-based) Service Provider Architecture AR mod_shib WAYF Apache mod_ssl My. SQL Session DB Open. SSL Origin
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
Service Provider Request Mapping Architecture Webapps, pages, files, etc. AAPs and access decisions Lazy Session Initiation Web Server Provider. ID Foo p. ID Bar Attribute Release, Policy Atom App Alpha App Beta App Theta Sessions, Most Settings URL 1 URL 2 URL 3 Resource Requests URL 4 Externally Visible Resources
Applications, Provider. IDs, 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
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
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.
System Requirements • Built successfully on OS X 10. 3, Solaris 2. 8+, Debian, Red. Hat 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+ • Open. SSL • Several prerequisite packages must be built from source or installed via RPM
Logging & Auditing • All transactions can be logged; flat-file logging and log 4 j/log 4 cpp-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 Id. Ps. • Decision logic may be hidden at either the Id. P or SP by constructive use of attributes
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
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
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
In. Common Federation Membership • Service Provider Charges – I 2 member $700 initial processing fee – $1 K annual membership fee (includes 20 provider. Ids) – Additional provider. Ids available in packages of 20
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
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 In. Common governance. . . • (optional) participation in discussions including Shib architects and other vendors about improving the user experience with Shibbolethenabled targets (eg with cross-site deeplinking transfers) • Participation in Shibboleth Academic SIG group
Deployment Resources • http: //shibboleth. internet 2. edu • http: //inqueue. internet 2. edu • Origin: – http: //shibboleth. internet 2. edu/guides/deploy-guide -origin-1. 2. 1. html – http: //shibboleth. internet 2. edu/guides/identityprovider-checklist. html • Target: – http: //shibboleth. internet 2. edu/guides/deploy-guide -target-1. 2. 1. html • shibboleth-users@internet 2. edu
Скачать презентацию Shibboleth Architecture and Shibboleth Requirements A New Approach
8eb866f43c4e7604c1a388e829d3023e.ppt