On Jul 2, 2009, at 11:36 AM, Jarek Gawor wrote:
On Wed, Jul 1, 2009 at 6:51 PM, David Jencks<[email protected]>
wrote:
On Jul 1, 2009, at 11:04 AM, Jarek Gawor wrote:
David,
I'm trying to make things work and behave the same for ejb-based web
services as for servlet-based web services. I have a similar
security
tests to jaxws-ejb-sec for servlet-based web services - see
jaxws-war-sec. Take a look at /basicAllowGet example in web.xml. It
has one http-method specified (POST) and auth-method is configured
to
BASIC. That allows me to perform GET on the service without any
security but POST request will require BASIC auth. So if that's how
are things working for web-based services I would like to have the
same behavior for ejb-based services.
I'm not very happy with what we can configure now. With a web app,
you can
have lots of security constraints but IIUC for ejb ws you can only
have one.
So with a single web security constraint, say you restrict POST to
require
CONFIDENTIAL and auth. That means that non-POST requests are
completely
unconstrained both for transport and for auth. In a web app you
can have
more constraints so that e.g. there's still transport guarantee.
If we imitate this with ejb constraints but only allow a single
constraint,
then adding a http method into the mix mostly unsecures everything
else. I
don't think this is a good idea. I think there are 2 reasonable
options:
1. if we only allow a single constraint, only grant the permissions
from
that constraint.... everything else is prohibited. This is nearly
the
opposite of what servlet constraints do. This is pretty easy to
implement.
2. allow full web-like multiple security-constraint elements
although we'd
ignore the role-constraint mapping since the ejb security ought to
be more
meaningful. This is more complicated to implement, but might not
be exactly
difficult.
I don't understand why a single security constraint in web should be
handled differently then a single security constraint in ejb. Bottom
line is that we do want to provide an option for unsecure access for
GETs to retrieve the wsdl and secure access for all other HTTP
methods. The issue is mainly with the javax.xml.ws.Service API where
you have to pass a service wsdl url to create an instance of it but
there is no easy way to specify what authentication method and/or
credentials to use to retrieve that wsdl. And once you have the
Service instance there is an easy way to configure the
credentials/authentication method on the port object for the
invocation (the POST, PUT, etc. requests).
Since there are an infinite set of http methods now, you can't secure
all non-GET requests with one servlet 2.5 security constraint. I'm
not sure if there's a syntax for servlet 3.0 web.xml to exclude GET
requests but apparently you can do it on servlets with annotations.
So I don't know how to produce this effect for POJO ws but its pretty
easy for ejb ws with two permissions.
If the only use case is the binary choice between
-- secure all requests with transport guarantee and authentication
-- secure all non-GET requests with transport guarantee and
authentication but allow all GET requests with no transport guarantee
or authentication
then I think a flag in our xml would be more appropriate than what we
have now.
Are there other choices?
thanks
david jencks
Jarek
