On 05/10/2016 10:10 AM, Darran Lofthouse wrote:
On 10/05/16 15:26, David M. Lloyd wrote:
> On 05/04/2016 12:50 AM, Stuart Douglas wrote:
>> Hi everyone,
>> I have started looking into support for service invocation over HTTP.
>> Unlike our existing HTTP upgrade support this will map EJB
>> requests/responses directly to HTTP requests and responses, which should
>> allow it to be used behind existing load balancers.
>> I have started an initial description of the protocol at:
>> The intention is to follow HTTP semantics as closely as possible.
>> Clustering will be provided in a similar manner to web clustering (i.e. it
>> will require a load balancer, and work in a similar manner to web
>> There is still plenty work that needs to be done (especially around
>> security), so if anyone has any feedback let me know.
> I noticed the responses are not coupled with the requests in the
> document, which was a bit confusing at first.
> I have a question though, why have the "EJB new session" response return
> a nonstandard header for the session ID rather than a REST-ish 201
> message that has a Location: header with the SFSB URI in it? Was it
> just message size you were worried about? Also having a content-type
> with no body is a little weird.
> The EJB request payload has to include the "weak affinity" value in
> order to be compatible with the existing protocol. But I think maybe
> the affinity concept should be nuked from orbit in general, as it turns
> out to be kinda broken; we can discuss this separately.
> On the topic of security... The original draft design doc was written
> before we really bit into HTTP authentication in Elytron. Now that we
> have, I think we can safely rely solely on HTTP authentication
> mechanisms to cover all cases for HTTP, including more complex
> mechanisms like Kerberos, OAuth2 and other SSO technologies,
> session-based authentication, and so forth; we don't need any separated
> authentication service over HTTP for any reason that I can think of.
> We may however want to consider adding a custom cookie-based
> authentication mechanism to allow for HTTP-level authentication results
> (for mechanisms like DIGEST or SCRAM or whatever) to be "tagged"; this
> way it would be possible to toggle between more than one identity
> without requiring every request to repeat the authentication, and
> without overloading JSESSIONID for this purpose (allowing multiple
> identities to be used for a given SFSB and/or transaction).
We would have to be very careful with that one though - for the identity
switching in Remoting we have the ability to use a long running
connection to associate the identity with - if we are not careful cookie
based tracking immediately adds somethign that can be used for replay
unless TLS is mandated as well.
Yeah it'd have to be checked against the session at the very least,
meaning a session may have multiple identities but an identity may not
cross sessions. If there's no session, each request would be required
Alternatively, it could be bound to a TLS session, though how that fits
into the protocol model is a bit more nebulous.