SP Service Architecture

Owned by Scott Cantor
Last updated: Dec 02, 2024
3 min read

DRAFT

Overview

The SP “service” in Java to replace shibd is being architected as a set of plugins to the IdP. There are a few reasons for this:

  • It facilitates packaging and delivery of the software and reinforces the IdP as our core product. Over time, if we were to last that long, the IdP itself likely sheds much of its original function into plugins and becomes more of a shell, really almost a foundation for deployment and not a specific piece of functionality.

  • It makes direct reuse of the IdP’s code possible. The refactoring we did is in some sense unforunately not needed if we do this, but having done it, this direction makes refactoring a choice rather than an obligation in the future.

  • It makes use of Spring Web Flow as an implementation tool much simpler, which makes code reuse much simpler.

  • It allows us to expose a documented API for agents more conveniently/succinctly.

  • It obviates the need to construct an entirely new set of components to manage “message” addressing and delivery since the SWF layer can already handle that for us.

Agents

The root level abstraction is now the Agent, representing a deployment of a software stub that uses the service to protect resources (e.g., an Apache module). Agents will have an identifier for configuration and logging purposes, and credentials allowing them to authenticate to the SP service. Agent configuration is mostly about the settings that control securing them, such as allowed IP addresses, authentication methods, etc. Agents are otherwise just “containers” for the rest of the SP service configuration material, most notably containing one or more Applications that hold most of the rest of an agent’s runtime configuration.

The service is not required or expected to remember state about agents. Thus agents need to supply as input to operations any settings they need to be able to control locally based on factors outside the view of the service, typically based on content.

However, most agents likely will be stateful with respect to the service in some sense, by requiring the agent to initially connect to the service to both verify it’s available and ensure it is recognized/authorized by the service (possibly minimally so, i.e., it can connect so it’s accepted).

Agent Resolver Service

The primary “new” service defined so far for the SP is net.shibboleth.sp.AgentResolver, which is the container for most of the SP’s new configuration material. Rexolving an Agent happens very early in the processing of most requests to the service, in order to establish rules applied to the connection to secure the request.

Agent Security

Since the SP is being architected around HTTP as a transport for remote operations, agents will be assumed to support TLS and validation of the service’s certificate to authenticate responses.

Authentication by agents to the service is more complex because requiring keys is both difficult to implement and support. Shared-secret and IP address authentication are easy to implement and combine and will likely be the most common method supported.

Applications

Applications remain the core abstraction around which the SP exposes configuration of protocol-level behavior. Because the service has no way of knowing which Application should apply to a given request, this is driven by input from agents, and then in turn ensuring that the Application identified is active for a given Agent. This also happens quite early in the processing of requests that need to operate in the context of specific Applications (most do). However, unlike today, the only notion of an Application that will be visible to an agent is the ability to submit a particular Application ID to the hub for processing. What the unique Application “means” in terms of that processing is only visible within the hub, and so one would expect this to reduce the use of this feature to only when strictly needed.

In addition to holding several new types of interfaces and exposing settings specific to the SP’s use cases, an Application also implements the original IdP’s notion of a RelyingPartyConfigurationResolver. Applications will manage and expose the settings controlling what profiles to enable and their settings, optionally up to and including those to apply specifically to interactions with a particular “authority”, the neutral term for a SAML IdP, OpenID OP, etc. This allows much of the IdP code to be reused based on the existing metaphor of a RelyingPartyConfiguration and ProfileConfiguration active in servicing a request.

To achieve the separation that the “containment” relationship provides now between Applications and components like metadata and attribute handling, the various reloadable services for these functions can be injected into the Application objects with Spring. Applications would then be free to reuse (or not) common instances/configurations of these services as required, but normally could do so.