[wildfly-dev] EJB over HTTP

[Darran Lofthouse]

On 10/05/16 16:13, David M. Lloyd wrote:
> 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.

Yeah it would really need to be the TLS session it is bound to, even 
HTTP sessions are weak if someone manages to obtain the session ID.

>