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.
If this is correct it seems to me that there is no way to enforce
any transport-guarantees.
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).
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.
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
