[wildfly-dev] EJB over HTTP

[David M. Lloyd]

On 05/10/2016 11:23 AM, Darran Lofthouse wrote:
>
> 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.

Of course; however this is an existing problem.  Form authentication for 
example also relies on the HTTP session to hold the authentication 
information.  Protection against session hijacking is going to have to 
be the responsibility of the user (and not just for authentication but 
also for privacy of transactions, SFSB session instances, etc.). They 
could use protocol level transport security (TLS) or they may rely on 
(for example) physical security, or even IP address verification if the 
situation allows for it.


-- 
- DML