You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2016/12/05 11:17:56 UTC
authorization for ejbd/http client
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
- we added basic.username and basic.password as shortcut for basic auth
which are just alimenting authorization header
- 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.
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.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
Re: authorization for ejbd/http client
Posted by Jonathan Gallimore <jg...@tomitribe.com>.
On Mon, Dec 5, 2016 at 6:24 PM, David Blevins <da...@gmail.com>
wrote:
>
> > On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rm...@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.
>
Sounds like a good compromise.
Jon
Re: authorization for ejbd/http client
Posted by David Blevins <da...@gmail.com>.
> On Dec 9, 2016, at 2:50 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Users rely on authorizatuon query param - stripped before actual query for
> security reasons - to put the token.
Can you point at the documentation for it or paste an example that includes the InitialContext creation with the right combination of InitialContext and query parameters?
> Side note: also used for other token based solutions like oauth2 or
> equivalent.
Supported, but discouraged, by the oauth2 spec, yes. You note, they’re not sent on the wire as query parameters, so that is fine and inline.
I’d want to make sure we’re not logging the passwords.
-David
>
>
> Le 9 déc. 2016 23:32, "David Blevins" <da...@gmail.com> a écrit :
>
>> http://www.tomitribe.com
>>
>>> On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>>
>>> Le 6 déc. 2016 23:15, "David Blevins" <da...@gmail.com> a écrit
>> :
>>>
>>>
>>>> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau <rm...@gmail.com>
>>> wrote:
>>>>
>>>>> 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)
>>>
>>> We do have this exactly and I think is possibly a reason for the
>> confusion.
>>>
>>> Here’s a thread from 2008, "Desktop app communicating with EJB"
>>>
>>> - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
>>> communicating-with-EJB-td980332.html <http://tomee-openejb.979440.
>>> n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
>>>
>>> Clients can login via the RemoteInitialContext parameters and have their
>>> identity propagate with their remote calls.
>>>
>>> The only change is that the user/pass could get applied at the http layer
>>> as well.
>>>
>>>
>>> This is unrelated to my comment. Point was we can use it with multicast -
>>> which is the only issue - cause outside of the multicasted info - the
>> url.
>>>
>>>
>>> Nothing we couldnt enhance but as explained this is also not needed and
>>> your example doesnt show this is wrong.
>>
>> I’m quite lost. Can you post a code snippet on how someone uses basic
>> auth from the client side with httpd+ejbd?
>>
>> -David
>>
>>
Re: authorization for ejbd/http client
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Users rely on authorizatuon query param - stripped before actual query for
security reasons - to put the token.
Side note: also used for other token based solutions like oauth2 or
equivalent.
Le 9 déc. 2016 23:32, "David Blevins" <da...@gmail.com> a écrit :
> http://www.tomitribe.com
>
> > On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > Le 6 déc. 2016 23:15, "David Blevins" <da...@gmail.com> a écrit
> :
> >
> >
> >> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >>
> >>> 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)
> >
> > We do have this exactly and I think is possibly a reason for the
> confusion.
> >
> > Here’s a thread from 2008, "Desktop app communicating with EJB"
> >
> > - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
> > communicating-with-EJB-td980332.html <http://tomee-openejb.979440.
> > n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
> >
> > Clients can login via the RemoteInitialContext parameters and have their
> > identity propagate with their remote calls.
> >
> > The only change is that the user/pass could get applied at the http layer
> > as well.
> >
> >
> > This is unrelated to my comment. Point was we can use it with multicast -
> > which is the only issue - cause outside of the multicasted info - the
> url.
> >
> >
> > Nothing we couldnt enhance but as explained this is also not needed and
> > your example doesnt show this is wrong.
>
> I’m quite lost. Can you post a code snippet on how someone uses basic
> auth from the client side with httpd+ejbd?
>
> -David
>
>
Re: authorization for ejbd/http client
Posted by David Blevins <da...@gmail.com>.
http://www.tomitribe.com
> On Dec 6, 2016, at 2:22 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> Le 6 déc. 2016 23:15, "David Blevins" <da...@gmail.com> a écrit :
>
>
>> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>>
>>> 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)
>
> We do have this exactly and I think is possibly a reason for the confusion.
>
> Here’s a thread from 2008, "Desktop app communicating with EJB"
>
> - http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
> communicating-with-EJB-td980332.html <http://tomee-openejb.979440.
> n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
>
> Clients can login via the RemoteInitialContext parameters and have their
> identity propagate with their remote calls.
>
> The only change is that the user/pass could get applied at the http layer
> as well.
>
>
> This is unrelated to my comment. Point was we can use it with multicast -
> which is the only issue - cause outside of the multicasted info - the url.
>
>
> Nothing we couldnt enhance but as explained this is also not needed and
> your example doesnt show this is wrong.
I’m quite lost. Can you post a code snippet on how someone uses basic auth from the client side with httpd+ejbd?
-David
Re: authorization for ejbd/http client
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 6 déc. 2016 23:15, "David Blevins" <da...@gmail.com> a écrit :
> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
>> 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)
We do have this exactly and I think is possibly a reason for the confusion.
Here’s a thread from 2008, "Desktop app communicating with EJB"
- http://tomee-openejb.979440.n4.nabble.com/Desktop-app-
communicating-with-EJB-td980332.html <http://tomee-openejb.979440.
n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
Clients can login via the RemoteInitialContext parameters and have their
identity propagate with their remote calls.
The only change is that the user/pass could get applied at the http layer
as well.
This is unrelated to my comment. Point was we can use it with multicast -
which is the only issue - cause outside of the multicasted info - the url.
Nothing we couldnt enhance but as explained this is also not needed and
your example doesnt show this is wrong.
-David
Re: authorization for ejbd/http client
Posted by David Blevins <da...@gmail.com>.
> On Dec 5, 2016, at 2:54 PM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>> 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)
We do have this exactly and I think is possibly a reason for the confusion.
Here’s a thread from 2008, "Desktop app communicating with EJB"
- http://tomee-openejb.979440.n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html <http://tomee-openejb.979440.n4.nabble.com/Desktop-app-communicating-with-EJB-td980332.html>
Clients can login via the RemoteInitialContext parameters and have their identity propagate with their remote calls.
The only change is that the user/pass could get applied at the http layer as well.
-David
Re: authorization for ejbd/http client
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-12-05 23:48 GMT+01:00 David Blevins <da...@gmail.com>:
> > On Dec 5, 2016, at 10:29 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >
> > 2016-12-05 19:24 GMT+01:00 David Blevins <da...@gmail.com>:
> >
> >>
> >>> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rm...@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
>
>
Re: authorization for ejbd/http client
Posted by David Blevins <da...@gmail.com>.
> On Dec 5, 2016, at 10:29 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> 2016-12-05 19:24 GMT+01:00 David Blevins <da...@gmail.com>:
>
>>
>>> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rm...@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
Re: authorization for ejbd/http client
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-12-05 19:24 GMT+01:00 David Blevins <da...@gmail.com>:
>
> > On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rm...@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)?
> 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? any global config is not acceptable there
- it would break the fact a single node can register multiple times.
>
> -David
>
>
Re: authorization for ejbd/http client
Posted by David Blevins <da...@gmail.com>.
> On Dec 5, 2016, at 4:21 AM, Romain Manni-Bucau <rm...@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.
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.
-David
Re: authorization for ejbd/http client
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-12-05 12:56 GMT+01:00 Jonathan Gallimore <jo...@gmail.com>
:
> On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau <rmannibucau@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
>
Re: authorization for ejbd/http client
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Mon, Dec 5, 2016 at 11:17 AM, Romain Manni-Bucau <rm...@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.
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