[wildfly-dev] EJB over HTTP

[David M. Lloyd]

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:
>>> https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc
>>>
>>> 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
>>> clustering).
>>>
>>> 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 
to re-authenticate.

Alternatively, it could be bound to a TLS session, though how that fits 
into the protocol model is a bit more nebulous.
-- 
- DML