Re: J2 - Grouping Permissions with the JAAS implementation
Hi Randy, I have to control two things with the help of security model. 1. Allow/disallow/show different contents on a psml based on which user is logged on. (This is very easy to achieve with the security model of Jetspeed as you indicated.) 2. Enable/Disable contents on some individual portlets based on which user has logged on. (For example show some buttons and links on a page to only some users, and not to other users, show some text fields and labels to only some users and not to othersetc...) Now for this feature, should I use security_permission table, or I should just define a role and flag my components based on that role ... I couldn't find a way to access the security_permissions from within the portlet using the standard portlet api (it is probably custom jetspeed stuff ?? ...) . Also, there is a table - security_group_role on the schema. This table has zero records. The way the relations on this table are defined, I am confused as to why or how I would ever use this table. Thanks, Amit Original Message Follows From: [EMAIL PROTECTED] Reply-To: "Jetspeed Users List" To: "Jetspeed Users List" Subject: Re: J2 - Grouping Permissions with the JAAS implementation Date: Mon, 21 Feb 2005 08:37:02 -0700 (MST) Amit, There are two security implementations to choose between to control access to folders and pages in the J2 portal. Both solutions allow specification by group and role in addition to user principals. I am not sure exactly what you are using the 20-25 permissions to control, but I am guessing that your J2 needs are covered. For PSML based security, (aka "bronco"), poke around in the demo site files for "security-constraint" tags. There are also some docs on the site that David put together as well. For JAAS permissions style security, see the populate-userinfo-for-default-psml.sql script that configures similar access to the site content. To use JAAS, you will have to change the configuration of the CastorXMLPageManager component in page-manager.xml. One can also use BOTH mechanisms simultaneously if necessary. HTH, Randy > With the security implementation of JAAS, I think in jetspeed there is a > direct relation between user and permissions. > > Now in a scenerio that I have, I have a bunch of permissions that I group > into a role, and then relate that to user. I think this facility is > lacking > in jetspeed. But I am not sure if this is the case, or I am missing > something. This feature would be kind of essential because I have around > 20 > - 25 permissions and I have to change behaviours based on those > permissions. > The user_permission table of jetspeed would probably get really very big. > > Any suggestions/helps > > Thanks, > Amit > > > > Original Message Follows > From: mike long <[EMAIL PROTECTED]> > Reply-To: "Jetspeed Users List" > To: Jetspeed Users List > Subject: Re: Access your own psml file > Date: Wed, 09 Feb 2005 12:29:59 -0500 > > Shah Amit wrote: > >>Hi Mike, >> >>Thanks a lot !! I do need help with security implementation. I would >> really >>really appreciate help !! I have gone thru the SPI interfaces and was >>trying to understand them. >> >>In the meantime, I was preparing for a presentation tomorrow so I wanted >> to >>see if I can layout a proof of concept with Jetspeed2. >> >>But I definately need help with the security implementation. >> >>If you want, I can pose my question again --- >> >>I have following security tables -- >> > Sha, > I will map the current J2 tables to your tables as best I can. These are > only my initial thoughts. I haven't implemented this solution to mapping > your current security data model to J2. In general I think you have two > alternatives: > 1) Map your current security data model to the J2 classes by altering the > security_repository.xml file. Security_repository.xml contains the > mapping > between the J2 security classes and the underlying data model. The > advantage > of this approach is that you would not have to change any code. You would > know you were successful when all the tests ran. Some tests may still > fail. > For example, you appear to have no many-to-many relationship between users > and roles. You will have to sort through relationships you are missing. > Maybe the tests will still run. Perhaps you can still use the J2 table > mappings where you have no equivalent. > > 2) Implement the following interfaces: GroupSecurityHandler, > RoleSecurityHandler, UserSecurityHandler, CredentialHandler, and > SecurityMappingHandler. You will note that the default implementations of > these classes use a class called SecurityAccessImpl to do a lot of t
Re: J2 - Grouping Permissions with the JAAS implementation
Amit, There are two security implementations to choose between to control access to folders and pages in the J2 portal. Both solutions allow specification by group and role in addition to user principals. I am not sure exactly what you are using the 20-25 permissions to control, but I am guessing that your J2 needs are covered. For PSML based security, (aka "bronco"), poke around in the demo site files for "security-constraint" tags. There are also some docs on the site that David put together as well. For JAAS permissions style security, see the populate-userinfo-for-default-psml.sql script that configures similar access to the site content. To use JAAS, you will have to change the configuration of the CastorXMLPageManager component in page-manager.xml. One can also use BOTH mechanisms simultaneously if necessary. HTH, Randy > With the security implementation of JAAS, I think in jetspeed there is a > direct relation between user and permissions. > > Now in a scenerio that I have, I have a bunch of permissions that I group > into a role, and then relate that to user. I think this facility is > lacking > in jetspeed. But I am not sure if this is the case, or I am missing > something. This feature would be kind of essential because I have around > 20 > - 25 permissions and I have to change behaviours based on those > permissions. > The user_permission table of jetspeed would probably get really very big. > > Any suggestions/helps > > Thanks, > Amit > > > > Original Message Follows > From: mike long <[EMAIL PROTECTED]> > Reply-To: "Jetspeed Users List" > To: Jetspeed Users List > Subject: Re: Access your own psml file > Date: Wed, 09 Feb 2005 12:29:59 -0500 > > Shah Amit wrote: > >>Hi Mike, >> >>Thanks a lot !! I do need help with security implementation. I would >> really >>really appreciate help !! I have gone thru the SPI interfaces and was >>trying to understand them. >> >>In the meantime, I was preparing for a presentation tomorrow so I wanted >> to >>see if I can layout a proof of concept with Jetspeed2. >> >>But I definately need help with the security implementation. >> >>If you want, I can pose my question again --- >> >>I have following security tables -- >> > Sha, > I will map the current J2 tables to your tables as best I can. These are > only my initial thoughts. I haven't implemented this solution to mapping > your current security data model to J2. In general I think you have two > alternatives: > 1) Map your current security data model to the J2 classes by altering the > security_repository.xml file. Security_repository.xml contains the > mapping > between the J2 security classes and the underlying data model. The > advantage > of this approach is that you would not have to change any code. You would > know you were successful when all the tests ran. Some tests may still > fail. > For example, you appear to have no many-to-many relationship between users > and roles. You will have to sort through relationships you are missing. > Maybe the tests will still run. Perhaps you can still use the J2 table > mappings where you have no equivalent. > > 2) Implement the following interfaces: GroupSecurityHandler, > RoleSecurityHandler, UserSecurityHandler, CredentialHandler, and > SecurityMappingHandler. You will note that the default implementations of > these classes use a class called SecurityAccessImpl to do a lot of the > actual JDBC work. You may have to change SecurityAccessImpl as well. > This > alternative seems pretty hard, close to the work involved in making LDAP > implementations which I expect to take about a month given that you are > already familiar with the underlying technology. > > I have done a cursory mapping below: > >>- user (username, password, userid etc.) > > security_principal - Contains the user. Your username field should be > mapped > to the full_path column. > security_credential - Contains the password. Password is the only type of > credential in use as far as I can tell. Your current implementation stores > the password on the user table. My ldap implementation does the same. > >>- groups (groupid, groupname) > > security_principal - Contains the group, just mapped to a different class. > Your groupname field should be mapped to the full_path column. > >>- role (roleid, rolename) > > security_principal - Contains the role, just mapped to a different class. > Your rolename field should be mapped to the full_path column. > >>- permission (permissionid, permissionname) > > security_permission - Contains the security permissions. Your > permissionname > should map directly to the name column there. > >>- role_permission > > Here you have a direct mapping the J2 security_principal_permission table. > J2 puts role, group, and user in a single security_principal table. > >>- group_role > > Here you have a direct mapping to the security_group_role table. > >> >>- user_group > > This table is analogous to the J2 security_user_group table which contains
J2 - Grouping Permissions with the JAAS implementation
With the security implementation of JAAS, I think in jetspeed there is a direct relation between user and permissions. Now in a scenerio that I have, I have a bunch of permissions that I group into a role, and then relate that to user. I think this facility is lacking in jetspeed. But I am not sure if this is the case, or I am missing something. This feature would be kind of essential because I have around 20 - 25 permissions and I have to change behaviours based on those permissions. The user_permission table of jetspeed would probably get really very big. Any suggestions/helps Thanks, Amit Original Message Follows From: mike long <[EMAIL PROTECTED]> Reply-To: "Jetspeed Users List" To: Jetspeed Users List Subject: Re: Access your own psml file Date: Wed, 09 Feb 2005 12:29:59 -0500 Shah Amit wrote: Hi Mike, Thanks a lot !! I do need help with security implementation. I would really really appreciate help !! I have gone thru the SPI interfaces and was trying to understand them. In the meantime, I was preparing for a presentation tomorrow so I wanted to see if I can layout a proof of concept with Jetspeed2. But I definately need help with the security implementation. If you want, I can pose my question again --- I have following security tables -- Sha, I will map the current J2 tables to your tables as best I can. These are only my initial thoughts. I haven't implemented this solution to mapping your current security data model to J2. In general I think you have two alternatives: 1) Map your current security data model to the J2 classes by altering the security_repository.xml file. Security_repository.xml contains the mapping between the J2 security classes and the underlying data model. The advantage of this approach is that you would not have to change any code. You would know you were successful when all the tests ran. Some tests may still fail. For example, you appear to have no many-to-many relationship between users and roles. You will have to sort through relationships you are missing. Maybe the tests will still run. Perhaps you can still use the J2 table mappings where you have no equivalent. 2) Implement the following interfaces: GroupSecurityHandler, RoleSecurityHandler, UserSecurityHandler, CredentialHandler, and SecurityMappingHandler. You will note that the default implementations of these classes use a class called SecurityAccessImpl to do a lot of the actual JDBC work. You may have to change SecurityAccessImpl as well. This alternative seems pretty hard, close to the work involved in making LDAP implementations which I expect to take about a month given that you are already familiar with the underlying technology. I have done a cursory mapping below: - user (username, password, userid etc.) security_principal - Contains the user. Your username field should be mapped to the full_path column. security_credential - Contains the password. Password is the only type of credential in use as far as I can tell. Your current implementation stores the password on the user table. My ldap implementation does the same. - groups (groupid, groupname) security_principal - Contains the group, just mapped to a different class. Your groupname field should be mapped to the full_path column. - role (roleid, rolename) security_principal - Contains the role, just mapped to a different class. Your rolename field should be mapped to the full_path column. - permission (permissionid, permissionname) security_permission - Contains the security permissions. Your permissionname should map directly to the name column there. - role_permission Here you have a direct mapping the J2 security_principal_permission table. J2 puts role, group, and user in a single security_principal table. - group_role Here you have a direct mapping to the security_group_role table. - user_group This table is analogous to the J2 security_user_group table which contains two FKs: one to the security_principal row for the user and the other to the security_principal row for the group. Now I am sure my DBA is going to yell on him if I ask him to change these tables !!! And David Sean Taylor advised that a good way of doing this would be to implement my own SPI provider. But then the mailing list advised me to see if it is feasible to adapt my tables ... I am confused !! Help help !!! I guess I can start the conversation back in the original "database question" thread because I guess it woudl be misguiding to have this discussion under this thread ... Original Message Follows From: mike long <[EMAIL PROTECTED]> Reply-To: "Jetspeed Users List" To: Jetspeed Users List Subject: Re: Access your own psml file Date: Wed, 09 Feb 2005 10:52:03 -0500 Shah Amit wrote: I have my own "portlet web application". Now it logically makes sense that to deploy this this applicaiton, I should just throw it under jetspeed/web-inf/deploy, and should be able to access my webapplication
