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]>
