On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau <[email protected]>
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
