Re: authorization for ejbd/http client

[David Blevins]

> On Dec 9, 2016, at 2:50 PM, Romain Manni-Bucau  wrote:
> 
> Users rely on authorizatuon query param - stripped before actual query for
> security reasons - to put the token.

Can you point at the documentation for it or paste an example that includes the 
InitialContext creation with the right combination of InitialContext and query 
parameters?

> Side note: also used for other token based solutions like oauth2 or
> equivalent.

Supported, but discouraged, by the oauth2 spec, yes.  You note, they’re not 
sent on the wire as query parameters, so that is fine and inline.

I’d want to make sure we’re not logging the passwords.

-David

> 
> 
> Le 9 déc. 2016 23:32, "David Blevins"  a écrit :
> 
>> http://www.tomitribe.com
>> 
>>> On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> Le 6 déc. 2016 23:15, "David Blevins"  a écrit
>> :
>>> 
>>> 
 On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau 
>>> wrote:
 
> You may have a desktop app or some other scenario where on your trusted
> network, users can log in and you don’t want identity statically
>>> configured
> on the server side.
> 
> 
 This is a feature we don't have today at all so quite out of scope of
>> the
 current mail (this is a new feature client wide, not related to udp
 probably)
>>> 
>>> We do have this exactly and I think is possibly a reason for the
>> confusion.
>>> 
>>> Here’s a thread from 2008, "Desktop app communicating with EJB"
>>> 
>>> - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
>>> communicating-with-EJB-td980332.html >> n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
>>> 
>>> Clients can login via the RemoteInitialContext parameters and have their
>>> identity propagate with their remote calls.
>>> 
>>> The only change is that the user/pass could get applied at the http layer
>>> as well.
>>> 
>>> 
>>> This is unrelated to my comment. Point was we can use it with multicast -
>>> which is the only issue - cause outside of the multicasted info - the
>> url.
>>> 
>>> 
>>> Nothing we couldnt enhance but as explained this is also not needed and
>>> your example doesnt show this is wrong.
>> 
>> I’m quite lost.  Can you post a code snippet on how someone uses basic
>> auth from the client side with httpd+ejbd?
>> 
>> -David
>> 
>> 

Re: authorization for ejbd/http client

[Romain Manni-Bucau]

Users rely on authorizatuon query param - stripped before actual query for
security reasons - to put the token.

Side note: also used for other token based solutions like oauth2 or
equivalent.


Le 9 déc. 2016 23:32, "David Blevins"  a écrit :

> http://www.tomitribe.com
>
> > On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau 
> wrote:
> >
> > Le 6 déc. 2016 23:15, "David Blevins"  a écrit
> :
> >
> >
> >> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau 
> > wrote:
> >>
> >>> You may have a desktop app or some other scenario where on your trusted
> >>> network, users can log in and you don’t want identity statically
> > configured
> >>> on the server side.
> >>>
> >>>
> >> This is a feature we don't have today at all so quite out of scope of
> the
> >> current mail (this is a new feature client wide, not related to udp
> >> probably)
> >
> > We do have this exactly and I think is possibly a reason for the
> confusion.
> >
> > Here’s a thread from 2008, "Desktop app communicating with EJB"
> >
> > - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
> > communicating-with-EJB-td980332.html  > n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
> >
> > Clients can login via the RemoteInitialContext parameters and have their
> > identity propagate with their remote calls.
> >
> > The only change is that the user/pass could get applied at the http layer
> > as well.
> >
> >
> > This is unrelated to my comment. Point was we can use it with multicast -
> > which is the only issue - cause outside of the multicasted info - the
> url.
> >
> >
> > Nothing we couldnt enhance but as explained this is also not needed and
> > your example doesnt show this is wrong.
>
> I’m quite lost.  Can you post a code snippet on how someone uses basic
> auth from the client side with httpd+ejbd?
>
> -David
>
>

Re: authorization for ejbd/http client

[David Blevins]

http://www.tomitribe.com

> On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau  wrote:
> 
> Le 6 déc. 2016 23:15, "David Blevins"  a écrit :
> 
> 
>> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau 
> wrote:
>> 
>>> You may have a desktop app or some other scenario where on your trusted
>>> network, users can log in and you don’t want identity statically
> configured
>>> on the server side.
>>> 
>>> 
>> This is a feature we don't have today at all so quite out of scope of the
>> current mail (this is a new feature client wide, not related to udp
>> probably)
> 
> We do have this exactly and I think is possibly a reason for the confusion.
> 
> Here’s a thread from 2008, "Desktop app communicating with EJB"
> 
> - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
> communicating-with-EJB-td980332.html  n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
> 
> Clients can login via the RemoteInitialContext parameters and have their
> identity propagate with their remote calls.
> 
> The only change is that the user/pass could get applied at the http layer
> as well.
> 
> 
> This is unrelated to my comment. Point was we can use it with multicast -
> which is the only issue - cause outside of the multicasted info - the url.
> 
> 
> Nothing we couldnt enhance but as explained this is also not needed and
> your example doesnt show this is wrong.

I’m quite lost.  Can you post a code snippet on how someone uses basic auth 
from the client side with httpd+ejbd?

-David

Re: authorization for ejbd/http client

[Romain Manni-Bucau]

Le 6 déc. 2016 23:15, "David Blevins"  a écrit :


> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau 
wrote:
>
>> You may have a desktop app or some other scenario where on your trusted
>> network, users can log in and you don’t want identity statically
configured
>> on the server side.
>>
>>
> This is a feature we don't have today at all so quite out of scope of the
> current mail (this is a new feature client wide, not related to udp
> probably)

We do have this exactly and I think is possibly a reason for the confusion.

Here’s a thread from 2008, "Desktop app communicating with EJB"

 - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
communicating-with-EJB-td980332.html 

Clients can login via the RemoteInitialContext parameters and have their
identity propagate with their remote calls.

The only change is that the user/pass could get applied at the http layer
as well.


This is unrelated to my comment. Point was we can use it with multicast -
which is the only issue - cause outside of the multicasted info - the url.


Nothing we couldnt enhance but as explained this is also not needed and
your example doesnt show this is wrong.



-David

Re: authorization for ejbd/http client

[David Blevins]

> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau  wrote:
> 
>> You may have a desktop app or some other scenario where on your trusted
>> network, users can log in and you don’t want identity statically configured
>> on the server side.
>> 
>> 
> This is a feature we don't have today at all so quite out of scope of the
> current mail (this is a new feature client wide, not related to udp
> probably)

We do have this exactly and I think is possibly a reason for the confusion.

Here’s a thread from 2008, "Desktop app communicating with EJB"

 - 
http://tomee-openejb.979440.n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html
 


Clients can login via the RemoteInitialContext parameters and have their 
identity propagate with their remote calls.

The only change is that the user/pass could get applied at the http layer as 
well.


-David

Re: authorization for ejbd/http client

[Romain Manni-Bucau]

2016-12-05 23:48 GMT+01:00 David Blevins :

> > On Dec 5, 2016, at 10:29 AM, Romain Manni-Bucau 
> wrote:
> >
> > 2016-12-05 19:24 GMT+01:00 David Blevins :
> >
> >>
> >>> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau 
> >> wrote:
> >>>
> >>> Concretely the proposal can be:
> >>>
> >>> p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> >> RemoteInitialContextFactory.
> >>> class.getName());
> >>> p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
> >>> p.setProperty(Context.PRINCIPAL, "tomee");
> >>> p.setProperty(Context.CREDENTIAL, "password”);
> >>
> >> This would work.
> >>
> >>
> >>> That said it doesnt help for multicast since you will loose the
> >> credentials
> >>> where current solution works.
> >>
> >> From my perspective this is desired.
> >>
> >>
> > Can you detail that? What is the case where you would not secure by
> network
> > the cluster and not have a security hole (= what's the case where this
> > additional security layer is justified)?
>
> Let’s say you did have a closed and trusted network.  There still might be
> the use case where you have different clients on that network and want them
> to have their own identities.
>
>
We support it so not sure what your comment was about then


> You may have a desktop app or some other scenario where on your trusted
> network, users can log in and you don’t want identity statically configured
> on the server side.
>
>
This is a feature we don't have today at all so quite out of scope of the
current mail (this is a new feature client wide, not related to udp
probably)


> >> For those that may not understand the reference.  Effectively the
> >> multicast/multipoint code collects all the server URIs, aggregates them
> >> together and broadcasts them to all the clients.  Putting the login
> >> credentials in the URL the server broadcasts effectively broadcasts
> client
> >> information to all the clients, which would mean:
> >>
> >> - client identity and credentials would be configured on the server
> >> - all clients would share the same identity and credentials
> >> - credentials would be freely given to anyone who connects to
> >> multicast/multipoint
> >>
> >> The above `authype=basic` compromise does allow the credentials to be
> part
> >> of the client configuration, which is great.  It allows the same
> >> credentials the client sends over the ejbd protocol to also be sent over
> >> the HTTP layer.  The client would simply be logging in twice, once at
> the
> >> http level and once at the ejbd level.
> >>
> >>
> > Before going with this: how do you login if you don't have credential
> since
> > the multicast only share the url?
>
> Currently, users login via the InitialContext properties as in your hybrid
> proposal.
>
> p.setProperty(Context.PRINCIPAL, "tomee”);
> p.setProperty(Context.CREDENTIAL, "password”);
>
> Those login properties are sent in the EJBd protocol after connecting via
> the URL.  This currently does work with multicast(udp)/multipoint(tcp).
> It’s not perfect, but it functions and the net result is via ejbd or ejbds,
> the client can chose its identity when talking with a single server or a
> cluster.
>
>
This is something else, ejbd authentication vs container authentication.
Basic is the last one and is inherited then by the servlet integration
mecanism. I don't think you can/should compare both since they have to work
differently. That said this feature is still there until you use multiX
which doesnt have these properties.


> It’s not perfect, I’d have designed the identity tracking differently
> knowing what I know now.  But the basic idea is the client has to prove
> itself and the server will not give it the credentials.
>
> The change would be these also get used to do basic auth when layering the
> ejbd protocol over http allowing the tomcat http connector to be locked
> down and when we do that we continue to let the client chose the identity.
>

Already doable as explained so one of us miss something but can't yet
determine if it is me or you.


>
> > any global config is not acceptable there
> > - it would break the fact a single node can register multiple times.
>
> Not sure I followed this.  Both multicast(udp)/multipoint(tcp) filter out
> duplicates, but I think I’m missing the intent.
>
>
MultiX doesnt have the context hashtable so lack the identity to use.


>
> Hope any of the above is useful.
>
>
> -David
>
>

Re: authorization for ejbd/http client

[Jonathan Gallimore]

On Mon, Dec 5, 2016 at 6:24 PM, David Blevins 
wrote:

>
> > On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau 
> wrote:
> >
> > Concretely the proposal can be:
> >
> > p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> RemoteInitialContextFactory.
> > class.getName());
> > p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
> > p.setProperty(Context.PRINCIPAL, "tomee");
> > p.setProperty(Context.CREDENTIAL, "password”);
>
> This would work.
>

Sounds like a good compromise.

Jon

Re: authorization for ejbd/http client

[David Blevins]

> On Dec 5, 2016, at 10:29 AM, Romain Manni-Bucau  wrote:
> 
> 2016-12-05 19:24 GMT+01:00 David Blevins :
> 
>> 
>>> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> Concretely the proposal can be:
>>> 
>>> p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>> RemoteInitialContextFactory.
>>> class.getName());
>>> p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
>>> p.setProperty(Context.PRINCIPAL, "tomee");
>>> p.setProperty(Context.CREDENTIAL, "password”);
>> 
>> This would work.
>> 
>> 
>>> That said it doesnt help for multicast since you will loose the
>> credentials
>>> where current solution works.
>> 
>> From my perspective this is desired.
>> 
>> 
> Can you detail that? What is the case where you would not secure by network
> the cluster and not have a security hole (= what's the case where this
> additional security layer is justified)?

Let’s say you did have a closed and trusted network.  There still might be the 
use case where you have different clients on that network and want them to have 
their own identities.

You may have a desktop app or some other scenario where on your trusted 
network, users can log in and you don’t want identity statically configured on 
the server side.

>> For those that may not understand the reference.  Effectively the
>> multicast/multipoint code collects all the server URIs, aggregates them
>> together and broadcasts them to all the clients.  Putting the login
>> credentials in the URL the server broadcasts effectively broadcasts client
>> information to all the clients, which would mean:
>> 
>> - client identity and credentials would be configured on the server
>> - all clients would share the same identity and credentials
>> - credentials would be freely given to anyone who connects to
>> multicast/multipoint
>> 
>> The above `authype=basic` compromise does allow the credentials to be part
>> of the client configuration, which is great.  It allows the same
>> credentials the client sends over the ejbd protocol to also be sent over
>> the HTTP layer.  The client would simply be logging in twice, once at the
>> http level and once at the ejbd level.
>> 
>> 
> Before going with this: how do you login if you don't have credential since
> the multicast only share the url?

Currently, users login via the InitialContext properties as in your hybrid 
proposal.

p.setProperty(Context.PRINCIPAL, "tomee”);
p.setProperty(Context.CREDENTIAL, "password”);

Those login properties are sent in the EJBd protocol after connecting via the 
URL.  This currently does work with multicast(udp)/multipoint(tcp).  It’s not 
perfect, but it functions and the net result is via ejbd or ejbds, the client 
can chose its identity when talking with a single server or a cluster.

It’s not perfect, I’d have designed the identity tracking differently knowing 
what I know now.  But the basic idea is the client has to prove itself and the 
server will not give it the credentials.

The change would be these also get used to do basic auth when layering the ejbd 
protocol over http allowing the tomcat http connector to be locked down and 
when we do that we continue to let the client chose the identity.

> any global config is not acceptable there
> - it would break the fact a single node can register multiple times.

Not sure I followed this.  Both multicast(udp)/multipoint(tcp) filter out 
duplicates, but I think I’m missing the intent.


Hope any of the above is useful.


-David

Re: authorization for ejbd/http client

[Romain Manni-Bucau]

2016-12-05 19:24 GMT+01:00 David Blevins :

>
> > On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau 
> wrote:
> >
> > Concretely the proposal can be:
> >
> > p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> RemoteInitialContextFactory.
> > class.getName());
> > p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
> > p.setProperty(Context.PRINCIPAL, "tomee");
> > p.setProperty(Context.CREDENTIAL, "password”);
>
> This would work.
>
>
> > That said it doesnt help for multicast since you will loose the
> credentials
> > where current solution works.
>
> From my perspective this is desired.
>
>
Can you detail that? What is the case where you would not secure by network
the cluster and not have a security hole (= what's the case where this
additional security layer is justified)?


> For those that may not understand the reference.  Effectively the
> multicast/multipoint code collects all the server URIs, aggregates them
> together and broadcasts them to all the clients.  Putting the login
> credentials in the URL the server broadcasts effectively broadcasts client
> information to all the clients, which would mean:
>
>  - client identity and credentials would be configured on the server
>  - all clients would share the same identity and credentials
>  - credentials would be freely given to anyone who connects to
> multicast/multipoint
>
> The above `authype=basic` compromise does allow the credentials to be part
> of the client configuration, which is great.  It allows the same
> credentials the client sends over the ejbd protocol to also be sent over
> the HTTP layer.  The client would simply be logging in twice, once at the
> http level and once at the ejbd level.
>
>
Before going with this: how do you login if you don't have credential since
the multicast only share the url? any global config is not acceptable there
- it would break the fact a single node can register multiple times.


>
> -David
>
>

Re: authorization for ejbd/http client

[David Blevins]

> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau  wrote:
> 
> Concretely the proposal can be:
> 
> p.setProperty(Context.INITIAL_CONTEXT_FACTORY, RemoteInitialContextFactory.
> class.getName());
> p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
> p.setProperty(Context.PRINCIPAL, "tomee");
> p.setProperty(Context.CREDENTIAL, "password”);

This would work.


> That said it doesnt help for multicast since you will loose the credentials
> where current solution works.

From my perspective this is desired.  

For those that may not understand the reference.  Effectively the 
multicast/multipoint code collects all the server URIs, aggregates them 
together and broadcasts them to all the clients.  Putting the login credentials 
in the URL the server broadcasts effectively broadcasts client information to 
all the clients, which would mean:

 - client identity and credentials would be configured on the server
 - all clients would share the same identity and credentials
 - credentials would be freely given to anyone who connects to 
multicast/multipoint

The above `authype=basic` compromise does allow the credentials to be part of 
the client configuration, which is great.  It allows the same credentials the 
client sends over the ejbd protocol to also be sent over the HTTP layer.  The 
client would simply be logging in twice, once at the http level and once at the 
ejbd level.


-David

Re: authorization for ejbd/http client

[Romain Manni-Bucau]

2016-12-05 12:56 GMT+01:00 Jonathan Gallimore 
:

> On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau  >
> wrote:
>
> > Hi guys,
> >
> > Just a quite summary of last fixes we worked on with Jonathan regarding
> the
> > security for ejbd/http client:
> >
> > - we already have authorization parameter in the provider url for months
> > (years now?). This was not removed from the url so the user needed to
> > exclude some url from the access log if it was a security concern, this
> is
> > now done/safe
> >
>
> Awesome!
>
>
> > - we added basic.username and basic.password as shortcut for basic auth
> > which are just alimenting authorization header
> >
>
> Also awesome, thank you.
>
>
> > - we can now customize the authorization header (authorizationHeader
> param)
> >
> > All there url query parameters are stipped before doing the actual http
> > request for the reason mentionned in the first point.
> >
> > Another nice feature is the ability to cipher the properties passed to
> the
> > initial context either in a custom manner giving the context a
> > JNDIContext.Decipher implementation or relying on tomee ciphering (like
> for
> > resources) if your client is in tomee.
> >
>
> Great - I think that is really useful.
>
>
> >
> > David pointed out if you mix it with multicast you will pass in clear the
> > url value between instances. I think it is good enough cause multicast is
> > not that used and only safe in a secured (firewalled) DMZ anyway. Worse
> > case we could cipher the urls as well in the multicasting.
> >
>
> I hadn't appreciated the multicast issue, but I have worked in environments
> where that wouldn't be ok, unless the cipher used wasn't publicly
> available.
>
>
Assuming you don't use basic then it is still not ok by design so think it
is 1-1 there, no?


> One additional point that hasn't been mentioned above is: I feel that the
> ability to specify properties like so:
>
> final Properties p = new Properties();
> p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> RemoteInitialContextFactory.class.getName());
> p.setProperty(Context.PROVIDER_URL, ejbUrl);
> p.setProperty("tomee.ejb.authentication.basic.login", "tomee");
> p.setProperty("tomee.ejb.authentication.basic.password", "password");
> final InitialContext context = new InitialContext(p);
>
> is more user friendly and not necessarily at-odds with the above. The
> feedback is that this isn't portable, which I don't fully understand, but I
> do appreciate that it needs a bunch of different properties for different
> auth schemes and isn't infinitely flexible. Would be interested in people's
> thoughts.
>
>
Maybe there is a compromise which can work: reuse standard
principal/credential properties and set the header computation in the url.
Overall point is the client properties are rarely - never - well outsourced
and you most of the time only have the Context.* extracted as a
configuration when you need to switch between containers - speaking from
experience since technically you can extract properties.

Concretely the proposal can be:

p.setProperty(Context.INITIAL_CONTEXT_FACTORY, RemoteInitialContextFactory.
class.getName());
p.setProperty(Context.PROVIDER_URL, ejbUrl + "?authype=basic");
p.setProperty(Context.PRINCIPAL, "tomee");
p.setProperty(Context.CREDENTIAL, "password");


That said it doesnt help for multicast since you will loose the credentials
where current solution works.



> Cheers
>
> Jon
>

Re: authorization for ejbd/http client

[Jonathan Gallimore]

On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau 
wrote:

> Hi guys,
>
> Just a quite summary of last fixes we worked on with Jonathan regarding the
> security for ejbd/http client:
>
> - we already have authorization parameter in the provider url for months
> (years now?). This was not removed from the url so the user needed to
> exclude some url from the access log if it was a security concern, this is
> now done/safe
>

Awesome!


> - we added basic.username and basic.password as shortcut for basic auth
> which are just alimenting authorization header
>

Also awesome, thank you.


> - we can now customize the authorization header (authorizationHeader param)
>
> All there url query parameters are stipped before doing the actual http
> request for the reason mentionned in the first point.
>
> Another nice feature is the ability to cipher the properties passed to the
> initial context either in a custom manner giving the context a
> JNDIContext.Decipher implementation or relying on tomee ciphering (like for
> resources) if your client is in tomee.
>

Great - I think that is really useful.


>
> David pointed out if you mix it with multicast you will pass in clear the
> url value between instances. I think it is good enough cause multicast is
> not that used and only safe in a secured (firewalled) DMZ anyway. Worse
> case we could cipher the urls as well in the multicasting.
>

I hadn't appreciated the multicast issue, but I have worked in environments
where that wouldn't be ok, unless the cipher used wasn't publicly available.

One additional point that hasn't been mentioned above is: I feel that the
ability to specify properties like so:

final Properties p = new Properties();
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
RemoteInitialContextFactory.class.getName());
p.setProperty(Context.PROVIDER_URL, ejbUrl);
p.setProperty("tomee.ejb.authentication.basic.login", "tomee");
p.setProperty("tomee.ejb.authentication.basic.password", "password");
final InitialContext context = new InitialContext(p);

is more user friendly and not necessarily at-odds with the above. The
feedback is that this isn't portable, which I don't fully understand, but I
do appreciate that it needs a bunch of different properties for different
auth schemes and isn't infinitely flexible. Would be interested in people's
thoughts.

Cheers

Jon

authorization for ejbd/http client

[Romain Manni-Bucau]

Hi guys,

Just a quite summary of last fixes we worked on with Jonathan regarding the
security for ejbd/http client:

- we already have authorization parameter in the provider url for months
(years now?). This was not removed from the url so the user needed to
exclude some url from the access log if it was a security concern, this is
now done/safe
- we added basic.username and basic.password as shortcut for basic auth
which are just alimenting authorization header
- we can now customize the authorization header (authorizationHeader param)

All there url query parameters are stipped before doing the actual http
request for the reason mentionned in the first point.

Another nice feature is the ability to cipher the properties passed to the
initial context either in a custom manner giving the context a
JNDIContext.Decipher implementation or relying on tomee ciphering (like for
resources) if your client is in tomee.

David pointed out if you mix it with multicast you will pass in clear the
url value between instances. I think it is good enough cause multicast is
not that used and only safe in a secured (firewalled) DMZ anyway. Worse
case we could cipher the urls as well in the multicasting.

wdyt?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory