What’s changed in the Shibboleth 1.2 Origin Walter Hoehn (wassa@memphis.edu)

Core Multi-federation support Rationalized application architecture Metadata-based request validation Support for multiple SAML Subject formats Compatibility with 1.1 targets With the release of Shibboleth 1.2, there have been several changes to the basic way in which the origin processes requests. First, almost all of the origin’s configuration parameters can be overridden depending on which service provider is being answered. Most importantly, the origin can vary the identifiers and credentials used when servicing SAML requests. This functionality can be used to join multiple federations or to create bilateral relationships with specific providers. The application architecture has been rationalized ------------------------------------------- In versions of Shibboleth previous to 1.2, the unit of policy was the “application domain”. The application domain concept was presented in the Shibboleth architecture document, but was never fully developed in the software. An application domain was comprised of a SHAR name and a request path, knowledge of which must be shared between the origin and target. In 1.2 this system is replaced and the unit of policy is the service provider, which has a single identifier that is transmitted via federation metadata. Not only does this simplify things, but it ties policy to a logical identifier instead of to an SSL credential. What this means in a practical sense is that folks don’t have to modify their Attribute Release Policies when they change server certificates or when they add multiple redundant servers with different certificates. Request Validation ---------------- The origin now validates the sanity of several aspects of the shibboleth transaction. Specifically, it checks the federation metadata and verifies that all credentials and SAML endpoints are valid for the requesting service provider. There is support for multiple SAML Subject formats ------------------------------------ This functionality enables the Attribute Authority to answer attribute queries using identifiers other than the shibboleth handle. For instance, DNs from a certificate or campus NetIDs. This paves the way for a few new shibboleth use cases, namely authorization in grid environments, and use within campus intranets. This should also allow for increased interoperability with other SAML-based products. Legacy Compatibility ------------------ Some of the changes I’ve already described are not compatible with Shibboleth 1.1, so a legacy interoperability mode was added so that the origin can answer requests from 1.1 targets.

Logging Configuration wizard Retained full power of log4j Separate transaction log for security auditing A couple of changes were made to the origin’s logging capabilities. The origin has, since early on, used a powerful logging library named log4j, which is part of the apache jakarta project. Previous versions of the software have required that administrators tweak the logging configuration manually. While this allowed a great deal of flexibility in how the logs were output, configuring log4j is a bit of a daunting task. So, the origin configuration file now includes some simple configuration parameters that can be used to turn log4j’s dials in the ways that are most commonly needed. Those who need more customized logging can still configure log4j manually. Also, a new separate log has been added to support accounting in production deployments. This log contains only information regarding security assertions that are issued by the origin.

Attribute Resolver SQL Data Connector Uses JDBC Supports DB connection pooling Supports using prepared statements Command line testing program (resolvertest) is now able to process & enforce ARPs Data Connector fail-over support The attribute resolver has been made a bit more functional. A connector plugin has been added that allows the resolver to pull data from relational databases. The connector uses JDBC, which should allow for connecting to just about any popular database. It supports some advanced features like connection pooling and prepared statements. The resolvertest command line program has been made a bit more useful. It can now be configured to enforce attribute release policies, giving administrators more information about what data will be sent over the wire for a given user & target. Also, the resolver can be configured to query alternate data connectors when the primary data connectors fail to respond. This allows it to seamlessly fail-over to redundant directories or databases.

Performance XML Security updates Handle Service request throttle Apache JuiCE (still alpha) A few items with respect to performance. The most important is that we are now including a new version of the Apache XML Security library. This version significantly improves the speed of signing operations, which in turn boosts the overall speed of the origin. A configurable request throttle has been added to the Handle Service. This prevents the server from becoming saturated with signing requests. While it isn’t really a part of the 1.2 release, we have written a Java JCE implementation that bridges to OpenSSL for native crypto operations. This code has been donated to the Apache Software Foundation and can significantly increase the speed and throughput of the Handle Service.

Signing Credential resolver Supports signing of all SAML Assertions & Responses Up until this release, the origin’s signing credentials could only be loaded from Java keystores. This turned out to be a stumbling block for many administrators, so we have created a generic interface for loading credentials. Implementations are provided for this interface that load from java keystores as well as from all of the formats usually used with mod_ssl. Also, both the Handle Service and Attribute Authority are now flexible in which portions of the SAML messages they digitally sign. This should increase interoperability with other SAML-based products.

Attribute Release Policies Attribute value specifications can contain match functions And, lastly, the Attribute Release Policy language has been extended a bit. Match functions can be used when deciding whether or not specific attribute values should be released. This allows filtering of values based on, for instance, regular expressions.

What’s changed in the Shibboleth 1.2 Origin Walter Hoehn (wassa@memphis.edu)