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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
