HubOverview

The V4+ Shibboleth SP software consists of a set of Agents and a (possibly shared/remote) Hub that consists of Java-based plugins for the Shiibboleth Identity Provider software.

Agents are “native” components that operate within web servers and application frameworks to mediate the general interactions of Web Single Sign-On and attribute-based authorization. Agents are neutral to any specific technical protocol like SAML or OpenID Connect and handle the sorts of content/resource-based rules that need to be able to evolve with an application or set of content. They require much less expertise/knowledge of SSO and are designed to be much easier for application and support staff to deploy and configure than the older versions.

The Hub, in contrast, understands and controls setup and behavior of supported protocols like SAML or OpenID Connect, and isolates the need for that expertise in a way that may lead to better use of limited staffing in some organizations. In turn, the Hub does not concern itself with the behavior of Agents and any settings that are likely to require a degree of content-driven agility. The Hub (mostly) doesn’t know about resources and paths and such, and is insulated from such changes.

This documentation space is specifically about the Hub plugins and how to configure and use them. The latest Agent documentation can be found at Service Provider Agents 4. Note that the Hub is versioned independently of the Agents.

It is possble and indeed expected to be common for different teams of staff to operate these separate pieces of software, but it is of course possible for them to be run by the same people and on the same host, much as the “shibd” daemon service used to be part of the SP software. The new design just allows them to be operated separately and with different scalability and reuse expectations.

In particular, unlike “shibd” in earlier versions, a single Hub can explicitly be configured to serve a large number of Agents as a shared service, while still allowing each Agent to act in a very autonomous fashion. That is, Agents may be treated as part of a single logcal SAML or OpenID relying party or may act quite distinctly as separate relying parties, as needs dictate. The Hub is also by design largely stateless in operation and can be clustered easily for HA and performance. A Hub may in some cases mediate access to stateful/persistent storage options, such as a database, on behalf of its Agents.

Finally, Agents communicate with their designated Hub by means of an HTTP-based protocol with simple shared secret authentication used for the time being (think OpenID client IDs and secrets). TLS is expected to be used to protect the tunnel if a network is used,and Agents can be configured with trust anchors with the usual flexibility depending on how the Hub gets deployed and equipped with either self-signed or CA-issued certificates.

The Hub is essentially a set of web services bolted into the IdP software that Agents invoke, while leveraging the same web container and many of the services already built-in to the IdP software. It is not a requirement, or indeed expected, that the Hub deployment would actually operate as a Shiibboleth IdP itself, as there are substantially different security risks to the operation of an IdP. However, it is not precluded. More on this below.

While it is not an absolute requirement for Hub deployers to be familiar with the Identity Provider software, those lacking any exposure to it will find themselves somewhat challenged by this software, as it makes extensive use of existing IdP features and configuration in areas such as SAML or OIDC metadata, attribute resolution, filtering, and decoding services, etc. As with the IdP, Java and Spring familiarity are also assumed. Much of the Hub documentation will refer to the IdP documentation in many places, though over time it is likely the two documentation sets may evolve somewhat independently.

Identity Provider Usage Considerations

To state this again: while the IdP software is the “container” for the Hub plugins, this is largely an issue of expediency. It simplified the development enormously, provides an existing delivery mechanism for the plugins, and provides the plugins with direct access to code and services that are of relevance to both use cases. In a perfect world, much of the IdP’s functionality could have been developed as plugins in their own right, rather than part of the “core”, but that is an accident of history.

That said, the Hub is capable of operating inside an actual IdP. This works, and we have tested it with SAML, and by the time of the eventual release it should work for OpenID as well. This is particularly convenient in fact for testing the Hub, as one can connect Agents to the same IdP to supply that “half” of the SSO story, which in the past always required a stand-alone IdP to do any useful testing.

However, there are a couple of reasons why this is not such a great idea in production and some other aspects to think about if you are considering this.

Security

The most obvious reason not to combine things is security.

The risks associated with operating IdPs and SPs, and in particular the risks associated with compromise, are vastly different. It is (or should be) well understood that compromising an IdP’s signing key is catastrophic in SAML. This is by design for reasons that are outside the scope of this discussion, but it’s a given that this is a very bad thing that is incredibly expensive in time to recover from. The risks associated with an SP compromise, even when a lot of SPs are involved tend to be much more limited in scope. The fewer Agents connected to a Hub, of course, the lower the risk. It’s also somewhat less expensive to recover from, though that depends on how many IdPs are federated with the SP(s).

So following basic security practice, one does not in general want to combine systems with very different security requirements into a single, combined environment and so we would, on that basis alone, not suggest doing this if the IdP is operating at a significant scale, supporting a lot of “other” SPs. It is perhaps more defensible if the only SPs supported are those operating with Agents connected to the IdP as a Hub.

Staff Roles

Another obvious issue is simply staffing roles. Operating SPs is, at root, an application deployment activity. Operating IdPs is an IAM activity. Most medium or large organizations are unlikely to have a single team providing both of these functions. Just because the IdP software is now acting as a home for both activities, it doesn’t follow that a separate deployment of the Hub is something to expect an existing IdP team to handle

It certainly might make sense for a sharing of knowledge between them of course, but per the Security point above, it’s unlikely that it would physically be the same deployment regardless. This might seem revolutionary, but asking small teams of people to continually take on new, essentially unrelated, responsibilities is a good way to end up with smaller teams of people. Just food for thought.

Confusion/Overlap

A final point is that it can be a bit of a brain-twisting exercise to deploy the Hub inside an actual IdP. It’s not that hard exactly, but it can get a little “odd” at times. The Attribute Filtering layer in particular can get rather confusing to manage when it’s operating in two different directions, particularly at “scale”. This comes up a bit when proxying authentication to another IdP but that tends to be limited in scope compared to developing a release framework for hundreds of Agents.

Just operationally speaking, it takes some creativity to develop strategies for managing the deployment when it’s doing such very different things at once. There’s nothing insurmountable about doing it, but it’s not that obvious that it offers compelling benefits, when one considers the other drawbacks.