2016-12-05 23:48 GMT+01:00 David Blevins <david.blev...@gmail.com>: > > 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. > > 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 > >