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