You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Phillip Rhodes <ph...@rhoderunner.com> on 2001/12/04 23:14:11 UTC
Re: JS Groups-Roles-Permissions
Hey I am ready to get going on the enhanced security model.
I am going to read the proposed security model referred to below. Should
we do the security changes within the context of the turbine project, or in
jetspeed?
Who else is interested in participating? Should we take future discussions
off-line?
Ripping to go!
At 09:28 AM 11/28/2001 -0800, David Sean Taylor wrote:
>We did some work on the Jetspeed security features a while back:
>- added role-based security for registry entries
>- security maintenance portlets for users, roles, groups
>- permission checks to access portlets
>
>One thing I personally find outstanding is that we could add better secured
>access to psml pages.
>
>Others on the list have had proposals about how security 'should' work, but
>its often difficult to find a consensus. The role-based security approach
>based on the turbine security model has some loopholes. I believe a better
>security model would be one like the one described in the security proposal
>by the SAP developers in the cvs under /proposals/0004.txt.
>(I just read that SAP bought TopTier - a commercial portal )
>however the proposed security model would take a larger development effort.
>
>----- Original Message -----
>From: "ICM S Op Guest 5" <IC...@icn.siemens.de>
>To: "Jetspeed Users List" <je...@jakarta.apache.org>
>Sent: Wednesday, November 28, 2001 7:55 AM
>Subject: JS Groups-Roles-Permissions
>
>
> > Hi,
> >
> > is there anybody working on these?
> > Is there a scheme or a structure available which shows how this is
>planned/should be implemented for/into jetspeed?
> >
> > Andreas
> >
> > --
> > To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
>
>
>
>--
>To unsubscribe,
>e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JS Groups-Roles-Permissions
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>>We need a JDBC implementation and an LDAP implementation
>>
>
>Yes, agreed.
>
>>What Object Relational layer (if any) are we going to use for
>>the JDBC
>>implementation. Some choices include castor, village, Torque, the
>>JCorporate, ofbiz, and dozens of others.
>>
>
>Torque is probably a good choice.
>Check the Turbine mailing list. Someone there was working on a LDAP adapter,
>not sure of the state of that.
>
I checked. It can be used for authentication, but the "save" methods are
not implemented (both in turbine-2 and 3). Thus, if we use it, we would
have no functional user.save() for session objects.
>
>>Or should we do it via the DAO pattern?
>>
>
>Torque provides a data access layer.
>
>>For the object model,
>>Here is what I think we need to do
>>
>>1) Hierarchical groups and roles
>>2) Users are associated to groups and to roles
>>3) Groups can be associated to users and to roles
>>
>>
>>TO DO:
>>Object Model
>>Database scripts
>>
>
>Generate them with Torque.
>
>>O/R Decision (DAO vs Castor, Torque, etc)
>>
>
>My vote is Torque.
>
This even after your fights? ;)
BTW. THere is something I did not like about how we implemented groups.
Turbine has a "DEFAULT_GROUP" concept. The group is called "global".
When you don't specify a group, this is the one that Turbine will check.
We have used a Jetspeed group as default. No global page under groups. I
think we should revise this, as the global group name is hardwired into
Turbine.
>
>>Web application for delegated administration
>>Web application for a reference implementation (a how-to use
>>this thing)
>>
>
>I would like to see this written with portlets.
>
Me too. Ideally beans put into a tool for template access.
>
>>
>>
>>Note:
>>I found it very good to use a de-normalized table for the
>>storage of groups
>>and roles. We should use a groupflat and roleflat table for better
>>performance. Oracle iPortal does it!
>>
>
>Could you show a simple table definition?
>
>>I really need to get this up and running. Where is this
>>thing? Does it
>>need a project lead? I am more than willing to drive this
>>baby to completion.
>>
>
>Have you read this yet:
>
>http://jakarta.apache.org/site/getinvolved.html
>http://jakarta.apache.org/site/guidelines.html
>
>If you'd like to start working on this project from within Jetspeed, make a
>formal proposal and the committers will then vote on it. You may also want
>to run this idea past the Turbine group, since in my opinion it, your
>proposed security system is similiar to Turbine security. Perhaps you could
>make a proposal to the Turbine developers list to improve the current
>Turbine security. Then the all Turbine apps, Jetspeed included, will benefit
>from it.
>
>David
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JS Groups-Roles-Permissions
Posted by David Sean Taylor <da...@bluesunrise.com>.
> We need a JDBC implementation and an LDAP implementation
>
Yes, agreed.
> What Object Relational layer (if any) are we going to use for
> the JDBC
> implementation. Some choices include castor, village, Torque, the
> JCorporate, ofbiz, and dozens of others.
>
Torque is probably a good choice.
Check the Turbine mailing list. Someone there was working on a LDAP adapter,
not sure of the state of that.
> Or should we do it via the DAO pattern?
>
Torque provides a data access layer.
> For the object model,
> Here is what I think we need to do
>
> 1) Hierarchical groups and roles
> 2) Users are associated to groups and to roles
> 3) Groups can be associated to users and to roles
>
>
> TO DO:
> Object Model
> Database scripts
Generate them with Torque.
> O/R Decision (DAO vs Castor, Torque, etc)
My vote is Torque.
> Web application for delegated administration
> Web application for a reference implementation (a how-to use
> this thing)
I would like to see this written with portlets.
>
>
>
> Note:
> I found it very good to use a de-normalized table for the
> storage of groups
> and roles. We should use a groupflat and roleflat table for better
> performance. Oracle iPortal does it!
>
Could you show a simple table definition?
>
> I really need to get this up and running. Where is this
> thing? Does it
> need a project lead? I am more than willing to drive this
> baby to completion.
>
Have you read this yet:
http://jakarta.apache.org/site/getinvolved.html
http://jakarta.apache.org/site/guidelines.html
If you'd like to start working on this project from within Jetspeed, make a
formal proposal and the committers will then vote on it. You may also want
to run this idea past the Turbine group, since in my opinion it, your
proposed security system is similiar to Turbine security. Perhaps you could
make a proposal to the Turbine developers list to improve the current
Turbine security. Then the all Turbine apps, Jetspeed included, will benefit
from it.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JS Groups-Roles-Permissions
Posted by Phillip Rhodes <rh...@yahoo.com>.
I have a few questions about our new security model implementation....
We need a JDBC implementation and an LDAP implementation
What Object Relational layer (if any) are we going to use for the JDBC
implementation. Some choices include castor, village, Torque, the
JCorporate, ofbiz, and dozens of others.
Or should we do it via the DAO pattern?
For the object model,
Here is what I think we need to do
1) Hierarchical groups and roles
2) Users are associated to groups and to roles
3) Groups can be associated to users and to roles
TO DO:
Object Model
Database scripts
O/R Decision (DAO vs Castor, Torque, etc)
Web application for delegated administration
Web application for a reference implementation (a how-to use this thing)
Note:
I found it very good to use a de-normalized table for the storage of groups
and roles. We should use a groupflat and roleflat table for better
performance. Oracle iPortal does it!
AccessControlItems are associated to (a role) or (a role and a group) or (a
user and a role)
An AccessControlItem is an object that encapsulates the Permission object,
a target and authorized party (a role) or (a role and a group) or (a user
and a role).
I hope you are not confused by having to specify a ROLE and GROUP for an
accesscontrolitem.
I thought about this for months. Let me explain.
In a B2b portal, it is not enough to know that a user is in a particular
role (request.isCallerInRole())
Let me explain.
How would you associate an Permission object that represented a customer id
to a role? Since the "Customer" role is shared for the million customers
you have, you can not associate it to just the Role. If you user is an
individual, this would be a case for a AccessControlItem to be a tuple of
Permission, User, and Role
However, in a B2B context, where many individuals may be associated to the
same organizational unit, you would use a tuple of Permission, Group, Role
to represent an accesscontrolitem
In many more simplistic security models, attributes such as customer id as
just stored as attributes of the group. This is bad....Roles are used to
factor out the common authorizations across the given set.
I really need to get this up and running. Where is this thing? Does it
need a project lead? I am more than willing to drive this baby to completion.
Phillip
At 04:49 PM 12/4/2001 -0800, David Sean Taylor wrote:
>Hi Phillip.
>
>I don't know if you are subscribed to the Jetspeed Developer list or not, so
>Im cross-posting this email from today, it seems that some others are also
>interested in working on security. I suggest that you join the developers
>list and we can discuss it there.
>
>David
>
>Included from Jetspeed Dev list - Tuesday, Dec. 4:
>
>Hi,
>
>because there's nobody working on GRP's we would like to implement it in our
>Jetspeed Version.
>We would also like to offer these upcoming changes to the jakarta team - for
>that, it would be fine if you could comment our proposal.
>
>Thanks,
>
>Andreas, Rony
>
>
>
>Groups/Roles/Permissions Implementation (ICM)
>---------------------------------------------
>Groups, roles and permissions implementation in the Jetspeed portal is for
>incorporating user authentication and authorization. User profiling will
>also be enable by the same.
>
>Overview of the portal scenario
>-------------------------------
>Every user who registers with the portal will belong to a particular group
>or a default group. Every Group will have access to a set of portlets which
>would be a subset of all the available portlets. The user would be assigned
>some role which would have a set of permissions.
>
>Implementation
>--------------
>Administrator will be inserted into the database directly through scripts.
>The tables in which data would be inserted to create the administrator are
>TURBINE_USER and TURBINE_USER_GROUP_ROLE.
>The administrator will create roles and map the permissions with role. The
>role will then be assigned to users.
>
>The administrator will have the authority to create new groups, add, modify
>and delete portlets which would be accessed by this group.
>
>Users would be created by the administrator in the following way.
>The administrator will insert predefined user information into the database
>with group and role for the particular user. The user information will be
>available to the administrator from a reliable source. This information will
>comprise of part of the TURBINE_USER table data. When the user registers
>with the portal this table will be looked up if the user data is already
>available.
>
>If the predefined user data is available (would be put into the
>TurbineResource.properties file regarding which predefined parameter will be
>checked for e.g. Email ID) the user will be registered with the predefined
>group and a notification will be send to the user via email which will
>consist of authentication key and the group he belongs to.
>If the user is not available in the predefined user database table he is
>registered as a default user and a notification would be send via email
>regarding his authentication key.
>
>In the TurbineResource.properties file column attributes i.e. what would be
>the data looked up for predefined user, default group name and default role
>will be set as part of configuration settings.
>
>Roles would be added to the valid users with permissions. The administrator
>will have the privilege to grant and revoke roles to/from the users.
>
>To implement the portlets registered per group we create a file called
>"groupportlet.properties" which would contain the group name and all the
>portlets available for that group. This would be created by the
>administrator.
>
>During startup of the system. The "groupportlet.properties" file would be
>read into the data structure and compared with the xreg files data structure
>to find if all the portlets assigned to groups are actually available in the
>system. If not the " groupportlet.properties" file is amended and the
>portlets assigned to groups but not available are removed from the file.
>
>When the user logs into the system his psml file is verified with the group
>portlets available in the data structure to check all the portlets that user
>has in his profile are available, if there is a discrepancy the profile data
>structure is changed and amended into the psml file when user logs out or
>changes customization profile.
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>----- Original Message -----
>From: "Phillip Rhodes" <ph...@rhoderunner.com>
>To: "Jetspeed Users List" <je...@jakarta.apache.org>; "Jetspeed
>Users List" <je...@jakarta.apache.org>
>Sent: Tuesday, December 04, 2001 2:14 PM
>Subject: Re: JS Groups-Roles-Permissions
>
>
> >
> > Hey I am ready to get going on the enhanced security model.
> >
> > I am going to read the proposed security model referred to below. Should
> > we do the security changes within the context of the turbine project, or
>in
> > jetspeed?
> >
> > Who else is interested in participating? Should we take future
>discussions
> > off-line?
> >
> > Ripping to go!
> >
> >
> >
> > At 09:28 AM 11/28/2001 -0800, David Sean Taylor wrote:
> > >We did some work on the Jetspeed security features a while back:
> > >- added role-based security for registry entries
> > >- security maintenance portlets for users, roles, groups
> > >- permission checks to access portlets
> > >
> > >One thing I personally find outstanding is that we could add better
>secured
> > >access to psml pages.
> > >
> > >Others on the list have had proposals about how security 'should' work,
>but
> > >its often difficult to find a consensus. The role-based security approach
> > >based on the turbine security model has some loopholes. I believe a
>better
> > >security model would be one like the one described in the security
>proposal
> > >by the SAP developers in the cvs under /proposals/0004.txt.
> > >(I just read that SAP bought TopTier - a commercial portal )
> > >however the proposed security model would take a larger development
>effort.
> > >
> > >----- Original Message -----
> > >From: "ICM S Op Guest 5" <IC...@icn.siemens.de>
> > >To: "Jetspeed Users List" <je...@jakarta.apache.org>
> > >Sent: Wednesday, November 28, 2001 7:55 AM
> > >Subject: JS Groups-Roles-Permissions
> > >
> > >
> > > > Hi,
> > > >
> > > > is there anybody working on these?
> > > > Is there a scheme or a structure available which shows how this is
> > >planned/should be implemented for/into jetspeed?
> > > >
> > > > Andreas
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > ><ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > ><ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe,
> > >e-mail: <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
>
>
>
>--
>To unsubscribe,
>e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JS Groups-Roles-Permissions
Posted by David Sean Taylor <da...@bluesunrise.com>.
Hi Phillip.
I don't know if you are subscribed to the Jetspeed Developer list or not, so
Im cross-posting this email from today, it seems that some others are also
interested in working on security. I suggest that you join the developers
list and we can discuss it there.
David
Included from Jetspeed Dev list - Tuesday, Dec. 4:
Hi,
because there's nobody working on GRP's we would like to implement it in our
Jetspeed Version.
We would also like to offer these upcoming changes to the jakarta team - for
that, it would be fine if you could comment our proposal.
Thanks,
Andreas, Rony
Groups/Roles/Permissions Implementation (ICM)
---------------------------------------------
Groups, roles and permissions implementation in the Jetspeed portal is for
incorporating user authentication and authorization. User profiling will
also be enable by the same.
Overview of the portal scenario
-------------------------------
Every user who registers with the portal will belong to a particular group
or a default group. Every Group will have access to a set of portlets which
would be a subset of all the available portlets. The user would be assigned
some role which would have a set of permissions.
Implementation
--------------
Administrator will be inserted into the database directly through scripts.
The tables in which data would be inserted to create the administrator are
TURBINE_USER and TURBINE_USER_GROUP_ROLE.
The administrator will create roles and map the permissions with role. The
role will then be assigned to users.
The administrator will have the authority to create new groups, add, modify
and delete portlets which would be accessed by this group.
Users would be created by the administrator in the following way.
The administrator will insert predefined user information into the database
with group and role for the particular user. The user information will be
available to the administrator from a reliable source. This information will
comprise of part of the TURBINE_USER table data. When the user registers
with the portal this table will be looked up if the user data is already
available.
If the predefined user data is available (would be put into the
TurbineResource.properties file regarding which predefined parameter will be
checked for e.g. Email ID) the user will be registered with the predefined
group and a notification will be send to the user via email which will
consist of authentication key and the group he belongs to.
If the user is not available in the predefined user database table he is
registered as a default user and a notification would be send via email
regarding his authentication key.
In the TurbineResource.properties file column attributes i.e. what would be
the data looked up for predefined user, default group name and default role
will be set as part of configuration settings.
Roles would be added to the valid users with permissions. The administrator
will have the privilege to grant and revoke roles to/from the users.
To implement the portlets registered per group we create a file called
"groupportlet.properties" which would contain the group name and all the
portlets available for that group. This would be created by the
administrator.
During startup of the system. The "groupportlet.properties" file would be
read into the data structure and compared with the xreg files data structure
to find if all the portlets assigned to groups are actually available in the
system. If not the " groupportlet.properties" file is amended and the
portlets assigned to groups but not available are removed from the file.
When the user logs into the system his psml file is verified with the group
portlets available in the data structure to check all the portlets that user
has in his profile are available, if there is a discrepancy the profile data
structure is changed and amended into the psml file when user logs out or
changes customization profile.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
----- Original Message -----
From: "Phillip Rhodes" <ph...@rhoderunner.com>
To: "Jetspeed Users List" <je...@jakarta.apache.org>; "Jetspeed
Users List" <je...@jakarta.apache.org>
Sent: Tuesday, December 04, 2001 2:14 PM
Subject: Re: JS Groups-Roles-Permissions
>
> Hey I am ready to get going on the enhanced security model.
>
> I am going to read the proposed security model referred to below. Should
> we do the security changes within the context of the turbine project, or
in
> jetspeed?
>
> Who else is interested in participating? Should we take future
discussions
> off-line?
>
> Ripping to go!
>
>
>
> At 09:28 AM 11/28/2001 -0800, David Sean Taylor wrote:
> >We did some work on the Jetspeed security features a while back:
> >- added role-based security for registry entries
> >- security maintenance portlets for users, roles, groups
> >- permission checks to access portlets
> >
> >One thing I personally find outstanding is that we could add better
secured
> >access to psml pages.
> >
> >Others on the list have had proposals about how security 'should' work,
but
> >its often difficult to find a consensus. The role-based security approach
> >based on the turbine security model has some loopholes. I believe a
better
> >security model would be one like the one described in the security
proposal
> >by the SAP developers in the cvs under /proposals/0004.txt.
> >(I just read that SAP bought TopTier - a commercial portal )
> >however the proposed security model would take a larger development
effort.
> >
> >----- Original Message -----
> >From: "ICM S Op Guest 5" <IC...@icn.siemens.de>
> >To: "Jetspeed Users List" <je...@jakarta.apache.org>
> >Sent: Wednesday, November 28, 2001 7:55 AM
> >Subject: JS Groups-Roles-Permissions
> >
> >
> > > Hi,
> > >
> > > is there anybody working on these?
> > > Is there a scheme or a structure available which shows how this is
> >planned/should be implemented for/into jetspeed?
> > >
> > > Andreas
> > >
> > > --
> > > To unsubscribe, e-mail:
> ><ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> >--
> >To unsubscribe,
> >e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> ><ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: JS Groups-Roles-Permissions
Posted by Andreas Kempf <An...@gmx.net>.
Hi Philip,
I am working on a security model too.
We just finished a proposal for our needs. If some others might find it
usefull I am sure we can offer it for jetspeed. We are also interested in
improvements and different point of views.
Our current proposal you can find in Jetspeed-Developer Newsgroup.
I can also email it to you tomorrow (when I am back in office).
Andreas K.
-----Ursprungliche Nachricht-----
Von: Phillip Rhodes [mailto:phillip@rhoderunner.com]
Gesendet: Dienstag, 4. Dezember 2001 23:14
An: Jetspeed Users List; Jetspeed Users List
Betreff: Re: JS Groups-Roles-Permissions
Hey I am ready to get going on the enhanced security model.
I am going to read the proposed security model referred to below. Should
we do the security changes within the context of the turbine project, or in
jetspeed?
Who else is interested in participating? Should we take future discussions
off-line?
Ripping to go!
At 09:28 AM 11/28/2001 -0800, David Sean Taylor wrote:
>We did some work on the Jetspeed security features a while back:
>- added role-based security for registry entries
>- security maintenance portlets for users, roles, groups
>- permission checks to access portlets
>
>One thing I personally find outstanding is that we could add better secured
>access to psml pages.
>
>Others on the list have had proposals about how security 'should' work, but
>its often difficult to find a consensus. The role-based security approach
>based on the turbine security model has some loopholes. I believe a better
>security model would be one like the one described in the security proposal
>by the SAP developers in the cvs under /proposals/0004.txt.
>(I just read that SAP bought TopTier - a commercial portal )
>however the proposed security model would take a larger development effort.
>
>----- Original Message -----
>From: "ICM S Op Guest 5" <IC...@icn.siemens.de>
>To: "Jetspeed Users List" <je...@jakarta.apache.org>
>Sent: Wednesday, November 28, 2001 7:55 AM
>Subject: JS Groups-Roles-Permissions
>
>
> > Hi,
> >
> > is there anybody working on these?
> > Is there a scheme or a structure available which shows how this is
>planned/should be implemented for/into jetspeed?
> >
> > Andreas
> >
> > --
> > To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
>
>
>
>--
>To unsubscribe,
>e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>