Project Layout

The layout of the IdP library stack has changed significantly in this release so warrants documentation for anybody trying to “find anything” or understand what dependencies would be needed for plugins. It is more modular now, at the cost of increasing the number of library artifacts, and has also been refactored to expose more code to software other than the IdP.

The information is presented in a bottom-up fashion, lowest layer to highest (the IdP itself).

1 Note Regarding Test Classes
2 Third Party Dependencies
3 Shared Modules
4 OpenSAML
5 Shibboleth Foundation Libraries
- 5.1 Metadata
- 5.2 Attributes
- 5.3 Profiles
6 Identity Provider

Note Regarding Test Classes

A large effort was undertaken in this release to reorganize any classes used for building unit tests to limit or eliminate the need to rely on the “test-jar” scope anywhere in the stack. To that end, a number of classes used across tests have been relocated into separate -testing modules in each multi-module project. These modules contain code intended to be incorporated into tests at “test” scope, never “compile”, and the various BOM artifacts reflect this.

Third Party Dependencies

We are not going to enumerate all of our third party dependencies here, but obviously there are many. These are libraries outside of our direct control and supplied by other projects. The most significant are:

Spring Framework 6
Spring Web Flow 3
SLF4J and Logback for logging
Santuario Java XML Security 3
Ldaptive 2
Apache HttpClient 5
Guava (a low level Google-authored library supporing various useful constructs such as Multimaps and HTML encoding)
Jackson (a popular JSON parser)
Codehale Metrics

Shared Modules

What used to be java-support and spring-extensions in the older releases has been refactored extensively to span a number of different modules in a new multi-module project called java-shib-shared. This spans a large range of utility needs, from primitives, condition/function support, Spring utilities and extensions, networking classes, security classes, and so forth. There are often both basic and Spring-aware modules in each functional area.

Many of the packages in these modules have been renamed significantly, as one of the goals for this refactor was to avoid generic package names like “support”, or “ext”. In some cases, stubs have been left behind to allow use of the older classes in deployments temporarily, but this is not universally true.

All modules can be imported via BOM using:

<dependency>
    <groupId>net.shibboleth</groupId>
    <artifactId>shib-shared-bom</artifactId>
    <version>${java-shib-shared.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

The initial version of all modules is 9.0.0 at the time of the IdP V5 release, a carryover from the previous versions of the older libraries.

The current list of modules is:

        <module>shib-cli</module>
        <module>shib-networking</module>
        <module>shib-networking-spring</module>
        <module>shib-security</module>
        <module>shib-security-spring</module>
        <module>shib-service</module>
        <module>shib-spring</module>
        <module>shib-support</module>
        <module>shib-testing</module>
        <module>shib-velocity</module>
        <module>shib-velocity-spring</module>

OpenSAML

There have been relatively few changes to the OpenSAML library as compared to the rest of the libraries, primarily adjusting some module names, splitting API and non-API modules where not already done, and adding a Spring module that contains functionality supporting the use of some OpenSAML classes in Spring-aware applications. (There remains no general dependency on Spring in the library except for that module.)

The most noticeable change is that opensaml-core no longer exists, in favor of opensaml-core-api and opensaml-core-impl separately.

As before, all modules can be imported via BOM using:

<dependency>
    <groupId>org.opensaml</groupId>
    <artifactId>opensaml-bom</artifactId>
    <version>${opensaml.version}</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

The initial version was of course 5.0.0 at the release of IdP V5.0.0 and we plan to release it in lockstep with the IdP going forward, which is a change from previously.

The current list of modules is:

Shibboleth Foundation Libraries

A set of 3 new multi-module projects has been created by forking the original IdP sources and excising much of the IdP code to leave “topical” material relevant to each of three main foundational layers:

Metadata
Attributes, Attribute Resolution, and Attribute Filtering
Profile Configuration and General Functionality

In most, but not all cases, the classes were relocated but packages were not renamed, despite the presence of “idp” in the package names. There are exceptions to this in cases in which the naming would be confusing and harmful to the eventual use of this code in the SP should that occur.

All of these modules depend in some fashion on OpenSAML as well as the shared modules. In generall they are really part of the IdP for now, but they do provide a lot of functionality that would allow for significant reuse of major features in the IdP in a Spring context outside of the IdP itself.

The initial version of all these modules was 5.0.0, and are being versioned and released in lockstep with the IdP.

Metadata

There is some cross-talk between the metadata and attribute layers so this division was less clean than one would prefer but for the most part, the metadata layer was deemed the “lowest” one, and it does not depend on either of the others. Code designed to decode SAML Attributes in metadata is therefore not in this layer.

This layer includes Shibboleth-defined metadata extensions and the custom Spring syntax parsers for configuring metadata resolvers and filters. Virtually anything metadata-related not already in OpenSAML is in this layer now.

All modules can be imported via BOM using:

The current list of modules is:

Attributes

This is the largest of the new projects and contains as much of the attribute-related classes and services we could manage to pull out of the IdP. Because of the amount of disruption it would case, there has been little or no package renaming, so the attribute classes remain wedded to the notion of “IdPAttributes” and so on. In the event this is used by the SP in the future, the justification will be that “mostly this data comes from the IdP” and we’re sticking to that story.

Note that this layer includes the entire implementation and Spring syntax parsing layers of both the Attribute Resolver and Filter services in the IdP. There is more or less nothing else needed to actually embed these components in a Spring application unrelated to the IdP or in some a large sense even to SAML or other protocols, as it’s all pretty generic functionality.

All modules can be imported via BOM using:

The current list of modules is:

Profiles

The profile layer is primarily a transplant of the RelyingParty and ProfileConfiguration concepts out of the IdP for potential reuse by the SP, and unfortunately this necessitated some renaming to get the “idp” naming out. From a deployer standpoint, there are a lot of insulators to allow for warnings and deferred updating of renamed classes, but extensions will be impacted in many cases by the changes. Usually yanking “idp” out is enough.

One particular change is that the ProfileConfiguration classes have been wholly refactored into interfaces and the concrete classes are largely non-API now. All the code using these has been recast now in terms of the interfaces.

All modules can be imported via BOM using:

The current list of modules is:

Identity Provider

Finally, the IdP itself remains as before, minus a decent number of modules that are now gone because their content has been relocated lower in the stack. Thus, POM dependencies on any of these modules will break, in particularly the old idp-attribute-* modules.

All modules can be imported via BOM using:

The current list of modules is: