geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Trunk Builds
Date Thu, 02 Jul 2009 19:43:03 GMT

On Jul 2, 2009, at 11:36 AM, Jarek Gawor wrote:

> On Wed, Jul 1, 2009 at 6:51 PM, David Jencks<>  
> 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 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?

david jencks

> Jarek

View raw message