cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Marasti-Georg" <cge...@rjlg.com>
Subject RE: Authentication Options in Cocoon- a Design Discussion
Date Thu, 04 Aug 2005 15:19:12 GMT
One option that you did not mention is ACEGI.  Since you mentioned you
are using spring, you could easily put an acegi filter in front of the
servlet requests... You could even use cocoon to display the login page,
and probably to perform any redirection after authentication (you could
of course use a basic spring controller for this as well)

Just 2 more cents on top of the pile.

Chris Marasti-Georg
 

> -----Original Message-----
> From: Cocoon User [mailto:cocoon_mail@hotmail.com] 
> Sent: Thursday, August 04, 2005 10:49 AM
> To: users@cocoon.apache.org
> Subject: Authentication Options in Cocoon- a Design Discussion
> 
> I apologize if posting a design discussion this is too broad 
> of a topic (I wasn't sure-please forgive me in advance!), but 
> I promise I will Wiki this if I get good answers and I think 
> it will be useful for a lot of people. 
> Also, I apologize for the length of this post but I am hoping 
> the detail will increase my chances of quality responses.
> 
> I am trying to understand what the pros and cons of using the 
> Authentication Framework versus container implemented 
> Authentication. At this time, I do not feel I have a strong 
> feel for the pros and cons of either one and would very much 
> like to engage in a design discussion from those who have the 
> benefit of the experience that I do not in this area.
> 
> 
> To set the stage a little, the cocoon wiki has an article 
> that briefly mentions these otions and their pros and cons  
> (see below):
> 
> (start of wiki quote)
> 
> "When you have to implement authentication and users 
> management in a Cocoon application you have mainly four solutions :
> *	Using JAAS security mechanisms specified in J2EE 
> standards and implemented 
> by containers (see [AuthWithTomcat])
> *	Using the  authentication framework
> *	 CoWarp
> *	Implementing your own security policy.
> 
> 
> The first approach lacks flexibility. The second one is very 
> generic and 
> hence very difficult to implement, all the more so as 
> documentation is not 
> very clear on that point :-P I don't know about the third 
> solution. I've 
> just heard of it but I skipped it as I thought implementing 
> my own security 
> policy using flowscript and my Spring layer was easier and 
> more flexible. "
> 
> (end of Wiki quote)
> 
> I see and hear a lot of comments like "don't use this-its 
> bad" and "use 
> that" but I can't seem to find a deep meaningful discussion 
> anywhere where I 
> can justify for myself.  I tried to find acheive this depth 
> of analysis 
> myself by researching,  for example:
> 
> I have:
> - read the Authentication Framework documentation and 
> implemented a basic 
> login form so I coulld see it in action-this is very 
> "prototypish' since it 
> was really just an exercise to get my feet wet
> - read the AuthWithTomcat Wiki Article
> -read several other articles on Authentication in general (as 
> well as cocoon 
> docs on session contexts, session management)
> -read several newsgroup posts
> -read a the brief intro to coWarp
> -had some brief discussions with trusted colleages.
> 
> BTW- I have no experience implementing authentication at all 
> (but know 
> enough to think carefully before implementing)
> 
> So, here are my initial thoughts on the 4 options (not 
> claiming to be an 
> expert or anything-just piecing all of the fragments together)
> 
> 1.)Container implemented: I got the impression from reading 
> AuthWithTomcat 
> that what this other cocoon wiki article says is true, it 
> appears that you 
> are limited in some ways. For example, when defining the url 
> pattern for the 
> protected resources, you cannot not use as complex 
> expressions as you can in 
> the pipeline matchers. I am not sure if this is what he was 
> referring to or 
> if there is more to it. Also, I am not sure how much this 
> will limit me. On 
> the flip side, some colleages and articles said said it is 
> better do do both 
> authentication and authorization in the container. Don't know 
> enough about 
> this to know why that is better, other than the 2 are related 
> any maybe 
> belong together for that reason. Would like to hear some 
> solid supporting or 
> negating arguments on this as opposed to "its just better".
> 
> 2.)Using the  authentication framework - seems easy to use in 
> a lot of ways, 
> althought I have not got far enough into it to know what the 
> gotchas are. I 
> have heard some people complain about how it is tied to the 
> portal framework 
> and that is bad, but I am not sure why that is bad. Also it 
> ties you to 
> cocoon, which I don't see aas a bad thing for the particular 
> project I am 
> on, but a purist may argue differently, and on a different 
> project with a 
> better skilled team, I might argue the same point.On this 
> team, I think that 
> might be OK (challenge me on this if I am wrong).  Anyway,  I 
> suspect  once 
> someone is authenticated, you can further restrict private 
> pages against 
> authenticated users who don't have access to your resouce by 
> writing your 
> own selector that checks the access for the user to that 
> resource and based 
> on the feedback for the selector they are  permitted or 
> denied access. I 
> have not tested the authorization piece I just described, and 
> I am not sure 
> if I am off in the weeds with my selector solution or not. In 
> addition, I 
> need to understand what, if any, impacts this has to session 
> management (I 
> realized this is handled by the container, but haven't 
> gottenmuch further 
> than that yet. (BTW, we aren't using portal..does this matter?)
> 
> 
> 3.)CoWarp: Read up on this, and I understand this is supposed 
> solve the some 
> of the limitations with the authentication -fw. However, this 
> seems to 
> leverage flows which we are not using.  Also seems very new 
> and therefore 
> too risky. I am generally not looking at this, but I am open to all 
> feedback. Actually, I am more interested in hearing  those 
> authentication-fw 
> drawbacks to know if they will affect me or not.
> 
> 
> 4.)Implementing your own security policy: Um..I am truly 
> concerned about 
> this option. Granted I don't have experience with this, but I 
> have no doubt 
> in my ability to rise to the challenge. The issue is my team 
> is low on skill 
> and low on resources. Most of them found the cocoon learning 
> curve to be 
> steep and have very dated technology background. My requirement is to 
> implement the simplist solution with the least java code, but not 
> sacraficing good design or security. Not sure that rolling my 
> own here is 
> the best solution for me team. I need to think about what I 
> leave behind 
> after I am gone and what people will be left to maintain. 
> Unless there is 
> something simple here that I missing but I don't think 
> something like this 
> is simple ever.
> 
> 
> So, I am hoping to get feedback of any kind from those with 
> experience.
> 
> Thanks in advance-
> NSR
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> - it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message