...
The first “new” such service is one that exposes an the net.shibboleth.sp.remoting.EndpointManager interface to the Spring Integration layer to identify the possible recipients of messages. Reloading it would will refresh the possible message destinations.
Many of the other services should be identical to those in the IdP, such as the metadata and attribute resolver/registry/filter services. Unlike the IdP, it is a possible goal initially to support multiple instances of these services in order to adapt the SP’s current behavior. While most (and preferably nearly all) SPs define default configurations for metadata and attribute handling that are reused even when application overrides are used, there are deployers that insist on isolating these configurations. Right now, we’re leaning toward not explicitly pushing towards that kind of isolation, and instead encouraging a single instance of each service, with behavior tailored through activation conditions that would trigger around which application was active. This should be simpler to configure and more efficient most of the time.
Applications
To accomodate this design, the proposed (yet to be now being prototyped) architecture is to layer the concept of an “Application” into the remoting components as the destination of a message. The current SP typically, though not universally, identifies the application involved with an operation by embedding an “application” member into the input data. This revised proposal is to promote that value to the top level as the name of the input object, targeting the Application object that should receive the request. The Application(s) would be auto-deployed into the EndpointManager alongside any other objects implementing the net.shibboleth.sp.remoting.Endpoint interface (e.g. status/monitoring). Applications could then be hot-deployed through reload of the EndpointManager service.
Internally, the Application objects would dispatch messages to another set of lower-level auto-wired components that perform work for the SP agents. Agents would map requests to Applications in some fashion similarly to today, create a message targeted for that Application, and then embed the additional message inputs in a manner yet to be finalized (currently an embedded “op” member).“this” member that is intended to reflect targeting a message to an object). The abstraction layer of the Application then invokes components that implement the net.shibboleth.sp.remoting.ApplicationEndpoint interface by auto-injecting the Application as the first parameter of the method call, providing access to the “current” Application involved in the request. This automates the “convention” used in the current code with more consistency.
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 would can be injected into the Application objects with Spring. Applicatons would then be free to reuse (or not) common instances/configurations of these services as required, but normally would do so.
As it stands now, it’s TBD whether a given instance of this service should host only Applications deployed together in a virtual web environment (i.e., not necessarily one physical server, but one logical server). I lean toward “no” and opening this up to simply viewing an Application as the top level concept without regard for where it lives. It’s not clear yet whether some of the logical URL details that are needed for things like endpoint computation and destination enforcement will actually require that the Java service be aware of these mappings. It’s plausible that any URL details might be fed in from the agent and simply trusted by the service as it goes about its work. Of course, sharing many different Applications inside one service instance obviously has implications for performance/scale, and for security.
...