EJB over HTTP

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that).

The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.

With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec.

Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though.

Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers.

Stuart

On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <[hidden email]> 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.

One thing I noticed is that you went a different way with async
invocations and cancellation support.

The way I originally proposed was that the request/response works as per
normal, but a 1xx header is used to send the client a cancellation token
which can be POSTed back to the server to cancel the invocation.  I
understand that this approach requires 1xx support which some clients
might not have.

In your proposal, the async EJB request always returns immediately and
uses an invocation ID which can later be retrieved.  I rejected this
approach because it requires the server to maintain state outside of the
request - something that is sure to fail.  Also the client doesn't
really have any notion as to when it can GET the response: it would have
to do it more or less immediately to avoid a late response (or when
Future.get() is called), meaning you need two round trips in the common
case, which is not so good.

I think that the best compromise solution is to treat async invocations
identically to regular invocations, and instead let the *client* give a
cancellation ID to the server, which it can later POST to the server as
I described in my original document.  If the server receives the
client's ID (maybe also matching the client's IP address) then the
request can be canceled if it is still running.

Failing this I still prefer the 1xx approach where the server gives a
cancellation ID at the beginning of the request, as this avoids problems
where the server has to maintain large object state for indefinite
amounts of time.  Either of these two options means only one server
round trip for async invocation, and no server-side caching of responses.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas


On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas <[hidden email]> wrote:
There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that).

The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.

I just thought of a way to get around this. If we require the use of an existing JSESSIONID for cancellable invocations both these problems are resolved. The sticky session makes sure the correct node is targeted, and the server can use the session id + invocation id as a unique key.

The only overhead of this is that we could need some kind of 'affinity' request message that has no other purpose than generating a session id if the client does not already have one (although this would only need to be executed once).

Stuart

 

With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec.

Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though.

Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers.

Stuart

On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <[hidden email]> 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.

One thing I noticed is that you went a different way with async
invocations and cancellation support.

The way I originally proposed was that the request/response works as per
normal, but a 1xx header is used to send the client a cancellation token
which can be POSTed back to the server to cancel the invocation.  I
understand that this approach requires 1xx support which some clients
might not have.

In your proposal, the async EJB request always returns immediately and
uses an invocation ID which can later be retrieved.  I rejected this
approach because it requires the server to maintain state outside of the
request - something that is sure to fail.  Also the client doesn't
really have any notion as to when it can GET the response: it would have
to do it more or less immediately to avoid a late response (or when
Future.get() is called), meaning you need two round trips in the common
case, which is not so good.

I think that the best compromise solution is to treat async invocations
identically to regular invocations, and instead let the *client* give a
cancellation ID to the server, which it can later POST to the server as
I described in my original document.  If the server receives the
client's ID (maybe also matching the client's IP address) then the
request can be canceled if it is still running.

Failing this I still prefer the 1xx approach where the server gives a
cancellation ID at the beginning of the request, as this avoids problems
where the server has to maintain large object state for indefinite
amounts of time.  Either of these two options means only one server
round trip for async invocation, and no server-side caching of responses.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Stuart Douglas
I have updated the spec doc to now use client side generated id that is paired with a session cookie to ensure uniqueness and node affinity.

If the client does not already have a session id it can request one with an affinity message.

Stuart

On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas <[hidden email]> wrote:


On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas <[hidden email]> wrote:
There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that).

The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.

I just thought of a way to get around this. If we require the use of an existing JSESSIONID for cancellable invocations both these problems are resolved. The sticky session makes sure the correct node is targeted, and the server can use the session id + invocation id as a unique key.

The only overhead of this is that we could need some kind of 'affinity' request message that has no other purpose than generating a session id if the client does not already have one (although this would only need to be executed once).

Stuart

 

With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec.

Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though.

Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers.

Stuart

On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <[hidden email]> 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.

One thing I noticed is that you went a different way with async
invocations and cancellation support.

The way I originally proposed was that the request/response works as per
normal, but a 1xx header is used to send the client a cancellation token
which can be POSTed back to the server to cancel the invocation.  I
understand that this approach requires 1xx support which some clients
might not have.

In your proposal, the async EJB request always returns immediately and
uses an invocation ID which can later be retrieved.  I rejected this
approach because it requires the server to maintain state outside of the
request - something that is sure to fail.  Also the client doesn't
really have any notion as to when it can GET the response: it would have
to do it more or less immediately to avoid a late response (or when
Future.get() is called), meaning you need two round trips in the common
case, which is not so good.

I think that the best compromise solution is to treat async invocations
identically to regular invocations, and instead let the *client* give a
cancellation ID to the server, which it can later POST to the server as
I described in my original document.  If the server receives the
client's ID (maybe also matching the client's IP address) then the
request can be canceled if it is still running.

Failing this I still prefer the 1xx approach where the server gives a
cancellation ID at the beginning of the request, as this avoids problems
where the server has to maintain large object state for indefinite
amounts of time.  Either of these two options means only one server
round trip for async invocation, and no server-side caching of responses.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
I think this is a good idea.  Allowing the user to acquire a session ID
could also allow for session-based authentication mechanisms to
function.  And it could be optional, in the event that a user wants to
(for example) rapid-fire stateless or one-way requests to a large number
of balanced nodes.  It could also be expanded to cover the
transaction/SFSB case we discussed, in that creation or acquisition of
these things would reuse or create a new ID based on whether one was
provided.

On 05/04/2016 09:59 PM, Stuart Douglas wrote:

> I have updated the spec doc to now use client side generated id that is
> paired with a session cookie to ensure uniqueness and node affinity.
>
> If the client does not already have a session id it can request one with
> an affinity message.
>
> Stuart
>
> On Thu, May 5, 2016 at 10:03 AM, Stuart Douglas
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>
>     On Thu, May 5, 2016 at 8:55 AM, Stuart Douglas
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         There are two problems with client generated ID's, and the main
>         one is that you can't guarantee that the cancellation message
>         will go to the same server as the original invocation. With my
>         current design the initial request will send back a JSESSIONID
>         that allows the cancel request to be targeted at the correct
>         server (of course if we already have affinity then this is not a
>         problem, but we can't guarantee that).
>
>         The other problem is that there is no easy way to guarantee
>         there will not be conflicts, although I guess you could send
>         back a 409 and force the client to retry with a new cancellation
>         id if a conflict happens. You can't really tie this to IP
>         because it may be behind a load balancer, and something like a
>         GUID may be expensive to generate for every invocation.
>
>
>     I just thought of a way to get around this. If we require the use of
>     an existing JSESSIONID for cancellable invocations both these
>     problems are resolved. The sticky session makes sure the correct
>     node is targeted, and the server can use the session id + invocation
>     id as a unique key.
>
>     The only overhead of this is that we could need some kind of
>     'affinity' request message that has no other purpose than generating
>     a session id if the client does not already have one (although this
>     would only need to be executed once).
>
>     Stuart
>
>
>         With the 1xx approach I am worried that not all load
>         balancers/proxies will properly support it. As this is not
>         really used outside of 'Expect: 100-continue' I would be
>         surprised if this works correctly without problems, even though
>         it is valid according to the spec.
>
>         Another potentially yucky way to do this would be to have the
>         client use chunked encoding and keep the request open, allowing
>         it to send some kind of cancellation token at any time. This
>         feels really hacky though.
>
>         Basically all the options suck, the one I put in the doc was
>         that one that I thought sucked the least when dealing with load
>         balancers.
>
>         Stuart
>
>         On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd
>         <[hidden email] <mailto:[hidden email]>> 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.
>
>             One thing I noticed is that you went a different way with async
>             invocations and cancellation support.
>
>             The way I originally proposed was that the request/response
>             works as per
>             normal, but a 1xx header is used to send the client a
>             cancellation token
>             which can be POSTed back to the server to cancel the
>             invocation.  I
>             understand that this approach requires 1xx support which
>             some clients
>             might not have.
>
>             In your proposal, the async EJB request always returns
>             immediately and
>             uses an invocation ID which can later be retrieved.  I
>             rejected this
>             approach because it requires the server to maintain state
>             outside of the
>             request - something that is sure to fail.  Also the client
>             doesn't
>             really have any notion as to when it can GET the response:
>             it would have
>             to do it more or less immediately to avoid a late response
>             (or when
>             Future.get() is called), meaning you need two round trips in
>             the common
>             case, which is not so good.
>
>             I think that the best compromise solution is to treat async
>             invocations
>             identically to regular invocations, and instead let the
>             *client* give a
>             cancellation ID to the server, which it can later POST to
>             the server as
>             I described in my original document.  If the server receives the
>             client's ID (maybe also matching the client's IP address)
>             then the
>             request can be canceled if it is still running.
>
>             Failing this I still prefer the 1xx approach where the
>             server gives a
>             cancellation ID at the beginning of the request, as this
>             avoids problems
>             where the server has to maintain large object state for
>             indefinite
>             amounts of time.  Either of these two options means only one
>             server
>             round trip for async invocation, and no server-side caching
>             of responses.
>
>             --
>             - DML
>             _______________________________________________
>             wildfly-dev mailing list
>             [hidden email] <mailto:[hidden email]>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
In reply to this post by Stuart Douglas
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).

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

Darran Lofthouse


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.

>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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.

>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EJB over HTTP

David Lloyd-2
In reply to this post by David Lloyd-2
On 05/10/2016 09:26 AM, 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 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.

Looking at the JNDI part, it seems like you are using the content type
to establish the operation that is to be performed, even when there is
no actual content.  In the draft, the Accept: type was used to establish
what kind of result was requested (for JNDI it could be the actual
binding, or it could be a list of bindings in a couple of forms for
subcontexts).  The request method determined the operation, and query
parameters applied behavioral variations.

You did (rightly, IMO) change the lookup operations from GET to POST,
but I think that response type and query parameters would still suffice
to get the result, and I'm not sure that using the request content type
to identify the operation is really appropriate in any event.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12