1 / 28

Shibboleth: New Functionality in Version 1

This article discusses the new functionality introduced in Version 1 of Shibboleth, including federation support, new origin functionality, new target functionality, and miscellaneous features.

tguzman
Download Presentation

Shibboleth: New Functionality in Version 1

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:New Functionality in Version 1 Steve Carmody July 9, 2003

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

  3. Quick Review of Shib Entities and Flow Origin Target

  4. Quick Review of Shib Entities and Flow Origin Target

  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. 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. 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. Attribute Authority Processing • ARP Resolution – determine which attributes to release; for each request, develop an effective ARP (X.arp.xml) • Attribute Discovery – obtain attribute values (resolver.xml) • Filter values using effective ARP

  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. 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. Example ARP • <?xml version="1.0" encoding="UTF-8" ?> • - <AttributeReleasePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:arp:1.0" xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd"> • <Description>Simplest possible ARP.</Description> • -<Rule> • - <Target> • <AnyTarget /> • </Target> • - <Attribute name="urn:mace:eduPerson:1.0:eduPersonAffiliation"> • <AnyValue release="permit" /> • </Attribute> • </Rule> • </AttributeReleasePolicy>

  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. Example Simple Resolver Element • <AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:resolver:1.0" xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0 shibboleth-resolver-1.0.xsd">  <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="shibdev.edu">     <DataConnectorDependency requires="echo"/>  </SimpleAttributeDefinition>  <CustomDataConnector id="echo" class="edu.internet2.middleware.shibboleth.aa.attrresolv.provider.SampleConnector" /> • </AttributeResolver>

  14. Example Ldap Resolver Element • - <AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mace:shibboleth:resolver:1.0" xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0 shibboleth-resolver-1.0.xsd"> • - <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonEntitlement"> • <DataConnectorDependency requires="directory" /> • </SimpleAttributeDefinition> • - <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonAffiliation"> • <DataConnectorDependency requires="directory" /> • </SimpleAttributeDefinition> <!-- To use these attributes, you should change the smartScope value to match your site's domain name. --> • - <!-- <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" smartScope="shibdev.edu"> <AttributeDependency requires="urn:mace:dir:attribute-def:eduPersonAffiliation"/> </SimpleAttributeDefinition> <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonPrincipalName" smartScope="shibdev.edu"> <DataConnectorDependency requires="directory"/> </SimpleAttributeDefinition> --> • - <JNDIDirectoryDataConnector id="directory"> • - <Search filter="cn=%PRINCIPAL%"> • <Controls searchScope="SUBTREE_SCOPE" returningObjects="false" /> • </Search> • <Property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" /> • <Property name="java.naming.provider.url" value="ldap://ldap.example.edu/dc=example,dc=edu" /> • <Property name="java.naming.security.principal" value="cn=admin,dc=example,dc=edu" /> • <Property name="java.naming.security.credentials" value="examplepw" /> • </JNDIDirectoryDataConnector> • </AttributeResolver>

  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. 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. Simple Target Configuration Browser User Shibboleth Target (apache or IIS) Shibboleth SHAR

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

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

  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. Requesting Specific Attributes • Currently, per vhost (hostname) basis • Defined in shibboleth.ini • requestAttributes = <attr1> <attr2> <attr3>...

  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. 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.HandleServlet.authMethod = <uri> • urn:oasis:names:tc:SAML:1.0:am:password

  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. (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. 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. 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. Questions?

More Related