portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject Re: JS Groups-Roles-Permissions
Date Wed, 05 Dec 2001 00:49:53 GMT
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.


Included from Jetspeed Dev list - Tuesday, Dec. 4:


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.


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.

Administrator will be inserted into the database directly through scripts.
The tables in which data would be inserted to create the administrator are
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

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

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:
For additional commands, e-mail:

----- Original Message -----
From: "Phillip Rhodes" <phillip@rhoderunner.com>
To: "Jetspeed Users List" <jetspeed-user@jakarta.apache.org>; "Jetspeed
Users List" <jetspeed-user@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
> jetspeed?
> Who else is interested in participating?  Should we take future
> 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
> >access to psml pages.
> >
> >Others on the list have had proposals about how security 'should' work,
> >its often difficult to find a consensus. The role-based security approach
> >based on the turbine security model has some loopholes. I believe a
> >security model would be one like the one described in the security
> >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
> >
> >----- Original Message -----
> >From: "ICM S Op Guest 5" <ICM-S-OP.guest-5@icn.siemens.de>
> >To: "Jetspeed Users List" <jetspeed-user@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:
> ><mailto:jetspeed-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> ><mailto:jetspeed-user-help@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> >--
> >To unsubscribe,
> >e-mail:   <mailto:jetspeed-user-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
> ><mailto:jetspeed-user-help@jakarta.apache.org>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <mailto:jetspeed-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-user-help@jakarta.apache.org>

View raw message