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 2005/12/23 00:05:01 UTC
Jetspeed 2 - Geronimo security integration (from apachecon)
At Apachecon some Jetspeed and Geronimo committers got together and
discussed Jetspeed 2 - Geronimo security integration a bit. Here's
what I remember: please chime in if you remember more/differently.
People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
David Jencks and ???
1. Jetspeed in tomcat is currently creating a separate "jetspeed
subject" because it isn't clear how to get the JAAS subject that
tomcat creates for use in jetspeed security. In geronimo we create a
special Principal that has a reference to the Subject
(JAASTomcatPrincipal). Probably Jetspeed can use the same idea in
Tomcat to get the JAAS subject and avoid the "fake login".
2. IIUC correctly jetspeed security currently requires a login module
to use specific principal classes, and there is a direct mapping
between instances of these classes and jetspeed portal/portlet
permissions. This is not very j2ee-like, at least as geronimo
interprets it :-) In particular it seems excessively restrictive to
require the use of specific principal classes. On the other hand
jetspeed implements an on-the-fly permissions-changing facility that
will take some work to fit into a jacc-like structure. Here is one
way to proceed that I tried to explain and I think got general
agreement that it deserved at least further consideration:
a. In analogy to the role-permissions mapping specified for web apps
and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
(presumably xml) jetspeed specific deployment descriptor. With a
suitable deployer this can be fed into a jacc-compliant app server:
in geronimo this can be fed into PolicyConfigurationGeneric. In j2ee
such a mapping is static, part of the original deployment descriptor,
and cannot be changed without redeploying the app. I'm inclined to
think that such a restriction may also work for jetspeed but don't
have enough info for my opinion to count for much. I think
implementing this as a first step would be a good idea.
b. Use the existing geronimo specific role-principal mapping to
connect the principals created by an arbitrary login module with the
roles set up in (a). This would result in jetspeed security being
integrated into the existing geronimo jacc security framework.
However, it would not immediately result in being able to change
permissions without redeploying the application.
c. Investigate how to make this more dynamic. One possibility is to
simply use the jacc facilities, which involve opening the policy
configuration (at which point it is taken out of service and no
requests can get through), modifying it, and committing the changes
(at which time it is put back into service and the new policy rules
are in force). It is not entirely clear to me if the requests made
while the configuration is open can be made to wait or if they must
be refused. I do think that some kind of transactional change
mechanism is needed so that many changes can be made in one operation.
If anyone finds what I am talking about unclear please ask questions,
I will be happy to try to explain in more detail.
Many 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: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by Randy Watler <wa...@wispertel.net>.
David,
Before I jump on this thread, I'd like to thank you for your interest
and continued research in how J2 security can be modified to work and
play well with Geronimo. Hopefully, we can wrestle this issue to the
ground in short order!
On Fri, 2005-12-23 at 22:03 +0100, Ate Douma wrote:
> David Jencks wrote:
> >
> > I'd like to understand a lot more about the use cases here, and if
> > there are any docs please point me to them :-) Some of my questions are:
A document that covers page/portlet level security constraints can be
found here:
http://portals.apache.org/jetspeed-2/guides/guide-security-declarative-psml.html
This document describes how J2 uses its PSML based security constraints
to make authorization decisions based on the user, role, and group
principals stored in the "fake" J2 Subject.
Here is a common use case for changing J2 Subjects for a given user:
1. A new user is created by their request that carries only the new user
principal. This allows the user to "see" a subset of the site that
allows all users, (i.e. publicly accessible pages/portlets).
2. At some point, it is decided that the new user is to be a granted
access to some pages associated with an existing group and role, (for
example, say group is 'accounting' and role is 'officer'). An admin then
would add the group and role to the user.
3. Immediately after the user has been added to the group and role, the
portions of the portal that require either or both authorizations would
be available to the user.
A common use case for changing J2 roles and groups:
1. A new portion of a corporate portal is created by adding pages and
portlets to access a new client's detailed billing information. The
various portlets and pages are developed and deployed in the portal.
2. Access to this information needs to tightly controlled. To do so, a
new group is created to segregate this information in a secure fashion
from all of the other clients served by the portal. All of the new
portlets and pages are constrained to require users be a member of this
group.
3. In addition to the coarse grain client access rules, some information
can only be seen by individuals with certain roles in the client's
organization. For example, only officers are allowed to view contracts
and disputed charges, but anyone with access is allowed to view the
current billing account status. New role constraints are assigned to the
more sensitive pages/portlets.
4. An administrator then assigns all the registered users of the portal
from the client to be a member of the client group. In addition, some
users are granted certain roles to give authorization to protected
pages/portlets within new client's portion of the portal.
We assume that the portal provider would like to perform these
operations without having to interrupt the portal application as a whole
since potentially only a small segment of the portal users are being
served by these activities.
> >
> > - do the portal/portlet permissions apply to the portal app or the
> > portlet app deployed in the portal?
> Both: we have portlet permissions (portlet app) and also something like page permissions
> (portal app).
> > - Where do new portlet pages come from (and are they portlet pages or
> > portal pages)? Can they be added to a running system or do they
> > require (re)deployment of a portlet application? Are they additional
> > portlets or servlets that should be represented in the portlet.xml or
> > web.xml deployment descriptor or are they representable as additional
> > parameters to an existing portlet or servlet?
> "Portlet" pages as such do not exists, although we support a specific invocation for
> only one portlet output in a request (a jetspeed specific feature).
> A "Portal" page is deployed to/managed by the portal.
> Currently, there is no formal deployment model or dd for it and the portlet spec
> says really *nothing* about a page other than it can contain/represent one or more
> portlets (which may originate from different portlet apps).
Currently, pages can be added using an administrative portlet
application, by adding PSML page documents in the file system, and/or by
adding PSML page definitions in the Page Manager DB. One can certainly
package a set of pages for initial deployment in the portal, but adding
pages dynamically is one of the primary ways the portal is extended and
customized per user.
> >
> > - In the existing jetspeed implementation, what kind of "transactional"
> > behavior is there to allow applying a set of security changes at once?
> We control this ourselves through Spring configured transactions. Can be a single or multiple
> changes, depending on our configuration.
>
Changes to a user's principals, (groups and roles in the J2 sense),
occur with the first new session following modification by the
administrator. IIRC, we do not attempt to clear session based "fake" J2
Subjects as part of the admin transaction.
Page and portlet constraints are evaluated per request. So, changes to
security constraints would be relatively immediate.
> >
> > - Are the contents of the request needed to make authorization decisions?
> I'm not sure I understand what you mean here.
> Request/query parameters?
> In that case, I think not, but maybe Randy Watler and/or David Sean Taylor should respond
> to this one.
>
Through the use of the J2 Profiler Component, just about any part of a
request, (host, path, parameters, HTTP headers, etc.), can be used to
address a set of portal pages. Session state can also be used. Any given
request combined with the session state will unambiguously "select" a
given page. Then, the security constraints in and related to the page
are checked against the "fake" J2 Subject principals to make an
authorization decision. Success results in the portal presenting the
page and the portlets on the page the user is authorized to "see".
Hope that explains what we are doing with the Subject/principals.
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On Dec 23, 2005, at 6:09 AM, Ate Douma wrote:
>
>> David Jencks wrote:
>> > At Apachecon some Jetspeed and Geronimo committers got together and
>> > discussed Jetspeed 2 - Geronimo security integration a bit. Here's
>> > what I remember: please chime in if you remember more/differently.
>> >
>> > People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
>> > David Jencks and ???
>> >
>> > 1. Jetspeed in tomcat is currently creating a separate "jetspeed
>> > subject" because it isn't clear how to get the JAAS subject that
>> tomcat
>> > creates for use in jetspeed security.
>> Correct.
>>
>>
>> > In geronimo we create a special
>> > Principal that has a reference to the Subject (JAASTomcatPrincipal).
>> > Probably Jetspeed can use the same idea in Tomcat to get the JAAS
>> > subject and avoid the "fake login".
>> For Tomcat (and probably Jetty too) we can look into using that
>> solution.
>> But: if we do that, we will also need to have a handling in place for
>> other web/app servers like JBoss, WebSphere etc.
>> Because we currently use our own "fake" Subject throughout, we need
>> to make
>> sure replacing that with the "real" Subject will provide the same/
>> similar
>> features we now rely on.
>
> I am speculating, but I think one possible outcome (possibly for the
> distant future) might be something like:
>
> -jetspeed only provides security on platforms with a jacc implementation
> -jetspeed uses the jacc mechanism to insert and modify the role-
> permission mappings
> -jetspeed provides, as one choice, a JAAS login module that produces
> jetspeed-friendly principals for easy role-principal mapping
> -jetspeed relies on the jacc implementation for the actual role-
> principal mapping.
>
> I haven't investigated but I would hope that this would let the jacc
> framework implement all or most of isUserInRole.
I can't really oversee it yet either, but if this all could be done as you
proposes but it really sounds promising.
>
>>
>> >
>> > 2. IIUC correctly jetspeed security currently requires a login module
>> > to use specific principal classes, and there is a direct mapping
>> > between instances of these classes and jetspeed portal/portlet
>> > permissions. This is not very j2ee-like, at least as geronimo
>> > interprets it :-)
>> > In particular it seems excessively restrictive to
>> > require the use of specific principal classes. On the other hand
>> > jetspeed implements an on-the-fly permissions-changing facility that
>> > will take some work to fit into a jacc-like structure.
>> To be precise: jetspeed provides an api (and portlets) to map role,
>> group
>> and user principals to each other. This is on-the-fly, but requires a
>> subject
>> (user principal) to (re)login for new (or removed) mappings to get
>> into effect.
>> The same can be done with (portal/portlet) permissions assignments to
>> principals,
>> *but doesn't imply it*.
>> Roles (nor groups) require any (explicit) permission but can be used
>> independent.
>
> My understanding of this is that it requires use of a jetspeed- specific
> login module or at least one that adds jetspeed-specific principals to
> the JAAS Subject. I suspect this may not be appropriate for all
> deployments, such as ones using an existing ldap system.
Why not?
I know some use ldap with Jetspeed so (some of) it should be possible, although
I haven't tested or used it myself.
>
>>
>> The Portlet API defines *no* requirements/restrictions/permission for
>> role usage.
>> It leaves it to the container/portlet developer how to use it and it
>> only
>> defines a request.isUserInRole('roleName') api, nothing more.
>
> I know nothing about the plans for the portlet 2.0 spec, but I wonder
> if defining a set of portlet permissions and a role-permission mapping
> analogous to those for web apps and ejbs would be a reasonable goal.
Well, both David Sean Taylor and myself are part of the portlet 2.0 spec
Expert Group ;-)
>
>>
>> Reading the jacc specification (I'm just getting into it so bear with
>> me if I'm
>> missing the finer details of the spec) it seems as it defines a role
>> as (only) a
>> named set of permissions. I'm not sure we might have a definition
>> problem here (too).
>
> I think the jacc spec takes a quite different view than the current
> jetspeed implementation. I would say that a (jacc) role is an object
> scoped to a j2ee application whose only attribute is its name. The web
> and ejb spec deployment descriptors define (abstractly, and as
> specified in detail in the jacc spec) a role to permissions mapping.
> The jacc spec does not indicate or specify the Subject/Principal to
> role mapping. It does specify an api whereby the algorithm that
> determines permissions can use the invocation information (request for
> web apps, ejb method name and args for ejbs, etc) in the authorization
> decision. Currently the Geronimo implementation defines a static
> role-permissions mapping that can only be changed at deployment time.
> This information from the geronimo plan is combined with the spec-dd
> specified role-permissions mapping to make a principal-permissions map
> which is actually used in authorization decisions. Geronimo is not
> currently using the invocation information in authorization decisions.
>
> IIUC the jetspeed view of a role is an instance of a specific Principal
> class. While this simplifies some parts of security setup, I think it
> will cause problems in some environments.
Ok. I'm open to see how we can improve/correct this, hopefully in a way which
still supports our current security handling.
>
>>
>> > Here is one way
>> > to proceed that I tried to explain and I think got general agreement
>> > that it deserved at least further consideration:
>> Yes
>>
>> >
>> > a. In analogy to the role-permissions mapping specified for web apps
>> > and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
>> > (presumably xml) jetspeed specific deployment descriptor. With a
>> > suitable deployer this can be fed into a jacc-compliant app
>> server: in
>> > geronimo this can be fed into PolicyConfigurationGeneric. In j2ee
>> such
>> > a mapping is static, part of the original deployment descriptor, and
>> > cannot be changed without redeploying the app. I'm inclined to think
>> > that such a restriction may also work for jetspeed
>> I'm afraid I'm not yet convinced of that yet: this needs further
>> investigation.
>>
>> > but don't have
>> > enough info for my opinion to count for much. I think implementing
>> > this as a first step would be a good idea.
>> Agreed, for a first test setup yes.
>> But we require support for dynamically changing role/permission
>> assignments
>> or restrictions on newly created pages for instance (which also can
>> be done
>> dynamically from with Jetspeed) in a releasable version.
>
> I'd like to understand a lot more about the use cases here, and if
> there are any docs please point me to them :-) Some of my questions are:
>
> - do the portal/portlet permissions apply to the portal app or the
> portlet app deployed in the portal?
Both: we have portlet permissions (portlet app) and also something like page permissions
(portal app).
> - Where do new portlet pages come from (and are they portlet pages or
> portal pages)? Can they be added to a running system or do they
> require (re)deployment of a portlet application? Are they additional
> portlets or servlets that should be represented in the portlet.xml or
> web.xml deployment descriptor or are they representable as additional
> parameters to an existing portlet or servlet?
"Portlet" pages as such do not exists, although we support a specific invocation for
only one portlet output in a request (a jetspeed specific feature).
A "Portal" page is deployed to/managed by the portal.
Currently, there is no formal deployment model or dd for it and the portlet spec
says really *nothing* about a page other than it can contain/represent one or more
portlets (which may originate from different portlet apps).
>
> - In the existing jetspeed implementation, what kind of "transactional"
> behavior is there to allow applying a set of security changes at once?
We control this ourselves through Spring configured transactions. Can be a single or multiple
changes, depending on our configuration.
>
> - Are the contents of the request needed to make authorization decisions?
I'm not sure I understand what you mean here.
Request/query parameters?
In that case, I think not, but maybe Randy Watler and/or David Sean Taylor should respond
to this one.
>
>
>> >
>> > b. Use the existing geronimo specific role-principal mapping to
>> connect
>> > the principals created by an arbitrary login module with the roles
>> set
>> > up in (a). This would result in jetspeed security being integrated
>> > into the existing geronimo jacc security framework. However, it
>> would
>> > not immediately result in being able to change permissions without
>> > redeploying the application.
>> >
>> > c. Investigate how to make this more dynamic. One possibility is to
>> > simply use the jacc facilities, which involve opening the policy
>> > configuration (at which point it is taken out of service and no
>> > requests can get through), modifying it, and committing the
>> changes (at
>> > which time it is put back into service and the new policy rules
>> are in
>> > force). It is not entirely clear to me if the requests made while
>> the
>> > configuration is open can be made to wait or if they must be refused.
>> > I do think that some kind of transactional change mechanism is needed
>> > so that many changes can be made in one operation.
>> Sounds good a good summary of what we've discussed so far at ApacheCon.
>>
>> >
>> > If anyone finds what I am talking about unclear please ask
>> questions, I
>> > will be happy to try to explain in more detail.
>> I'm looking forward working with all of you on this.
>
> Likewise!
>
> thanks
> david jencks
>
Thanks for the support David, I know you planned to take some time off these days.
I will be mostly offline the next few days, so a next response might take some time.
Take care and Happy Christmas anyone!
Regards, Ate
>>
>> I've good hopes we can have the security integration with Geronimo
>> working soon
>> and I expect the Jetspeed security implementation to improve from that
>> as well.
>>
>> Regards, Ate
>>
>> >
>> > Many 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by David Jencks <da...@yahoo.com>.
On Dec 23, 2005, at 6:09 AM, Ate Douma wrote:
> David Jencks wrote:
> > At Apachecon some Jetspeed and Geronimo committers got together and
> > discussed Jetspeed 2 - Geronimo security integration a bit. Here's
> > what I remember: please chime in if you remember more/differently.
> >
> > People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
> > David Jencks and ???
> >
> > 1. Jetspeed in tomcat is currently creating a separate "jetspeed
> > subject" because it isn't clear how to get the JAAS subject that
> tomcat
> > creates for use in jetspeed security.
> Correct.
>
>
> > In geronimo we create a special
> > Principal that has a reference to the Subject
> (JAASTomcatPrincipal).
> > Probably Jetspeed can use the same idea in Tomcat to get the JAAS
> > subject and avoid the "fake login".
> For Tomcat (and probably Jetty too) we can look into using that
> solution.
> But: if we do that, we will also need to have a handling in place for
> other web/app servers like JBoss, WebSphere etc.
> Because we currently use our own "fake" Subject throughout, we need
> to make
> sure replacing that with the "real" Subject will provide the same/
> similar
> features we now rely on.
I am speculating, but I think one possible outcome (possibly for the
distant future) might be something like:
-jetspeed only provides security on platforms with a jacc implementation
-jetspeed uses the jacc mechanism to insert and modify the role-
permission mappings
-jetspeed provides, as one choice, a JAAS login module that produces
jetspeed-friendly principals for easy role-principal mapping
-jetspeed relies on the jacc implementation for the actual role-
principal mapping.
I haven't investigated but I would hope that this would let the jacc
framework implement all or most of isUserInRole.
>
> >
> > 2. IIUC correctly jetspeed security currently requires a login
> module
> > to use specific principal classes, and there is a direct mapping
> > between instances of these classes and jetspeed portal/portlet
> > permissions. This is not very j2ee-like, at least as geronimo
> > interprets it :-)
> > In particular it seems excessively restrictive to
> > require the use of specific principal classes. On the other hand
> > jetspeed implements an on-the-fly permissions-changing facility that
> > will take some work to fit into a jacc-like structure.
> To be precise: jetspeed provides an api (and portlets) to map role,
> group
> and user principals to each other. This is on-the-fly, but requires
> a subject
> (user principal) to (re)login for new (or removed) mappings to get
> into effect.
> The same can be done with (portal/portlet) permissions assignments
> to principals,
> *but doesn't imply it*.
> Roles (nor groups) require any (explicit) permission but can be
> used independent.
My understanding of this is that it requires use of a jetspeed-
specific login module or at least one that adds jetspeed-specific
principals to the JAAS Subject. I suspect this may not be
appropriate for all deployments, such as ones using an existing ldap
system.
>
> The Portlet API defines *no* requirements/restrictions/permission
> for role usage.
> It leaves it to the container/portlet developer how to use it and
> it only
> defines a request.isUserInRole('roleName') api, nothing more.
I know nothing about the plans for the portlet 2.0 spec, but I wonder
if defining a set of portlet permissions and a role-permission
mapping analogous to those for web apps and ejbs would be a
reasonable goal.
>
> Reading the jacc specification (I'm just getting into it so bear
> with me if I'm
> missing the finer details of the spec) it seems as it defines a
> role as (only) a
> named set of permissions. I'm not sure we might have a definition
> problem here (too).
I think the jacc spec takes a quite different view than the current
jetspeed implementation. I would say that a (jacc) role is an object
scoped to a j2ee application whose only attribute is its name. The
web and ejb spec deployment descriptors define (abstractly, and as
specified in detail in the jacc spec) a role to permissions mapping.
The jacc spec does not indicate or specify the Subject/Principal to
role mapping. It does specify an api whereby the algorithm that
determines permissions can use the invocation information (request
for web apps, ejb method name and args for ejbs, etc) in the
authorization decision. Currently the Geronimo implementation
defines a static role-permissions mapping that can only be changed at
deployment time. This information from the geronimo plan is combined
with the spec-dd specified role-permissions mapping to make a
principal-permissions map which is actually used in authorization
decisions. Geronimo is not currently using the invocation
information in authorization decisions.
IIUC the jetspeed view of a role is an instance of a specific
Principal class. While this simplifies some parts of security setup,
I think it will cause problems in some environments.
>
> > Here is one way
> > to proceed that I tried to explain and I think got general
> agreement
> > that it deserved at least further consideration:
> Yes
>
> >
> > a. In analogy to the role-permissions mapping specified for web apps
> > and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
> > (presumably xml) jetspeed specific deployment descriptor. With a
> > suitable deployer this can be fed into a jacc-compliant app
> server: in
> > geronimo this can be fed into PolicyConfigurationGeneric. In
> j2ee such
> > a mapping is static, part of the original deployment descriptor,
> and
> > cannot be changed without redeploying the app. I'm inclined to
> think
> > that such a restriction may also work for jetspeed
> I'm afraid I'm not yet convinced of that yet: this needs further
> investigation.
>
> > but don't have
> > enough info for my opinion to count for much. I think implementing
> > this as a first step would be a good idea.
> Agreed, for a first test setup yes.
> But we require support for dynamically changing role/permission
> assignments
> or restrictions on newly created pages for instance (which also can
> be done
> dynamically from with Jetspeed) in a releasable version.
I'd like to understand a lot more about the use cases here, and if
there are any docs please point me to them :-) Some of my questions
are:
- do the portal/portlet permissions apply to the portal app or the
portlet app deployed in the portal?
- Where do new portlet pages come from (and are they portlet pages or
portal pages)? Can they be added to a running system or do they
require (re)deployment of a portlet application? Are they additional
portlets or servlets that should be represented in the portlet.xml or
web.xml deployment descriptor or are they representable as additional
parameters to an existing portlet or servlet?
- In the existing jetspeed implementation, what kind of
"transactional" behavior is there to allow applying a set of security
changes at once?
- Are the contents of the request needed to make authorization
decisions?
> >
> > b. Use the existing geronimo specific role-principal mapping to
> connect
> > the principals created by an arbitrary login module with the
> roles set
> > up in (a). This would result in jetspeed security being integrated
> > into the existing geronimo jacc security framework. However, it
> would
> > not immediately result in being able to change permissions without
> > redeploying the application.
> >
> > c. Investigate how to make this more dynamic. One possibility is to
> > simply use the jacc facilities, which involve opening the policy
> > configuration (at which point it is taken out of service and no
> > requests can get through), modifying it, and committing the
> changes (at
> > which time it is put back into service and the new policy rules
> are in
> > force). It is not entirely clear to me if the requests made
> while the
> > configuration is open can be made to wait or if they must be
> refused.
> > I do think that some kind of transactional change mechanism is
> needed
> > so that many changes can be made in one operation.
> Sounds good a good summary of what we've discussed so far at
> ApacheCon.
>
> >
> > If anyone finds what I am talking about unclear please ask
> questions, I
> > will be happy to try to explain in more detail.
> I'm looking forward working with all of you on this.
Likewise!
thanks
david jencks
>
> I've good hopes we can have the security integration with Geronimo
> working soon
> and I expect the Jetspeed security implementation to improve from that
> as well.
>
> Regards, Ate
>
> >
> > Many 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: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by David Jencks <da...@yahoo.com>.
On Dec 23, 2005, at 6:09 AM, Ate Douma wrote:
> David Jencks wrote:
> > At Apachecon some Jetspeed and Geronimo committers got together and
> > discussed Jetspeed 2 - Geronimo security integration a bit. Here's
> > what I remember: please chime in if you remember more/differently.
> >
> > People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
> > David Jencks and ???
> >
> > 1. Jetspeed in tomcat is currently creating a separate "jetspeed
> > subject" because it isn't clear how to get the JAAS subject that
> tomcat
> > creates for use in jetspeed security.
> Correct.
>
>
> > In geronimo we create a special
> > Principal that has a reference to the Subject
> (JAASTomcatPrincipal).
> > Probably Jetspeed can use the same idea in Tomcat to get the JAAS
> > subject and avoid the "fake login".
> For Tomcat (and probably Jetty too) we can look into using that
> solution.
> But: if we do that, we will also need to have a handling in place for
> other web/app servers like JBoss, WebSphere etc.
> Because we currently use our own "fake" Subject throughout, we need
> to make
> sure replacing that with the "real" Subject will provide the same/
> similar
> features we now rely on.
I am speculating, but I think one possible outcome (possibly for the
distant future) might be something like:
-jetspeed only provides security on platforms with a jacc implementation
-jetspeed uses the jacc mechanism to insert and modify the role-
permission mappings
-jetspeed provides, as one choice, a JAAS login module that produces
jetspeed-friendly principals for easy role-principal mapping
-jetspeed relies on the jacc implementation for the actual role-
principal mapping.
I haven't investigated but I would hope that this would let the jacc
framework implement all or most of isUserInRole.
>
> >
> > 2. IIUC correctly jetspeed security currently requires a login
> module
> > to use specific principal classes, and there is a direct mapping
> > between instances of these classes and jetspeed portal/portlet
> > permissions. This is not very j2ee-like, at least as geronimo
> > interprets it :-)
> > In particular it seems excessively restrictive to
> > require the use of specific principal classes. On the other hand
> > jetspeed implements an on-the-fly permissions-changing facility that
> > will take some work to fit into a jacc-like structure.
> To be precise: jetspeed provides an api (and portlets) to map role,
> group
> and user principals to each other. This is on-the-fly, but requires
> a subject
> (user principal) to (re)login for new (or removed) mappings to get
> into effect.
> The same can be done with (portal/portlet) permissions assignments
> to principals,
> *but doesn't imply it*.
> Roles (nor groups) require any (explicit) permission but can be
> used independent.
My understanding of this is that it requires use of a jetspeed-
specific login module or at least one that adds jetspeed-specific
principals to the JAAS Subject. I suspect this may not be
appropriate for all deployments, such as ones using an existing ldap
system.
>
> The Portlet API defines *no* requirements/restrictions/permission
> for role usage.
> It leaves it to the container/portlet developer how to use it and
> it only
> defines a request.isUserInRole('roleName') api, nothing more.
I know nothing about the plans for the portlet 2.0 spec, but I wonder
if defining a set of portlet permissions and a role-permission
mapping analogous to those for web apps and ejbs would be a
reasonable goal.
>
> Reading the jacc specification (I'm just getting into it so bear
> with me if I'm
> missing the finer details of the spec) it seems as it defines a
> role as (only) a
> named set of permissions. I'm not sure we might have a definition
> problem here (too).
I think the jacc spec takes a quite different view than the current
jetspeed implementation. I would say that a (jacc) role is an object
scoped to a j2ee application whose only attribute is its name. The
web and ejb spec deployment descriptors define (abstractly, and as
specified in detail in the jacc spec) a role to permissions mapping.
The jacc spec does not indicate or specify the Subject/Principal to
role mapping. It does specify an api whereby the algorithm that
determines permissions can use the invocation information (request
for web apps, ejb method name and args for ejbs, etc) in the
authorization decision. Currently the Geronimo implementation
defines a static role-permissions mapping that can only be changed at
deployment time. This information from the geronimo plan is combined
with the spec-dd specified role-permissions mapping to make a
principal-permissions map which is actually used in authorization
decisions. Geronimo is not currently using the invocation
information in authorization decisions.
IIUC the jetspeed view of a role is an instance of a specific
Principal class. While this simplifies some parts of security setup,
I think it will cause problems in some environments.
>
> > Here is one way
> > to proceed that I tried to explain and I think got general
> agreement
> > that it deserved at least further consideration:
> Yes
>
> >
> > a. In analogy to the role-permissions mapping specified for web apps
> > and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
> > (presumably xml) jetspeed specific deployment descriptor. With a
> > suitable deployer this can be fed into a jacc-compliant app
> server: in
> > geronimo this can be fed into PolicyConfigurationGeneric. In
> j2ee such
> > a mapping is static, part of the original deployment descriptor,
> and
> > cannot be changed without redeploying the app. I'm inclined to
> think
> > that such a restriction may also work for jetspeed
> I'm afraid I'm not yet convinced of that yet: this needs further
> investigation.
>
> > but don't have
> > enough info for my opinion to count for much. I think implementing
> > this as a first step would be a good idea.
> Agreed, for a first test setup yes.
> But we require support for dynamically changing role/permission
> assignments
> or restrictions on newly created pages for instance (which also can
> be done
> dynamically from with Jetspeed) in a releasable version.
I'd like to understand a lot more about the use cases here, and if
there are any docs please point me to them :-) Some of my questions
are:
- do the portal/portlet permissions apply to the portal app or the
portlet app deployed in the portal?
- Where do new portlet pages come from (and are they portlet pages or
portal pages)? Can they be added to a running system or do they
require (re)deployment of a portlet application? Are they additional
portlets or servlets that should be represented in the portlet.xml or
web.xml deployment descriptor or are they representable as additional
parameters to an existing portlet or servlet?
- In the existing jetspeed implementation, what kind of
"transactional" behavior is there to allow applying a set of security
changes at once?
- Are the contents of the request needed to make authorization
decisions?
> >
> > b. Use the existing geronimo specific role-principal mapping to
> connect
> > the principals created by an arbitrary login module with the
> roles set
> > up in (a). This would result in jetspeed security being integrated
> > into the existing geronimo jacc security framework. However, it
> would
> > not immediately result in being able to change permissions without
> > redeploying the application.
> >
> > c. Investigate how to make this more dynamic. One possibility is to
> > simply use the jacc facilities, which involve opening the policy
> > configuration (at which point it is taken out of service and no
> > requests can get through), modifying it, and committing the
> changes (at
> > which time it is put back into service and the new policy rules
> are in
> > force). It is not entirely clear to me if the requests made
> while the
> > configuration is open can be made to wait or if they must be
> refused.
> > I do think that some kind of transactional change mechanism is
> needed
> > so that many changes can be made in one operation.
> Sounds good a good summary of what we've discussed so far at
> ApacheCon.
>
> >
> > If anyone finds what I am talking about unclear please ask
> questions, I
> > will be happy to try to explain in more detail.
> I'm looking forward working with all of you on this.
Likewise!
thanks
david jencks
>
> I've good hopes we can have the security integration with Geronimo
> working soon
> and I expect the Jetspeed security implementation to improve from that
> as well.
>
> Regards, Ate
>
> >
> > Many 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: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
> At Apachecon some Jetspeed and Geronimo committers got together and
> discussed Jetspeed 2 - Geronimo security integration a bit. Here's
> what I remember: please chime in if you remember more/differently.
>
> People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
> David Jencks and ???
>
> 1. Jetspeed in tomcat is currently creating a separate "jetspeed
> subject" because it isn't clear how to get the JAAS subject that tomcat
> creates for use in jetspeed security.
Correct.
> In geronimo we create a special
> Principal that has a reference to the Subject (JAASTomcatPrincipal).
> Probably Jetspeed can use the same idea in Tomcat to get the JAAS
> subject and avoid the "fake login".
For Tomcat (and probably Jetty too) we can look into using that solution.
But: if we do that, we will also need to have a handling in place for
other web/app servers like JBoss, WebSphere etc.
Because we currently use our own "fake" Subject throughout, we need to make
sure replacing that with the "real" Subject will provide the same/similar
features we now rely on.
>
> 2. IIUC correctly jetspeed security currently requires a login module
> to use specific principal classes, and there is a direct mapping
> between instances of these classes and jetspeed portal/portlet
> permissions. This is not very j2ee-like, at least as geronimo
> interprets it :-)
> In particular it seems excessively restrictive to
> require the use of specific principal classes. On the other hand
> jetspeed implements an on-the-fly permissions-changing facility that
> will take some work to fit into a jacc-like structure.
To be precise: jetspeed provides an api (and portlets) to map role, group
and user principals to each other. This is on-the-fly, but requires a subject
(user principal) to (re)login for new (or removed) mappings to get into effect.
The same can be done with (portal/portlet) permissions assignments to principals,
*but doesn't imply it*.
Roles (nor groups) require any (explicit) permission but can be used independent.
The Portlet API defines *no* requirements/restrictions/permission for role usage.
It leaves it to the container/portlet developer how to use it and it only
defines a request.isUserInRole('roleName') api, nothing more.
Reading the jacc specification (I'm just getting into it so bear with me if I'm
missing the finer details of the spec) it seems as it defines a role as (only) a
named set of permissions. I'm not sure we might have a definition problem here (too).
> Here is one way
> to proceed that I tried to explain and I think got general agreement
> that it deserved at least further consideration:
Yes
>
> a. In analogy to the role-permissions mapping specified for web apps
> and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
> (presumably xml) jetspeed specific deployment descriptor. With a
> suitable deployer this can be fed into a jacc-compliant app server: in
> geronimo this can be fed into PolicyConfigurationGeneric. In j2ee such
> a mapping is static, part of the original deployment descriptor, and
> cannot be changed without redeploying the app. I'm inclined to think
> that such a restriction may also work for jetspeed
I'm afraid I'm not yet convinced of that yet: this needs further investigation.
> but don't have
> enough info for my opinion to count for much. I think implementing
> this as a first step would be a good idea.
Agreed, for a first test setup yes.
But we require support for dynamically changing role/permission assignments
or restrictions on newly created pages for instance (which also can be done
dynamically from with Jetspeed) in a releasable version.
>
> b. Use the existing geronimo specific role-principal mapping to connect
> the principals created by an arbitrary login module with the roles set
> up in (a). This would result in jetspeed security being integrated
> into the existing geronimo jacc security framework. However, it would
> not immediately result in being able to change permissions without
> redeploying the application.
>
> c. Investigate how to make this more dynamic. One possibility is to
> simply use the jacc facilities, which involve opening the policy
> configuration (at which point it is taken out of service and no
> requests can get through), modifying it, and committing the changes (at
> which time it is put back into service and the new policy rules are in
> force). It is not entirely clear to me if the requests made while the
> configuration is open can be made to wait or if they must be refused.
> I do think that some kind of transactional change mechanism is needed
> so that many changes can be made in one operation.
Sounds good a good summary of what we've discussed so far at ApacheCon.
>
> If anyone finds what I am talking about unclear please ask questions, I
> will be happy to try to explain in more detail.
I'm looking forward working with all of you on this.
I've good hopes we can have the security integration with Geronimo working soon
and I expect the Jetspeed security implementation to improve from that
as well.
Regards, Ate
>
> Many 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: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
> At Apachecon some Jetspeed and Geronimo committers got together and
> discussed Jetspeed 2 - Geronimo security integration a bit. Here's
> what I remember: please chime in if you remember more/differently.
>
> People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
> David Jencks and ???
>
> 1. Jetspeed in tomcat is currently creating a separate "jetspeed
> subject" because it isn't clear how to get the JAAS subject that tomcat
> creates for use in jetspeed security.
Correct.
> In geronimo we create a special
> Principal that has a reference to the Subject (JAASTomcatPrincipal).
> Probably Jetspeed can use the same idea in Tomcat to get the JAAS
> subject and avoid the "fake login".
For Tomcat (and probably Jetty too) we can look into using that solution.
But: if we do that, we will also need to have a handling in place for
other web/app servers like JBoss, WebSphere etc.
Because we currently use our own "fake" Subject throughout, we need to make
sure replacing that with the "real" Subject will provide the same/similar
features we now rely on.
>
> 2. IIUC correctly jetspeed security currently requires a login module
> to use specific principal classes, and there is a direct mapping
> between instances of these classes and jetspeed portal/portlet
> permissions. This is not very j2ee-like, at least as geronimo
> interprets it :-)
> In particular it seems excessively restrictive to
> require the use of specific principal classes. On the other hand
> jetspeed implements an on-the-fly permissions-changing facility that
> will take some work to fit into a jacc-like structure.
To be precise: jetspeed provides an api (and portlets) to map role, group
and user principals to each other. This is on-the-fly, but requires a subject
(user principal) to (re)login for new (or removed) mappings to get into effect.
The same can be done with (portal/portlet) permissions assignments to principals,
*but doesn't imply it*.
Roles (nor groups) require any (explicit) permission but can be used independent.
The Portlet API defines *no* requirements/restrictions/permission for role usage.
It leaves it to the container/portlet developer how to use it and it only
defines a request.isUserInRole('roleName') api, nothing more.
Reading the jacc specification (I'm just getting into it so bear with me if I'm
missing the finer details of the spec) it seems as it defines a role as (only) a
named set of permissions. I'm not sure we might have a definition problem here (too).
> Here is one way
> to proceed that I tried to explain and I think got general agreement
> that it deserved at least further consideration:
Yes
>
> a. In analogy to the role-permissions mapping specified for web apps
> and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
> (presumably xml) jetspeed specific deployment descriptor. With a
> suitable deployer this can be fed into a jacc-compliant app server: in
> geronimo this can be fed into PolicyConfigurationGeneric. In j2ee such
> a mapping is static, part of the original deployment descriptor, and
> cannot be changed without redeploying the app. I'm inclined to think
> that such a restriction may also work for jetspeed
I'm afraid I'm not yet convinced of that yet: this needs further investigation.
> but don't have
> enough info for my opinion to count for much. I think implementing
> this as a first step would be a good idea.
Agreed, for a first test setup yes.
But we require support for dynamically changing role/permission assignments
or restrictions on newly created pages for instance (which also can be done
dynamically from with Jetspeed) in a releasable version.
>
> b. Use the existing geronimo specific role-principal mapping to connect
> the principals created by an arbitrary login module with the roles set
> up in (a). This would result in jetspeed security being integrated
> into the existing geronimo jacc security framework. However, it would
> not immediately result in being able to change permissions without
> redeploying the application.
>
> c. Investigate how to make this more dynamic. One possibility is to
> simply use the jacc facilities, which involve opening the policy
> configuration (at which point it is taken out of service and no
> requests can get through), modifying it, and committing the changes (at
> which time it is put back into service and the new policy rules are in
> force). It is not entirely clear to me if the requests made while the
> configuration is open can be made to wait or if they must be refused.
> I do think that some kind of transactional change mechanism is needed
> so that many changes can be made in one operation.
Sounds good a good summary of what we've discussed so far at ApacheCon.
>
> If anyone finds what I am talking about unclear please ask questions, I
> will be happy to try to explain in more detail.
I'm looking forward working with all of you on this.
I've good hopes we can have the security integration with Geronimo working soon
and I expect the Jetspeed security implementation to improve from that
as well.
Regards, Ate
>
> Many 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: Jetspeed 2 - Geronimo security integration (from apachecon)
Posted by Jian Liao <no...@gmail.com>.
On 12/23/05, David Jencks <da...@yahoo.com> wrote:
>
> At Apachecon some Jetspeed and Geronimo committers got together and
> discussed Jetspeed 2 - Geronimo security integration a bit. Here's
> what I remember: please chime in if you remember more/differently.
>
> People: David Sean Taylor, Ate Douma, Randy Watler, Alan Cabrera,
> David Jencks and ???
>
> 1. Jetspeed in tomcat is currently creating a separate "jetspeed
> subject" because it isn't clear how to get the JAAS subject that
> tomcat creates for use in jetspeed security. In geronimo we create a
> special Principal that has a reference to the Subject
> (JAASTomcatPrincipal). Probably Jetspeed can use the same idea in
> Tomcat to get the JAAS subject and avoid the "fake login".
This could solve *JS2-238 <http://issues.apache.org/jira/browse/JS2-238>*,
great!*
*
2. IIUC correctly jetspeed security currently requires a login module
> to use specific principal classes, and there is a direct mapping
> between instances of these classes and jetspeed portal/portlet
> permissions. This is not very j2ee-like, at least as geronimo
> interprets it :-) In particular it seems excessively restrictive to
> require the use of specific principal classes. On the other hand
> jetspeed implements an on-the-fly permissions-changing facility that
> will take some work to fit into a jacc-like structure. Here is one
> way to proceed that I tried to explain and I think got general
> agreement that it deserved at least further consideration:
>
> a. In analogy to the role-permissions mapping specified for web apps
> and ejbs, set up a role-to-jetspeed-portlet-permissions mapping in a
> (presumably xml) jetspeed specific deployment descriptor. With a
> suitable deployer this can be fed into a jacc-compliant app server:
> in geronimo this can be fed into PolicyConfigurationGeneric. In j2ee
> such a mapping is static, part of the original deployment descriptor,
> and cannot be changed without redeploying the app. I'm inclined to
> think that such a restriction may also work for jetspeed but don't
> have enough info for my opinion to count for much. I think
> implementing this as a first step would be a good idea.
>
> b. Use the existing geronimo specific role-principal mapping to
> connect the principals created by an arbitrary login module with the
> roles set up in (a). This would result in jetspeed security being
> integrated into the existing geronimo jacc security framework.
> However, it would not immediately result in being able to change
> permissions without redeploying the application.
>
> c. Investigate how to make this more dynamic. One possibility is to
> simply use the jacc facilities, which involve opening the policy
> configuration (at which point it is taken out of service and no
> requests can get through), modifying it, and committing the changes
> (at which time it is put back into service and the new policy rules
> are in force). It is not entirely clear to me if the requests made
> while the configuration is open can be made to wait or if they must
> be refused. I do think that some kind of transactional change
> mechanism is needed so that many changes can be made in one operation.
I am wondering when will 2-a come true? I'm eager to see that ASAP.
If anyone finds what I am talking about unclear please ask questions,
> I will be happy to try to explain in more detail.
>
> Many thanks,
> david jencks
>
>