Security in Cocoon blocks (was: Re: Linotype)

[Gianugo Rabellino <gi...@apache.org>]

Stefano Mazzocchi wrote:

>> Torsten Curdt wrote:
>>
>>> In general I agree but it makes the deployment more
>>> complicated because the authentication differs from
>>> container to container.
>>
>>
>> The container-specific part of the configuration varies, but it's 
>> usually not that complicated. And everyone who has ever deployed a 
>> J2EE webapp should know it well.
>>
>> Anyway, the current implementation of authentication in Linotype is a 
>> toy, so you'd have to rewrite it for a realistic deployment, and 
>> whoever wants to deploy Linotype using a different user repository, 
>> LDAP for example, or support single sign-on, would have to rewrite it 
>> once again.
> 
> 
>> J2EE has a standardized, declaratively specified, authentication 
>> mechanism for web apps, that is good enough for Linotype and most 
>> apps. Why reinvent it?
> 
> 
> Well, there is a big reason: ease of deployment.

*bzzzt*... this is *exactly* what container managed security buys you. 
At a price of some configuration (but, hey, it's really easy stuff), you 
get integration with your own AAA architecture, no matter what is it 
(Basic, Digest, Form, Client cert as mechanism, flat files, SQL, LDAP, 
you-name-it as user repository).

Now, whether this is suitable for a personal blogging engine, this is 
quite disputable and I can see your point somehow, but for more complex 
applications I see no other way. Why reinvent wheels all over? During 
the past years I've see all kinds of self-baked AAA solutions and _very 
few_ of them were HTTP compliant (and IIRC, Linotype actually isn't) 
since they were just layered on top (as in HTTP 200 all over instead 
than 401's with authentication performed per request).

> Linotype will be block and people will want us to deploy a block and 
> forget about it.

Uh-oh, this brings a big issue on the table. You will have a hell of a 
hard time to convince me that Cocoon (blocks) shouldn't support 
container managed authentication. If you're serious about HTTP security, 
  you cannot just forget about CMA, since you will have to forget about 
pluggable authentication mechanism, pluggable authentication layers, SSL 
aware logins, single sign-on solutions and all the like. Or reinvent 
them (and maintain them!) yourself. SoC, mate: authentication is part of 
the HTTP protocol, let's use it the way it was designed. :-)


> We don't spend 18 months of design to come up with something that is 
> totally hotdeployable and rewritable and then you throw it down the 
> drain because you have to restart the container because you have to add 
> your own little thing in the webapp deployment descriptor.

I'm all for finding a better solution, but I really can't see any ATM, 
apart from (again) just reinventing stuff.

> 
> Why reinvent what J2EE sucked at? 
 >

This is not J2EE, this is plain HTTP. You can re-invent it, if you wish, 
but you'll have to reinvent a huge pile of stuff.

well, I thought that was the reason to
> for doing cocoon in the first place.
> 
> I'm all for a better authentication strategy but if this doesn't work 
> with our way of doing stuff, well, it's not going to help anybody.
> 
>>> We would need to maintain examples for the different
>>> containers... The login page might also need to
>>> be different per container.
>>
>>
>> We can easily provide a configuration for Jetty, since that's what we 
>> distribute for running the examples (I already did and will commit it 
>> soon). Adding another one for Tomcat wouldn't be a problem at all.
> 
> 
> See, that's exactly what I mean.

Well, this is not the case actually. I would ship an _open_ Linotype 
(yeah, no username/password) and instruct people to protect it using 
their favourite strategy. This is, after all, what well-behaved Apache 
applications do: auth belongs to <Directory> or .htaccess.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)

Re: Security in Cocoon blocks

[Stefano Mazzocchi <st...@apache.org>]

Gianugo Rabellino wrote:

> Well, this is not the case actually. I would ship an _open_ Linotype 
> (yeah, no username/password) and instruct people to protect it using 
> their favourite strategy. This is, after all, what well-behaved Apache 
> applications do: auth belongs to <Directory> or .htaccess.

This is what I do for our webapps on simile.mit.edu and I think it makes 
perfect sense, but this different from what Ugo was talking about.

-- 
Stefano.