On Wed, Jul 1, 2009 at 6:51 PM, David Jencks<david_jen...@yahoo.com> 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). Jarek
