6:14 a.m.
On 04/05/16 11:42, Stuart Douglas wrote:
On Wed, May 4, 2016 at 7:47 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
I wonder how much this should be integrated with the new client that
David is currently working on, if the two were closely integrated it
would make it much easier for clients to switch between the two as
well as taking advantage of all of the new shared configuration.
This should be implemented as a transport provider for the HTTP Client,
one of the goals is to be able to use this in place of remoting
basically transparently (just a configuration change).
Server side Elytron will have a full set of HTTP mechanisms so all
the mechanisms you list will be available going forward. Would this
be used for server to server as well or just client to client? We
may end up with additional requirements that we already have for
native calls regarding clients running with multiple identities and
the propagation of identities from server to server.
It could be used for server -> server and client -> server. I think auth
should be based on existing HTTP mechanisms, but I am not sure if
something as simple as hooking up our existing HTTP mechanisms to this
will meet all the use cases.
TBH it should be possible to secure a new context with either old or new
- once new is used it will give us an established Elytron identity to
inflow into the EJB container also backed by Elytron. This will cover
the same case we have for Remoting calls where we have an authenticated
identity for the entry to the server and inflow this identity to the
domain used to secure the EJB deployment.
The server to server case is probably going to be the most problematic
though as that will have the same demands for identity propagation we
are solving with the Remoting case.
Stuart
Regards,
Darran Lofthouse.
On 04/05/16 06:50, 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/wi...
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.
Stuart