You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Jencks <da...@yahoo.com> on 2006/01/04 20:19:11 UTC
How does jetspeed security work from web-app viewpoint?
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.
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: How does jetspeed security work from web-app viewpoint?
Posted by David Jencks <da...@yahoo.com>.
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
Re: How does jetspeed security work from web-app viewpoint?
Posted by Ate Douma <at...@douma.nu>.
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
Re: How does jetspeed security work from web-app viewpoint?
Posted by David Jencks <da...@yahoo.com>.
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org