2016-12-05 12:56 GMT+01:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:
> On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> 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
>
