1. Shibboleth: New Functionality in Version 1 Steve Carmody July 9, 2003 Steve Carmody July 9, 2003

2. 2 Outline Federation Support New Origin Functionality New Target Functionality Miscellaneous InQueue – the first Federation

3. 3 Quick Review of Shib Entities and Flow OriginTarget

4. 4 Quick Review of Shib Entities and Flow OriginTarget

5. 5 Federation Support Federation and trust support has been substantially extended. Federation structures are now defined. The set of metadata collected and managed by each Federation is more fully defined. The configuration values assigned by a Federation are now identified. Better support for flexible and bilateral trust agreements. A key specific to an origin site can be used to validate its signature.

6. 6 Federation Support There is some support for targets to be members of multiple federations When a browser user arrives, a target will determine which federation their origin belongs to, and then use the trust fabric associated with that Federation. this support will continue to evolve. This version contains a significantly more mature security implementation, and should meet the security requirements of typical sites.

7. 7 New Origin Functionality The Attribute Authority has a powerful new attribute resolver. Simple scenarios (using a string attribute stored in ldap) can be accomplished by merely editing a configuration file. (Potentially) supports a variety of physical Attribute Repositories Java classes may still be written for more complex evaluations (eg retrieving information from multiple disparate repositories, and computing the SAML attribute using business rules). This should greatly simplify the process of configuring the AA to support additional general attributes.

8. 8 Attribute Authority Processing 1.ARP Resolution – determine which attributes to release; for each request, develop an effective ARP (X.arp.xml) 2.Attribute Discovery – obtain attribute values (resolver.xml) 3.Filter values using effective ARP

9. 9 ARP Terms ARP An Attribute Release Policy. Site ARP A policy that is applied to all principals for which a particular Attribute Authority responds. User ARP A policy that is applied only to an individual. This sort of policy is generally created and maintained by the individual to which it is applicable. ARP Rule An atomic statement of policy that pertains to a single target definition. Each rule may contain multiple specifications for which attribute values should or should not be released. Effective ARP The complete set of rules that is applicable to a principal for a particular target. These rules may be retrieved from user, group, site, and other types of ARPs. Default Rule A statement of policy that is guaranteed to be included in Effective ARPs that are derived from an ARP including such a statement.

10. 10 ARP Processing Identify all ARPs that should be applied to a particular user. Including site, user, and other ARPs Create an Effective ARP. For every rule in the previously identified ARPs, perform the matching functions specified in the rule's target definition, to determine which evaluate to TRUE. Any Default Rules encountered are automatically included in the Effective ARP without performing any matching functions. Determine which attribute/value pairs will be released. For each attribute, compile a temporary list that includes all values with a release qualifier of "permit". Subtract from this list all values with a release qualifier of "deny". This list represents the allowable release values for the attribute and is used as a mask for the values which are returned from the Attribute Resolver. If a statement specifies that all values should be permitted, then specific deny qualifiers for specific values should still be enforced. If a statement specifies that all values should be denied, then permit qualifiers for specific values will be ignored.

11. 11 Example ARP - Simplest possible ARP. - -

12. 12 Resolver -- Attribute Discovery The resolver is uses attribute definitions and data connectors. The data connectors pull data, in the form of attributes, from external data sources. The attribute definitions then process this data into a from suitable for use by Shibboleth. This procedure can be as simple as taking an unmodified string value from a data connector and tagging it with a name or can include arbitrarily complex business rules.

13. 13 Example Simple Resolver Element

14. 14 Example Ldap Resolver Element - - -- --> -

15. 15 New Target Side Functionality Significantly more flexibility in configuring targets to ensure robustness. Failover and redundant configurations are now supported. Attribute acceptance policies have been greatly enhanced, and now support filtering of attribute values by sites. The SHAR can be configured to request specific attributes from the Origin.

16. 16 Target Side Robustness The SHAR may now optionally store its session and attribute cache in a back-end database in addition to the previously available in-memory option. This would allow a site to run an apache server farm, with multiple SHARs, supporting the same set of sessions. Federation supplied files (sites.xml and trust.xml) are now refreshed in a much more robust manner.

17. 17 Simple Target Configuration Browser User Shibboleth Target (apache or IIS) Shibboleth SHAR

18. 18 Load Balanced Environment Browser User Load Balancer Shib Target (apache or IIS) Shib Target (apache or IIS) Shib Target (apache or IIS) Shib SHAR

19. 19 Load Balanced Environment Browser User Load Balancer Shib Target (apache or IIS) Shib Target (apache or IIS) Shib Target (apache or IIS) Shib SHAR Shib SHAR Shib SHAR Session DB

20. 20 Attribute Acceptance Policies An essential part of the Shibboleth trust fabric Ensure that sites only assert attributes for domains for which they are considered authoritative by the target. Typically, this means that Brown University will be trusted to assert attributes only scoped to brown.edu. Unless there are very specific circumstances requiring this restriction be removed, it is strongly encouraged that such policies be in place.

21. 21 Requesting Specific Attributes Currently, per vhost (hostname) basis Defined in shibboleth.ini requestAttributes =...

22. 22 Miscellaneous Origin sites can configure a value to describe the type of authentication mechanism used at the origin site (e.g. password, Kerberos, PKI, etc.). This value is made available on the target side as Shib-Authentication-Method. Various improvements to error handling. Origin sites are now able to supply an "error URL" and contact information to a federation. When a target encounters an error, it can include this information in the error page. Local time string values are now used in log files. Internationalization support has been extended.

23. 23 Setting Origin Authentication Method Set via directive in origin.properties Static – currently, no provision for determining dynamically (yea, we know this needs to get better) edu.internet2.middleware.shibboleth.hs.Han dleServlet.authMethod = urn:oasis:names:tc:SAML:1.0:am:password

24. 24 Target Error Handling Using templating 3 different possible templates Variable substitution Values come from runtime (error message text) and from origin site metadata New Value – url for origin site error page

25. 25 (Possible) Uses for Origin Side Error Page Describe local problem resolution process Aid the process of submitting a trouble ticket Begin to automate problem resolution process Analyze error code – for common non-user problems, submit trouble ticket

26. 26 InQueue – the first Federation http://marsalis.internet2.edu/cgi- bin/viewcvs.cgi/*checkout*/shibboleth/c/ doc/InQueue.html?rev=HEAD&content- type=text/html

27. 27 InQueue – What is Defined? What does InQueue provide? Policies Participation Data Security Security Management Attributes –eduPerson –Some “standard” entitlement values Joining InQueue Configuration for using InQueue

28. 28 Questions?