...
It facilitates packaging and delivery of the software and reinforces the IdP as our core product.
It makes direct reuse of the IdP’s code directly 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.
It allows us to expose a REST documented API for agents more conveniently.
It shifts the focus to agents that will have HTTP client capability, which is likely the majority of them anyway. Remoting HTTP calls via the DDF protocol becomes the special case, even if it turns out to be required for the most common agent today, Apache.
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.
...
Applications probably will remain the core abstractioon abstraction around which the SP exposes configuration of protocol behavior. 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. Applicatons Applications would then be free to reuse (or not) common instances/configurations of these services as required, but normally would do so.
...
Assuming we lump “many” SP’s Applications into one service instance, identifying them starts to overlap with the problem of porting over the configuration and how entityIDs or client_ids are assigned to systems. Even if we wanted to make that assignment purely a service-side issue, it wouldn’t allow the service to cleanly properly identify the agents in a shared scenario, and there’s no identifier for the Applications that would be unique in the current model (they’re all local to each SP deployment today).
An obvious thing to do would be to combine the current entityID and applicationId together to build a unique value, but the SP’s multi-hosting features might make that a challenge if there are e.g. entityIDs being calculated based on vhosts. It’s plausible that at least for compatibility with the old configuration we would just use the “default” entityID to name the agent, and come up with something more abstracted (agent ID?) if a new, simpler configuration were used.
...
The lack of security in the current remoting layer was always a very deliberate choice because security is hard, true networking greatly reduces performance, and it adds dependencies. The redesign’s focus is on eliminating all dependencies, so adding security formally isn’t likely in the cards. However, we envision adding TLS support to the TCP gateway, and the use of stunnel is a plausible solution to secure the traffic if desired, which would be critical if different agents share an instance of the service. Direct REST access would be TLS-protected of course. However, with the shift to using HTTP to handle the remoting, TLS would inherently be supported by any HTTP clients we used, so at least some degree of security would be added from that.
Additionally, it’s possible that some kind of simple key or secret authorization strategy could be employed to limit the agents that can send requests targeted at a particular Application. It is unlikely for the usual reasons that we would seek to secure the traffic end to end with TLS because of the difficulties of supporting Client TLS Authentication in modern systems due to intermediaries.
Agent / Service Interaction
...
Many of the other “not a handler” operations will probably be centered on session handling, asking to recover a session. Plausibly, a request to the agent that does not self-identify a session already in the agent’s local cache (whatever that entails) would lead to a request to either return a session, or (if a flag signaled signalled that one was required) ask the service to respond with a new login request message (i.e., return the HTTP response body or redirect to make one happen). That implies that any configuration settings influencing the generation of that request would have to be known by the service or provided by the agent with the request. That kind of hurts, since it turns a simple “get session” call into a much larger message “just in case” but it seems unavoidable because the SP definitely was steered toward using content settings to influence login requests, but ideally the overhead won’t be too bad and could, I suppose, even be optional. Some kind of “I’m using advanced features like this” flag could change the agent’s behavior in some way.
...