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 Shah Amit <am...@hotmail.com> on 2005/02/21 00:44:55 UTC
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 <mi...@dataline.com>
Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
To: Jetspeed Users List <je...@jakarta.apache.org>
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 <mi...@dataline.com>
>Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
>To: Jetspeed Users List <je...@jakarta.apache.org>
>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
>>from the browser.
>>
>>Till now I used to edit the "default-page.psml" in jetspeed/web-inf/pages
>>directory and enter my portlet in there.
>>
>>But suppose I want to have my own psml file. (I guess I should put it
>>under <my-webapp>/web-inf/pages/myPage.psml ??) Now even if I do this, how
>>should I access this page from the browser ?
>>http://localhost:8080/jetspeed/myapp/myPage.psml ??
>>
>>Also regarding decorators. I have read all the documentation on the
>>website and I understand how it should be done. But again similar
>>question. I should be able to put my decorators under
>><my-webapp>/web-inf/decorations etc. ??
>>
>>My only concern is that I dont want to change anything in jetspeed. This
>>way I can easily keep updating jetspeed with new releases. Otherwise I
>>would have to put my changes in jetspeed everytime I upgrade my jetspeed.
>>
>>Please help/advise/comment ....
>>
>>Thanks,
>>Amit
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>Sha,
>Did you work through your database issues? I am in the throes of
>understanding the Jetspeed-2 RDBMS security implementation and can offer
>some help if you need it.
>
>Sincerely,
>Mike Long
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: J2 - Grouping Permissions with the JAAS implementation
Posted by Shah Amit <am...@hotmail.com>.
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 others etc...) 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: watler@wispertel.net
Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
To: "Jetspeed Users List" <je...@jakarta.apache.org>
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 <mi...@dataline.com>
> Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
> To: Jetspeed Users List <je...@jakarta.apache.org>
> 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 <mi...@dataline.com>
>>Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
>>To: Jetspeed Users List <je...@jakarta.apache.org>
>>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
>>>from the browser.
>>>
>>>Till now I used to edit the "default-page.psml" in
>>> jetspeed/web-inf/pages
>>>directory and enter my portlet in there.
>>>
>>>But suppose I want to have my own psml file. (I guess I should put it
>>>under <my-webapp>/web-inf/pages/myPage.psml ??) Now even if I do this,
>>> how
>>>should I access this page from the browser ?
>>>http://localhost:8080/jetspeed/myapp/myPage.psml ??
>>>
>>>Also regarding decorators. I have read all the documentation on the
>>>website and I understand how it should be done. But again similar
>>>question. I should be able to put my decorators under
>>><my-webapp>/web-inf/decorations etc. ??
>>>
>>>My only concern is that I dont want to change anything in jetspeed. This
>>>way I can easily keep updating jetspeed with new releases. Otherwise I
>>>would have to put my changes in jetspeed everytime I upgrade my
>>> jetspeed.
>>>
>>>Please help/advise/comment ....
>>>
>>>Thanks,
>>>Amit
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>Sha,
>>Did you work through your database issues? I am in the throes of
>>understanding the Jetspeed-2 RDBMS security implementation and can offer
>>some help if you need it.
>>
>>Sincerely,
>>Mike Long
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: J2 - Grouping Permissions with the JAAS implementation
Posted by wa...@wispertel.net.
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 <mi...@dataline.com>
> Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
> To: Jetspeed Users List <je...@jakarta.apache.org>
> 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 <mi...@dataline.com>
>>Reply-To: "Jetspeed Users List" <je...@jakarta.apache.org>
>>To: Jetspeed Users List <je...@jakarta.apache.org>
>>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
>>>from the browser.
>>>
>>>Till now I used to edit the "default-page.psml" in
>>> jetspeed/web-inf/pages
>>>directory and enter my portlet in there.
>>>
>>>But suppose I want to have my own psml file. (I guess I should put it
>>>under <my-webapp>/web-inf/pages/myPage.psml ??) Now even if I do this,
>>> how
>>>should I access this page from the browser ?
>>>http://localhost:8080/jetspeed/myapp/myPage.psml ??
>>>
>>>Also regarding decorators. I have read all the documentation on the
>>>website and I understand how it should be done. But again similar
>>>question. I should be able to put my decorators under
>>><my-webapp>/web-inf/decorations etc. ??
>>>
>>>My only concern is that I dont want to change anything in jetspeed. This
>>>way I can easily keep updating jetspeed with new releases. Otherwise I
>>>would have to put my changes in jetspeed everytime I upgrade my
>>> jetspeed.
>>>
>>>Please help/advise/comment ....
>>>
>>>Thanks,
>>>Amit
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>Sha,
>>Did you work through your database issues? I am in the throes of
>>understanding the Jetspeed-2 RDBMS security implementation and can offer
>>some help if you need it.
>>
>>Sincerely,
>>Mike Long
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org