portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: How does jetspeed security work from web-app viewpoint?
Date Thu, 05 Jan 2006 09:01:35 GMT
After more fiddling around and fixing GERONIMO-1012 I got jetspeed to  
work with (a modified version of) the GeronimoSecurityValve.  As you  
suggest, after login the subject is stored so that all access is  
authenticated.  I haven't figured out exactly what changed, but it  
seems to be working now.  I've posted the code to JS2-444.

For me, the next steps are to make this work with jetty and further  
investigate how to do jetspeed security with JACC.  I also want  a  
closer deployment integration that will not require use of the deploy- 
tool on wars before deployment.

many thanks,
david jencks

On Jan 4, 2006, at 5:18 PM, Ate Douma wrote:

> David,
> Sorry for the late response and all the investigating you had to do  
> without
> our help so far.
> I've commented on your questions below.
> David Jencks wrote:
>> On Jan 4, 2006, at 11:19 AM, David Jencks wrote:
>>> I'm trying to figure out why my attempt to use the JAAS login to   
>>> supply the subject for jetspeed security in geronimo doesn't  
>>> work  and could use a hint about how jetspeed security is  
>>> supposed to  work from the viewpoint of a web (not portlet)  
>>> application.
>>> What appears to me to be happening is that pressing the login   
>>> button on the jetspeed "first page" results in a call to the web   
>>> server that is authenticated and logs in, but that this call  
>>> does  not result in any access to the portal itself, and the  
>>> subsequent  calls to the portal that result in portlet rendering  
>>> are not  authenticated.  I'm not sure I understand how redirects  
>>> work, but  my weak-kneed attempts to understand the  
>>> LoginRedirectorServlet  seem to be consistent with this.  I also  
>>> don't see any security  constraints on the jetspeed servlet.
> Almost correct so far.
> Indeed, there are no security constraints (by default that is) on  
> the jetspeed
> servlet. That doesn't mean you can't or shouldn't define them, but  
> that is not
> required for plain usage of jetspeed.
> The difference with a "normal" secured web application is that for  
> a portal
> request (e.g. accessing  the jetspeed servlet) its url doesn't have  
> to indicate
> *anything* concerning security constraints.
> A portal request delivers content aggregated from one or more  
> portlets which can
> have their own security constraints (see jsr-168 PLT.20.4).
> To support those *portlet* security constraints, a portal *might*  
> switch/redirect
> to https for instance if for one (or more) portlets to be  
> aggregated in the
> returned content for the portal request a  user data constraint is  
> specified.
> Note: Jetspeed doesn't support this yet, nor is it required by the  
> spec/tck.
> For authentication/role security, the portlet spec only requires  
> the container to
> *inform* a portlet the roles users are in when accessing them (PLT. 
> 20.1).
> So, Jetspeed provides a way for a user to authenticate/login  
> through the portal
> and (by default) doesn't require anything more than that. Once a  
> user is
> authenticated by the webcontainer, the webcontainer is used to  
> provide the
> getRemoteUser, isUserInRole and getUserPrincipal methods as  
> required by the portlet
> api and as such this is working, on Tomcat and JBoss at least it is.
> If you have the default Jetspeed setup running on Geronimo  
> including the demo
> portlets (sorry, I haven't found the time to test your setup yet),  
> this is
> tested/verified by the "Role Security Test" Portlet as shown on the  
> portal start page.
> If you login with a user which has a admin, manager and/or user  
> role assigned this
> portlet will tell you so.
>>> If this is correct it seems to me that there is no way to  
>>> enforce  any transport-guarantees.
> As I described above (hopefully clear enough) this is not a  
> requirement for the
> *portal* web application.
>>> Assuming this analysis has some relationship to what is  
>>> happening,  is it possible to set up the security so that access  
>>> that requires  login is done through a resource subject to a  
>>> security constraint?
>>> Any hints about what is actually going on would be greatly   
>>> appreciated.
>> After some experimentation I think my description above is more  
>> or  less correct.  If I set up an alternate secured path into the  
>> webapp  the GeronimoSecurityValve works fine (after suitable  
>> modification).
> Now, there is an important difference in your GeronimoSecurityValve  
> and the SecurityValve
> as provided by Jetspeed: the SecurityValve only retrieves the  
> subject *once* after
> login and then saves it in the session. Subsequent requests then  
> reuse that subject
> from the session (see: SecurityValve.java line 81).
> As the GeronimoSecurityValve is retrieving the Subject for each  
> request from the
> ContextManager it looks as if it isn't getting the correct (if  
> any?) Subject back when
> a request is not performed for a secured url.
> Now, this makes me question the ContextManager implementation and/ 
> or how Tomcat handles
> authentication. Once a user has been authenticated for a web  
> application, shouldn't *all*
> subsequent requests (until logout) be handled as likewise  
> authenticated?
>> I'd still appreciate a comment on why jetspeed security is set up  
>> in  this way as it seems to me as if it is sidestepping servlet  
>> security  completely.
> Well, at least that I hope to have cleared up as being *not* the  
> case :-)
>> thanks
>> david jencks
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message