Idea for transport secure: Concept 2

[msavy]

I've spent a long while today working through a few different implementations of how to represent transport security in apiman. Although the implementations are simple, there are a wide range of security implications we need to consider.

This is my preferred idea vs concept 1, and turns out to be simpler, I think, but has a few downsides which are worth considering. We will also need to extend this in some way to try and make sure that side-channels (like policies making requests) and connectors (i.e. backend connections) obey the same rules (or at least dire warnings that isn't really secure otherwise).

Essentially we simply encapsulate this logic into the request.

Advantages:

• Encapsulates this into the request, keeps the implementation very simple
• This object is forwarded onto various areas of the system, and they can use it to determine that they should also utilise secure connections
• In the future we could consider methods of enforcing this security on the basis of the TLS status (e.g. add a connectSecure method for connectors and call that if request had transport security).

Disadvantages:

• Initially I had 'isTransportSecure' on the response, too. I deleted that because most stateful protocols don't include that information on the response (only on the request, obviously). The downside is that if we implement a stateless protocol that still has security but treats request and response separately then we'll probably need to add that back in.
• Something could accidentally unset the isTransportSecure status, which would break security for anything that relies upon it.

[msavy]

Also, we could have a mechanism where we only allow the security status to be set once for a given object. However, this might be evil for a javabean and doesn't stop someone providing a new object to the system with the security flag changed.