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
>
>

Reply via email to