1 / 32

Shibboleth Architecture and Requirements

Shibboleth Architecture and Requirements. Nate Klingenstein Internet2. http://shibboleth.internet2.edu/archive/architecture.ppt. Overview. Shibboleth as implemented Key concepts in the code Identity Provider (IDP) structure, components, and functionality

melvina
Download Presentation

Shibboleth Architecture and Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shibboleth Architecture and Requirements Nate Klingenstein Internet2 http://shibboleth.internet2.edu/archive/architecture.ppt

  2. Overview • Shibboleth as implemented • Key concepts in the code • Identity Provider (IDP) structure, components, and functionality • Service Provider (SP) structure, components, and functionality • Federation functionality • Deployment guidelines & resources 2

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

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

  5. 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 Browser/POST profile • Artifact will be supported in 1.3 • Other implementations exist 5

  6. Key Concepts • SAML • Attributes in an Inter-Realm Context • ProviderID’s & Relying Parties • Attribute Release Policies (ARP’s) • Attribute Acceptance Policies (AAP’s) 6

  7. SAML • Security Assertion Markup Language • Codified by OASIS’ SSTC with participation from MACE and other bodies • Defines XML schema for Authentication and Attribute Assertions and XML schema for Queries and Responses • Defines bindings to protocols for transport • v2.0 expands to include concepts from Liberty Alliance 7

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

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

  10. ProviderID’s and Relying Parties • ProviderID’s are the basic atoms of inter-realm policy and trust; the molecule is the enterprise • URI (urn:mace:inqueue:supervillain.edu, or https://shibboleth.supervillain.edu/ShibMain) • Each SP or IdP may support multiple providerId’s • Must be carefully defined; defines distributed use of enterprise Shibboleth infrastructure • Care must be taken when defining providerID’s for single or multiple federation use • A Relying Party is the other end in a transaction, and may represent an individual site or a collection of sites 10

  11. Attribute Release Policies (ARP’s) • Policies at the IdP governing the release of attributes to various SP providerID’s • ARP’s limit attributes released to a relying party on a per-site or per-user basis matched against a providerID • Can match individual targets, groups of targets, or regular expressions; supports both positive and negative attribute rules 11

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

  13. Attribute Acceptance Policies (AAP’s) • AAP’s filter received attributes before they are used by applications or as part of access control decisions • Also enforces privacy by limiting information available to agents using the SHAR to make requests • Partial answer to who can assert which attributes • Collectively define the set of attributes available to the resource manager to make access decisions require eduPersonScopedAffiliation staff@supervillain.edu 13

  14. Garbage Collection • AA converts attributes for inter-realm use filtered by ARP’s chosen by the relying party’s providerID • SAML transports attributes; processed by AAP’s • Together, help define total set of information in a Shibboleth transaction 14

  15. Simplified Identity Service Provider Architecture WAYF Shibboleth IdP Authentication Service Target HS AA Attribute Store (LDAP) Identity Management / Provisioning 15

  16. Simplified Identity Provider Architecture Apache WebISO Tomcat Shibboleth HS Connectors Target Shibboleth AA ARP’s Attribute Store 16

  17. HS Mechanics & Interfaces • The HS generates handles and authentication assertions per relying party • Any authentication method that can protect a webapp works; must populate REMOTE_USER with principal • Outside of Shibboleth’s concern • Required part of the surrounding infrastructure • Shibboleth as SSO? Would still require login piece 17

  18. AA Mechanics & Interfaces • Attributes can be sourced through LDAP directories, MySQL databases, or any other source with a JDBC connector • Custom attribute classes may be written in Java to generate attributes or interface with complex systems • Frequently deployed on a separate port or server; distinct service from the HS, responds directly to AR requests • All attributes filtered by ARP’s before released 18

  19. Required Campus Middleware Infrastructure • Person management -- identity & login • Attributes, attributes, attributes • Shibboleth isn’t very valuable without the right information to transport about the right principals • Level of Assurance begins at home • Your assertions are only as good as your I&A and mechanics • This really starts to matter in inter-realm scenarios • Firewall configuration may be necessary 19

  20. System Requirements • Tested with Tomcat • Apache 1.3 or 2.0 with SSL Support • Java JDK v1.4 • mod_jk2 • Server loads not severe; signing by far the heaviest operation 20

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

  22. Service Provider Request Mapping Architecture Web Server Webapps, pages, files, etc. AAP’s and access decisions Lazy Session Initiation ProviderID Bob pID Scott 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 22

  23. Applications, ProviderID’s, and Webapps • Decouples internal applications from externally visible services • Access controls can be defined at many granularities • Rules must be simple right now • More complicated rules engines (XACML, SPOCP, complex XML booleans) under consideration/development • Much of this should be hidden from users 23

  24. Lazy Sessions • Allows an application to call for Shibboleth when needed without requiring Shibboleth for all access • Construct a special URL • Handle generation & attribute transport occur as usual 24

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

  26. 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 RedHat • Apache 1.3 or 2.0 with SSL Support, or IIS 4.0+ • OpenSSL • Many prerequisite packages must be built 26

  27. Logging & Auditing • All transactions can be logged; flat-file logging and log4j/log4cpp 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 SP’s may require co-operation from IdP’s. • Decision logic may be hidden at either the IdP or SP by constructive use of attributes 27

  28. Federations in Practice • May provide a WAYF Service • Defines attribute & trust rules • May issue certificates to participants • Distributes 3 metadata files: • ca-bundle.crt • sites.xml • trust.xml 28

  29. 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 Code of Shibboleth 29

  30. Current Development • Shibboleth 1.2.1 released on Tuesday • Shibboleth 1.3 early 2005 • Reduces reliance on mod_ssl • 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 HS 30

  31. Deployment Guidelines • Extensive Apache/IIS Experience • Supports redundant production configurations • Dedicated servers likely not necessary • Surrounding infrastructure must be developed • Primary authentication & WebSSO • Attribute sources • Enable webapps • Good security practices • Shibboleth expertise can be developed while in InQueue 31

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

More Related