> On Dec 5, 2016, at 10:29 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > 2016-12-05 19:24 GMT+01:00 David Blevins <david.blev...@gmail.com>: > >> >>> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rmannibu...@gmail.com> >> 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
