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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ----- Original Message ----- From: "Phillip Rhodes" <[EMAIL PROTECTED]> To: "Jetspeed Users List" <[EMAIL PROTECTED]>; "Jetspeed Users List" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >To: "Jetspeed Users List" <[EMAIL PROTECTED]> > >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:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > >-- > >To unsubscribe, > >e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
