portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: How does jetspeed security work from web-app viewpoint?
Date Thu, 05 Jan 2006 01:18:51 GMT
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


Mime
View raw message