HubPlanning

Introduction

Beyond initial testing or proofs of concept, the deployment of the new SP typically requires some planning unless the requirements are very minimal. The separation of the Agents and Hub and the ability to support many Agents with a single Hub allow for a much wider variety of scenarios in terms of separation of duty and administrative control than the older design.

While not formally a SSO proxy/gateway (we already have the IdP for that use case), there are substantial similarities in terms of:

• the “scope” of a Hub and what Agents it serves

• the range of protected applications and services a Hub will act for

• the processes by which Agent deployers will be supported

• the data “contract” between the Hub and its Agents

So considering the Hub a SSO proxy, while not technically accurate, is a good way to approach the planning. If you were to proxy SSO and potentially federation relationships in your environment, how would you do that and on how large a scale would it function?

Why not a proxy?

To understand why the Hub is not literally a proxy, it perhaps suffices to say that if it were, there’d be no point to building it because there are already many proxy soliutions available. What makes the Agent/Hub design different is that it more naturally addresses the problem of how to “SSO-enable” a large set of applications such that:

• The Agent footprint and security considerations are minimized over and above even simple SSO protocols. The Agent and Hub work together to make the endpoint “appear” to be SAML or OpenID capable but the footprint is split between the two in a way that tilts complexity heavily away from the Agent.

• Formal support for clusterable application session management can be offered, which is not easy to provide with a SSO proxy.

• Applications can be exposed natively and directly to SAML or OpenID federations while maintaining the centralized management that proxying offers. Yes, proxies do sometimes support this, but many also do not.

• A reverse proxy is not required. This is a different sort of proxy somewhat common in enterprises but not as common in less centralized environments.

Considerations

Building on the introduction, these are the most critical things to consider and plan for.

1. Is the Hub meant to serve a single application service (essentially a legacy deployment of the SP with a self-contained story) or if not, exactly what range of Agents need to be supported?
   This may range from a single team operating a few applications and a shared Hub, to a departmental Hub handling a dozen or dozens of Agents across a business or academic unint, to an enterprise-wide deployment serving hundreds of Agents across many different units. Obviously the amount of “formalism” in terms of process and on/off-boarding support must grow as one scales up.
   In particular the need for a reasonably “enterprise-oriented” approach to managing Agent IDs and secrets is a given to operate a Hub at a large scale, just as it would be to operate a database shared by hundreds of clients. Manual account management breaks down at that scale, and the Hub supports standard enterprise service authentication mechanisms for that reason (and quite simple to support given that it’s operating inside our IdP).

2. Will the Hub need to provide access to persistent or semi-persistent data storage to its Agents (primarily for sessions)? We hope to make this avoidable as we always have, but the use of Java means we can make the use of various storage mechanisms for sessions more practical than it was in the past.

3. What SSO protocols will need to be supported? Additional plugins and different follow on work will be required to support SAML vs. OpenID (or whatever else we may eventually support).

4. How much variability in SSO behavior needs to be supported within a set of Agents acting as a logical unit?
   As an example, will different sources of SAML Metadata have to be scoped to different “parts” of a single application? Will there be different data requirements, particularly with regard to “local” data the Hub might be “enriching” an Agent’s sessions with?
   This is analagous (and termed identically) to the older Shibboleth SP’s concept of “Applications” within a single web server, and as with the older SP, it remains the case that it’s always best to avoid having more than one and to limit the amount of variable behavior one needs to support because it increases complexity drastically to do so. And again as with the old design, it’s best (to the point of practically being a necessity) to scope a distinct Application when it does exist to an entire virtual host.
   A newer consideration is that the more fine-grained the behavior, the more the Hub will be “coupled” in some sense to its Agents and likely have to deal with more frequent requests for changes in behavior, whereas the goal is certainly to allow the Agent and Hub to be operated fairly autonomously.

Single Agent Use

Of course, most of the aforementioned concerns go out the window if the intent is to simply replace an older SP with the new Agent and a Hub running together (or closely so) and operated by one person or team. The default configuration of both Agent and Hub support this use case “out of the box” and most adjustments will be property-driven except for any non-trivial requirements around attribute manipulation or enrichment via other data sources.