J2 Profiler, was: Re: Jetspeed2 M1 security setup
Doug Schnelzer wrote: Randy, Thanks for the guidance. Putting the login portlet in a plain page in the guest directory and protecting everything else works well. In the future, it would be nice to dynamically show/hide portlets on a page based on a user's role. It is definitely under consideration... odds are it will be there in M2 if I had to guess, but others need to weigh in. As I dig in further, can you point me in the right direction for learning more about how the profiler works? Should I just follow the Jetspeed2 source code? If so, can you point me at a Java class to start with? First, look and understand the examples shipped with J2. Try logging in as user/user and jetspeed/jetspeed. Compare what you see with the various content pages and other elements in the pages directories. For more detail, check out this document: http://cvs.apache.org/viewcvs.cgi/jakarta-jetspeed-2/design-docs/src/profiler/J2-page-manager-profiling.sxw This is an OpenOffice document. I can email you another format if you'd like. The source code for all of this resides in /components/profiler and /components/page-manager, but it is not trivial. Feel free to ask questions here so that others can read about the profiler and how to configure it! Also as I browse through the WEB-INF/pages directory structure, there seems to be psml files that aren't displayed (e.g. pages/_user/user/p003.psml and pages/_user/user/nested-layout.psml). These are simply user files for 'user', (instead of 'guest')! Login as user/user. I'd like to learn more about how this works. Is the psml documentation for Jetspeed 1 applicable? Personally, I'd prefer if you stick with J2 resources and asking questions here. We can also contribute to the wiki as we go, (if nothing else we can link back to user list threads). If not can you recommend a better starting point (part of the source code is fine) for some self-study on overall navigation and layout? The easiest thing is to look at the examples. For a better understanding of navigations/layout, look at the Velocity, (*.vm), templates in the WEB-INF/decorations/layout/html/tigris and WEB-INF/decorations/portlet/html/tigris directories. Most of all, don't be shy on this list! Thanks very much, Doug No problem... good luck with J2! Randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed2 M1 security setup
Randy, Thanks for the guidance. Putting the login portlet in a plain page in the guest directory and protecting everything else works well. In the future, it would be nice to dynamically show/hide portlets on a page based on a user's role. As I dig in further, can you point me in the right direction for learning more about how the profiler works? Should I just follow the Jetspeed2 source code? If so, can you point me at a Java class to start with? Also as I browse through the WEB-INF/pages directory structure, there seems to be psml files that aren't displayed (e.g. pages/_user/user/p003.psml and pages/_user/user/nested-layout.psml). I'd like to learn more about how this works. Is the psml documentation for Jetspeed 1 applicable? If not can you recommend a better starting point (part of the source code is fine) for some self-study on overall navigation and layout? Thanks very much, Doug -Original Message- From: Randy Watler [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 7:04 PM To: Jetspeed Users List Subject: Re: Jetspeed2 M1 security setup Ate Douma wrote: > > Randy Watler wrote: > >> Doug, >> >> Portlet level security constraints are apparently the responsibility >> of the portlet writer to implement, so the portal and portlet >> container will always display the portlet. We just received >> clarification on this from the pluto mail list: >> >> http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 > > One small correction: only the portlet container should not > enforce security constraints according to the portlet specification. > The portal can, as Randy showed in the example below. > > Another solution would be to use security constraints on a page, > restricting > (certain type of) access to only certain users, roles or groups. Just to be clear, I think Doug is trying to control access by role at the page level but wants finer grain control over portlet in the page. This is not available now, so I was proposing he try controlling acess to two different pages with appropriate portlet subsets via the profiler. > > Furthermore, this should not only be possible on page level but even on > (psml) fragment level, but that isn't yet implemented I think (Randy?). This is not implemented in M1. > > If (when) it is, you can simply restrict certain parts of a page to > certain > users, groups and/or roles. Well, David and I discussed this just before M1 was released. I actually had it implemented on the fragment level, but we figured that the portlet security constraints would be sufficient/conflicting, so we removed it. However, we did not have the Pluto ruling then. So, we'll have to revist this for M2. I'll add it to my "to-do" list. > > >> >> So, one way to achieve what you are after is to use the profiler. >> When the user is not logged in, they are known as 'guest'. By >> default, users are profiled using the 'j1' rule. This all boils down >> to the fact that unauthenticated users can be directed to pages >> placed in the ".../WEB-INF/pages/_user/guest" directory. Place your >> stripped down version of your pages in this 'guest' directory, >> (without your role security), and then secure all the rest of the >> pages in your site by role. >> >> HTH, >> >> Randy >> >> Doug Schnelzer wrote: >> >>> I've been working through this thread. It's very helpful. Thanks >>> to Marina >>> and Randy for providing some good documentation here. As I have worked >>> through this, I have a follow up question... >>> >>> Is there a way in a psml file or in one of the deployment >>> descriptors to >>> require a role before displaying "some" of the portlets on a page? >>> I want >>> to modify the default page so that only the login portlet is visible >>> until a >>> user logs in. If I make the entire page require a role, then I >>> can't log in >>> to establish my identity. >>> >>> Thanks, Doug >>> >>> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Ate Douma wrote: Randy Watler wrote: Doug, Portlet level security constraints are apparently the responsibility of the portlet writer to implement, so the portal and portlet container will always display the portlet. We just received clarification on this from the pluto mail list: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 One small correction: only the portlet container should not enforce security constraints according to the portlet specification. The portal can, as Randy showed in the example below. Another solution would be to use security constraints on a page, restricting (certain type of) access to only certain users, roles or groups. Just to be clear, I think Doug is trying to control access by role at the page level but wants finer grain control over portlet in the page. This is not available now, so I was proposing he try controlling acess to two different pages with appropriate portlet subsets via the profiler. Furthermore, this should not only be possible on page level but even on (psml) fragment level, but that isn't yet implemented I think (Randy?). This is not implemented in M1. If (when) it is, you can simply restrict certain parts of a page to certain users, groups and/or roles. Well, David and I discussed this just before M1 was released. I actually had it implemented on the fragment level, but we figured that the portlet security constraints would be sufficient/conflicting, so we removed it. However, we did not have the Pluto ruling then. So, we'll have to revist this for M2. I'll add it to my "to-do" list. So, one way to achieve what you are after is to use the profiler. When the user is not logged in, they are known as 'guest'. By default, users are profiled using the 'j1' rule. This all boils down to the fact that unauthenticated users can be directed to pages placed in the ".../WEB-INF/pages/_user/guest" directory. Place your stripped down version of your pages in this 'guest' directory, (without your role security), and then secure all the rest of the pages in your site by role. HTH, Randy Doug Schnelzer wrote: I've been working through this thread. It's very helpful. Thanks to Marina and Randy for providing some good documentation here. As I have worked through this, I have a follow up question... Is there a way in a psml file or in one of the deployment descriptors to require a role before displaying "some" of the portlets on a page? I want to modify the default page so that only the login portlet is visible until a user logs in. If I make the entire page require a role, then I can't log in to establish my identity. Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Randy Watler wrote: Doug, Portlet level security constraints are apparently the responsibility of the portlet writer to implement, so the portal and portlet container will always display the portlet. We just received clarification on this from the pluto mail list: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 One small correction: only the portlet container should not enforce security constraints according to the portlet specification. The portal can, as Randy showed in the example below. Another solution would be to use security constraints on a page, restricting (certain type of) access to only certain users, roles or groups. Furthermore, this should not only be possible on page level but even on (psml) fragment level, but that isn't yet implemented I think (Randy?). If (when) it is, you can simply restrict certain parts of a page to certain users, groups and/or roles. So, one way to achieve what you are after is to use the profiler. When the user is not logged in, they are known as 'guest'. By default, users are profiled using the 'j1' rule. This all boils down to the fact that unauthenticated users can be directed to pages placed in the ".../WEB-INF/pages/_user/guest" directory. Place your stripped down version of your pages in this 'guest' directory, (without your role security), and then secure all the rest of the pages in your site by role. HTH, Randy Doug Schnelzer wrote: I've been working through this thread. It's very helpful. Thanks to Marina and Randy for providing some good documentation here. As I have worked through this, I have a follow up question... Is there a way in a psml file or in one of the deployment descriptors to require a role before displaying "some" of the portlets on a page? I want to modify the default page so that only the login portlet is visible until a user logs in. If I make the entire page require a role, then I can't log in to establish my identity. Thanks, Doug -Original Message- From: Marina [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 4:35 PM To: Jetspeed Users List Subject: RE: Jetspeed2 M1 security setup Randy, thanks a lot for your help! I was able to setup a basic access control to my portlet's view and Edit mode. I do have more questions on the user management in J2, though :) I've created a new user, dce-admin, using the "Administrative Portlets" as 'admin' user. This worked fine, and I was able to detect this user through the PortletResponse.getUserPrincipal(). I've also tried to create a new role, say dce-admin-role, and assign this role to the new user. This , unfortunately, did not work. I entered the new role name into the corresponding form ("Add Role") of the "Role Management" tab, but it was never added to the list of the available roles and when I tried to assign this role to the new user I've got an error from J2 complaining that this role does not exist: *** New Full Path: /role/dce-admin-role failed to add user to role: dce-admin, dce-admin-roleorg.apache.jetspeed.security.SecurityException: The role does not exist. dce-admin-role *** New Full Path: /role/dce-admin-role Any idea why this is not working? Thanks, Marina --- Randy Watler <[EMAIL PROTECTED]> wrote: Marina, Thanks for using the jetspeed user list! Comments below. Randy -Original Message- From: Marina To: 'Jetspeed Users List ' Sent: 12/6/04 5:06 PM Subject: RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)> Hi, I've successfully built and installed J2 M1 and was looking into the demo applications to figure out how to setup access control for portlets/pages. After checking out some example portlets , like RoleSecurityTest and Login, and their source code, I think I have some idea of how to approach the task but I would like to clarify some topics. First, I'll list my assumptions and then ask questions: 1. tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security file specifies 'Edit'/'View' permissions for the default Portal's page, defined in default-page.psml The /page.security file defines named security constraints that can be referenced here or in individual page, folder meta data, link, or document set documents. The scope of this file is global across the entire site. References take the form of , (which appear only in /page.security), or . Thus, this part : admin view, edit means that only a user with the role 'admin' can edit the layout of the page. Yes, since this fragment is referenced in a , it applies to all documents in the site. And this fragment: manager view means that a user with the role 'manager' can view the page.
Re: Jetspeed2 M1 security setup
Doug, Portlet level security constraints are apparently the responsibility of the portlet writer to implement, so the portal and portlet container will always display the portlet. We just received clarification on this from the pluto mail list: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=261&msgNo=2160 So, one way to achieve what you are after is to use the profiler. When the user is not logged in, they are known as 'guest'. By default, users are profiled using the 'j1' rule. This all boils down to the fact that unauthenticated users can be directed to pages placed in the ".../WEB-INF/pages/_user/guest" directory. Place your stripped down version of your pages in this 'guest' directory, (without your role security), and then secure all the rest of the pages in your site by role. HTH, Randy Doug Schnelzer wrote: I've been working through this thread. It's very helpful. Thanks to Marina and Randy for providing some good documentation here. As I have worked through this, I have a follow up question... Is there a way in a psml file or in one of the deployment descriptors to require a role before displaying "some" of the portlets on a page? I want to modify the default page so that only the login portlet is visible until a user logs in. If I make the entire page require a role, then I can't log in to establish my identity. Thanks, Doug -Original Message- From: Marina [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 4:35 PM To: Jetspeed Users List Subject: RE: Jetspeed2 M1 security setup Randy, thanks a lot for your help! I was able to setup a basic access control to my portlet's view and Edit mode. I do have more questions on the user management in J2, though :) I've created a new user, dce-admin, using the "Administrative Portlets" as 'admin' user. This worked fine, and I was able to detect this user through the PortletResponse.getUserPrincipal(). I've also tried to create a new role, say dce-admin-role, and assign this role to the new user. This , unfortunately, did not work. I entered the new role name into the corresponding form ("Add Role") of the "Role Management" tab, but it was never added to the list of the available roles and when I tried to assign this role to the new user I've got an error from J2 complaining that this role does not exist: *** New Full Path: /role/dce-admin-role failed to add user to role: dce-admin, dce-admin-roleorg.apache.jetspeed.security.SecurityException: The role does not exist. dce-admin-role *** New Full Path: /role/dce-admin-role Any idea why this is not working? Thanks, Marina --- Randy Watler <[EMAIL PROTECTED]> wrote: Marina, Thanks for using the jetspeed user list! Comments below. Randy -Original Message- From: Marina To: 'Jetspeed Users List ' Sent: 12/6/04 5:06 PM Subject: RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)> Hi, I've successfully built and installed J2 M1 and was looking into the demo applications to figure out how to setup access control for portlets/pages. After checking out some example portlets , like RoleSecurityTest and Login, and their source code, I think I have some idea of how to approach the task but I would like to clarify some topics. First, I'll list my assumptions and then ask questions: 1. tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security file specifies 'Edit'/'View' permissions for the default Portal's page, defined in default-page.psml The /page.security file defines named security constraints that can be referenced here or in individual page, folder meta data, link, or document set documents. The scope of this file is global across the entire site. References take the form of , (which appear only in /page.security), or . Thus, this part : admin view, edit means that only a user with the role 'admin' can edit the layout of the page. Yes, since this fragment is referenced in a , it applies to all documents in the site. And this fragment: manager view means that a user with the role 'manager' can view the page. Yes, where used with a . However, anybody can view this default page in reality - even before a user logs in. You don't need any special privileges to access http://localhost:8080/jetspeed to see the page. My assumption is that it is because security constraints are "overwritten" in the pages/folder.metadata file (see below). Is that true? Not exactly. The override is in the default-page.psml itself, (user=*, permission=view). What is the scope of the page.security definitions and where are they used? See
RE: Jetspeed2 M1 security setup
I've been working through this thread. It's very helpful. Thanks to Marina and Randy for providing some good documentation here. As I have worked through this, I have a follow up question... Is there a way in a psml file or in one of the deployment descriptors to require a role before displaying "some" of the portlets on a page? I want to modify the default page so that only the login portlet is visible until a user logs in. If I make the entire page require a role, then I can't log in to establish my identity. Thanks, Doug -Original Message- From: Marina [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 4:35 PM To: Jetspeed Users List Subject: RE: Jetspeed2 M1 security setup Randy, thanks a lot for your help! I was able to setup a basic access control to my portlet's view and Edit mode. I do have more questions on the user management in J2, though :) I've created a new user, dce-admin, using the "Administrative Portlets" as 'admin' user. This worked fine, and I was able to detect this user through the PortletResponse.getUserPrincipal(). I've also tried to create a new role, say dce-admin-role, and assign this role to the new user. This , unfortunately, did not work. I entered the new role name into the corresponding form ("Add Role") of the "Role Management" tab, but it was never added to the list of the available roles and when I tried to assign this role to the new user I've got an error from J2 complaining that this role does not exist: *** New Full Path: /role/dce-admin-role failed to add user to role: dce-admin, dce-admin-roleorg.apache.jetspeed.security.SecurityException: The role does not exist. dce-admin-role *** New Full Path: /role/dce-admin-role Any idea why this is not working? Thanks, Marina --- Randy Watler <[EMAIL PROTECTED]> wrote: > Marina, > > Thanks for using the jetspeed user list! > > Comments below. > > Randy > > >-----Original Message- > >From: Marina > >To: 'Jetspeed Users List ' > >Sent: 12/6/04 5:06 PM > >Subject: RE: Jetspeed2 M1 security setup (was: > jetspeed-newbie > Roles-Groups-Users)> > > > >Hi, > > > > I've successfully built and installed J2 M1 and > was > >looking into the demo applications to figure out > how > >to setup access control for portlets/pages. > >After checking out some example portlets , like > >RoleSecurityTest and Login, and their source code, > I > >think I have some idea of how to approach the task > but > >I would like to clarify some topics. > > > >First, I'll list my assumptions and then ask > >questions: > > > >1. > >tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security > > file specifies 'Edit'/'View' permissions for the > >default Portal's page, defined in default-page.psml > > The /page.security file defines named security > constraints that can be > referenced here or in individual page, folder meta > data, link, or document > set documents. The scope of this file is global > across the entire site. > References take the form of > , (which > appear only in /page.security), or > . > > >Thus, this part : > > > > > > admin > > view, edit > > > > > >means that only a user with the role 'admin' can > edit > >the layout of the page. > > Yes, since this fragment is referenced in a > , it applies to > all documents in the site. > > >And this fragment: > > > > > > manager > > view > > > > > >means that a user with the role 'manager' can view > the > >page. > > Yes, where used with a . > > >However, anybody can view this default page in > reality > >- even before a user logs in. You don't need any > >special privileges to access > >http://localhost:8080/jetspeed to see the page. > >My assumption is that it is because security > >constraints are "overwritten" in the > >pages/folder.metadata file (see below). > >Is that true? > > Not exactly. The override is in the > default-page.psml itself, (user=*, > permission=view). > > >What is the scope of the page.security definitions > and > >where are they used? > > See above. > > >2. each folder under /pages directory (including > >/pages itself) has a folder.metadata file where > more > > are defined for that folder. > >For example, here is pages/folder.metadata: > >. > > > > > > user > >
Re: Jetspeed2 M1 security setup
Yes, it did work! The original SQL query did not work right away, so I looked more closely into the DB schema and guessed that I should be using the '/role' node's node_id as the 'parent_node_id' (204). That was a lucky guess and the following query worked fine: INSERT INTO PREFS_NODE VALUES(200,204,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22 16:27:12.472','2004-05-22 16:27:12.472'); After that, I was able to see the new role, 'dce-admin-role', in the 'Role Management' portlet's list, and was able to assign this role to a user and see it detected correctly by PortletRequest.isUserInRole("dce-admin-role"). Thanks a lot for your help! Marina --- David Le Strat <[EMAIL PROTECTED]> wrote: > Marina, > > If you are doing this manually, you also need to set > up the role hierarchy manager. In SQL terms, this > means something like this: > > INSERT INTO PREFS_NODE > VALUES(200,196,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22 > 16:27:12.472','2004-05-22 16:27:12.472'); > > You can also use the RoleManager to add the role you > want to set up. > > Regards, > > David. > > --- Marina <[EMAIL PROTECTED]> wrote: > > > Thanks, Randy, > > > > I tried adding the new role directly into the HSQL > > DB > > like this: > > INSERT INTO SECURITY_PRINCIPAL > > > VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15 > > 16:27:12.572','2004-12-15 16:27:12.572'); > > > > I ran this sql query directly on the HSQL DB, > > without > > modifying the > populate-userinfo-for-default-psml.sql > > and rebuilding J2. > > > > After I restarted J2, though, the new role is > still > > not displayed in the list of available roles in > the > > "Role Management" portlet. And asigning this role > to > > a > > user through the "User Manegement" portlet did not > > work either. > > > > Is this the only table I have to update > > ('security_principal') in order to create a new > > role, > > or are there some other related tables that I > > missed? > > > > Thanks, > > Marina > > > > --- Randy Watler <[EMAIL PROTECTED]> wrote: > > > > > Marina, > > > > > > There you have it, (thanks David). > > > > > > It is a simple matter to add users, roles, > groups, > > > etc. directly to the > > > DB in the interim. See one of the following > > scripts: > > > > > > CVS - > > src/sql/populate-userinfo-for-default-psml.sql > > > CVS - src/sql/ > > name>/populate-userinfo-for-default-psml.sql > > > M1 - > > > > > > jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql > > > M1 - jetspeed-database/scripts/sql/DML/ > > name>/populate-userinfo-for-default-psml.sql > > > > > > Randy > > > > > > David Le Strat wrote: > > > > > > >Marina, > > > > > > > >Implementation of the role management portlet > is > > > not > > > >complete. > > > > > > > >Regards, > > > > > > > >David Le Strat. > > > >--- Marina <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > >>Randy, thanks a lot for your help! I was able > to > > > >>setup > > > >>a basic access control to my portlet's view > and > > > Edit > > > >>mode. > > > >>I do have more questions on the user > management > > in > > > >>J2, > > > >>though :) > > > >> > > > >>I've created a new user, dce-admin, using the > > > >>"Administrative Portlets" as 'admin' user. > This > > > >>worked > > > >>fine, and I was able to detect this user > through > > > the > > > >>PortletResponse.getUserPrincipal(). > > > >>I've also tried to create a new role, say > > > >>dce-admin-role, and assign this role to the > new > > > >>user. > > > >>This , unfortunately, did not work. I entered > > the > > > >>new > > > >>role name into the corresponding form ("Add > > Role") > > > >>of > > > >>the "Role Management" tab, but it was never > > added > > > to > > > >>the list of the available roles and when I > tried > > > to > > > >>assign this role to the new user I've got an > > error > > > >>from J2 complaining that this role does not > > exist: > > > >> > > > >>*** New Full Path: /role/dce-admin-role > > > >>failed to add user to role: dce-admin, > > > >> > > > >> > > > >> > > > > > > >dce-admin-roleorg.apache.jetspeed.security.SecurityException: > > > > > > > > > > > >>The role does not exist. dce-admin-role > > > >>*** New Full Path: /role/dce-admin-role > > > >> > > > >> > > > >>Any idea why this is not working? > > > >> > > > >>Thanks, > > > >>Marina > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > __ > > Do you Yahoo!? > > Yahoo! Mail - Helps protect you from nasty > viruses. > > http://promotions.yahoo.com/new_mail > > > > > - > > To unsubscribe, e-mail: >
Re: Jetspeed2 M1 security setup
Marina, If you are doing this manually, you also need to set up the role hierarchy manager. In SQL terms, this means something like this: INSERT INTO PREFS_NODE VALUES(200,196,'dce-admin-role',0,'/role/dce-admin-role','2004-05-22 16:27:12.472','2004-05-22 16:27:12.472'); You can also use the RoleManager to add the role you want to set up. Regards, David. --- Marina <[EMAIL PROTECTED]> wrote: > Thanks, Randy, > > I tried adding the new role directly into the HSQL > DB > like this: > INSERT INTO SECURITY_PRINCIPAL > VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15 > 16:27:12.572','2004-12-15 16:27:12.572'); > > I ran this sql query directly on the HSQL DB, > without > modifying the populate-userinfo-for-default-psml.sql > and rebuilding J2. > > After I restarted J2, though, the new role is still > not displayed in the list of available roles in the > "Role Management" portlet. And asigning this role to > a > user through the "User Manegement" portlet did not > work either. > > Is this the only table I have to update > ('security_principal') in order to create a new > role, > or are there some other related tables that I > missed? > > Thanks, > Marina > > --- Randy Watler <[EMAIL PROTECTED]> wrote: > > > Marina, > > > > There you have it, (thanks David). > > > > It is a simple matter to add users, roles, groups, > > etc. directly to the > > DB in the interim. See one of the following > scripts: > > > > CVS - > src/sql/populate-userinfo-for-default-psml.sql > > CVS - src/sql/ > name>/populate-userinfo-for-default-psml.sql > > M1 - > > > jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql > > M1 - jetspeed-database/scripts/sql/DML/ > name>/populate-userinfo-for-default-psml.sql > > > > Randy > > > > David Le Strat wrote: > > > > >Marina, > > > > > >Implementation of the role management portlet is > > not > > >complete. > > > > > >Regards, > > > > > >David Le Strat. > > >--- Marina <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >>Randy, thanks a lot for your help! I was able to > > >>setup > > >>a basic access control to my portlet's view and > > Edit > > >>mode. > > >>I do have more questions on the user management > in > > >>J2, > > >>though :) > > >> > > >>I've created a new user, dce-admin, using the > > >>"Administrative Portlets" as 'admin' user. This > > >>worked > > >>fine, and I was able to detect this user through > > the > > >>PortletResponse.getUserPrincipal(). > > >>I've also tried to create a new role, say > > >>dce-admin-role, and assign this role to the new > > >>user. > > >>This , unfortunately, did not work. I entered > the > > >>new > > >>role name into the corresponding form ("Add > Role") > > >>of > > >>the "Role Management" tab, but it was never > added > > to > > >>the list of the available roles and when I tried > > to > > >>assign this role to the new user I've got an > error > > >>from J2 complaining that this role does not > exist: > > >> > > >>*** New Full Path: /role/dce-admin-role > > >>failed to add user to role: dce-admin, > > >> > > >> > > >> > > > >dce-admin-roleorg.apache.jetspeed.security.SecurityException: > > > > > > > > >>The role does not exist. dce-admin-role > > >>*** New Full Path: /role/dce-admin-role > > >> > > >> > > >>Any idea why this is not working? > > >> > > >>Thanks, > > >>Marina > > >> > > >> > > >> > > > > > > > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > __ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Thanks, Randy, I tried adding the new role directly into the HSQL DB like this: INSERT INTO SECURITY_PRINCIPAL VALUES(15,'org.apache.jetspeed.security.JetspeedRolePrincipalImpl',0,1,'/role/dce-admin-role','2004-12-15 16:27:12.572','2004-12-15 16:27:12.572'); I ran this sql query directly on the HSQL DB, without modifying the populate-userinfo-for-default-psml.sql and rebuilding J2. After I restarted J2, though, the new role is still not displayed in the list of available roles in the "Role Management" portlet. And asigning this role to a user through the "User Manegement" portlet did not work either. Is this the only table I have to update ('security_principal') in order to create a new role, or are there some other related tables that I missed? Thanks, Marina --- Randy Watler <[EMAIL PROTECTED]> wrote: > Marina, > > There you have it, (thanks David). > > It is a simple matter to add users, roles, groups, > etc. directly to the > DB in the interim. See one of the following scripts: > > CVS - src/sql/populate-userinfo-for-default-psml.sql > CVS - src/sql/ name>/populate-userinfo-for-default-psml.sql > M1 - > jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql > M1 - jetspeed-database/scripts/sql/DML/ name>/populate-userinfo-for-default-psml.sql > > Randy > > David Le Strat wrote: > > >Marina, > > > >Implementation of the role management portlet is > not > >complete. > > > >Regards, > > > >David Le Strat. > >--- Marina <[EMAIL PROTECTED]> wrote: > > > > > > > >>Randy, thanks a lot for your help! I was able to > >>setup > >>a basic access control to my portlet's view and > Edit > >>mode. > >>I do have more questions on the user management in > >>J2, > >>though :) > >> > >>I've created a new user, dce-admin, using the > >>"Administrative Portlets" as 'admin' user. This > >>worked > >>fine, and I was able to detect this user through > the > >>PortletResponse.getUserPrincipal(). > >>I've also tried to create a new role, say > >>dce-admin-role, and assign this role to the new > >>user. > >>This , unfortunately, did not work. I entered the > >>new > >>role name into the corresponding form ("Add Role") > >>of > >>the "Role Management" tab, but it was never added > to > >>the list of the available roles and when I tried > to > >>assign this role to the new user I've got an error > >>from J2 complaining that this role does not exist: > >> > >>*** New Full Path: /role/dce-admin-role > >>failed to add user to role: dce-admin, > >> > >> > >> > >dce-admin-roleorg.apache.jetspeed.security.SecurityException: > > > > > >>The role does not exist. dce-admin-role > >>*** New Full Path: /role/dce-admin-role > >> > >> > >>Any idea why this is not working? > >> > >>Thanks, > >>Marina > >> > >> > >> > > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jetspeed2 M1 security setup
Marina, There you have it, (thanks David). It is a simple matter to add users, roles, groups, etc. directly to the DB in the interim. See one of the following scripts: CVS - src/sql/populate-userinfo-for-default-psml.sql CVS - src/sql//populate-userinfo-for-default-psml.sql M1 - jetspeed-database/scripts/sql/DML/populate-userinfo-for-default-psml.sql M1 - jetspeed-database/scripts/sql/DML//populate-userinfo-for-default-psml.sql Randy David Le Strat wrote: Marina, Implementation of the role management portlet is not complete. Regards, David Le Strat. --- Marina <[EMAIL PROTECTED]> wrote: Randy, thanks a lot for your help! I was able to setup a basic access control to my portlet's view and Edit mode. I do have more questions on the user management in J2, though :) I've created a new user, dce-admin, using the "Administrative Portlets" as 'admin' user. This worked fine, and I was able to detect this user through the PortletResponse.getUserPrincipal(). I've also tried to create a new role, say dce-admin-role, and assign this role to the new user. This , unfortunately, did not work. I entered the new role name into the corresponding form ("Add Role") of the "Role Management" tab, but it was never added to the list of the available roles and when I tried to assign this role to the new user I've got an error from J2 complaining that this role does not exist: *** New Full Path: /role/dce-admin-role failed to add user to role: dce-admin, dce-admin-roleorg.apache.jetspeed.security.SecurityException: The role does not exist. dce-admin-role *** New Full Path: /role/dce-admin-role Any idea why this is not working? Thanks, Marina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jetspeed2 M1 security setup
Marina, Implementation of the role management portlet is not complete. Regards, David Le Strat. --- Marina <[EMAIL PROTECTED]> wrote: > Randy, thanks a lot for your help! I was able to > setup > a basic access control to my portlet's view and Edit > mode. > I do have more questions on the user management in > J2, > though :) > > I've created a new user, dce-admin, using the > "Administrative Portlets" as 'admin' user. This > worked > fine, and I was able to detect this user through the > PortletResponse.getUserPrincipal(). > I've also tried to create a new role, say > dce-admin-role, and assign this role to the new > user. > This , unfortunately, did not work. I entered the > new > role name into the corresponding form ("Add Role") > of > the "Role Management" tab, but it was never added to > the list of the available roles and when I tried to > assign this role to the new user I've got an error > from J2 complaining that this role does not exist: > > *** New Full Path: /role/dce-admin-role > failed to add user to role: dce-admin, > dce-admin-roleorg.apache.jetspeed.security.SecurityException: > The role does not exist. dce-admin-role > *** New Full Path: /role/dce-admin-role > > > Any idea why this is not working? > > Thanks, > Marina > > > > --- Randy Watler <[EMAIL PROTECTED]> wrote: > > > Marina, > > > > Thanks for using the jetspeed user list! > > > > Comments below. > > > > Randy > > > > >-Original Message- > > >From: Marina > > >To: 'Jetspeed Users List ' > > >Sent: 12/6/04 5:06 PM > > >Subject: RE: Jetspeed2 M1 security setup (was: > > jetspeed-newbie > > Roles-Groups-Users)> > > > > > >Hi, > > > > > > I've successfully built and installed J2 M1 and > > was > > >looking into the demo applications to figure out > > how > > >to setup access control for portlets/pages. > > >After checking out some example portlets , like > > >RoleSecurityTest and Login, and their source > code, > > I > > >think I have some idea of how to approach the > task > > but > > >I would like to clarify some topics. > > > > > >First, I'll list my assumptions and then ask > > >questions: > > > > > >1. > > > >tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security > > > file specifies 'Edit'/'View' permissions for the > > >default Portal's page, defined in > default-page.psml > > > > The /page.security file defines named security > > constraints that can be > > referenced here or in individual page, folder meta > > data, link, or document > > set documents. The scope of this file is global > > across the entire site. > > References take the form of > > , (which > > appear only in /page.security), or > > . > > > > >Thus, this part : > > > > > > > > > admin > > > view, edit > > > > > > > > >means that only a user with the role 'admin' can > > edit > > >the layout of the page. > > > > Yes, since this fragment is referenced in a > > , it applies to > > all documents in the site. > > > > >And this fragment: > > > > > > > > > manager > > > view > > > > > > > > >means that a user with the role 'manager' can > view > > the > > >page. > > > > Yes, where used with a > . > > > > >However, anybody can view this default page in > > reality > > >- even before a user logs in. You don't need any > > >special privileges to access > > >http://localhost:8080/jetspeed to see the page. > > >My assumption is that it is because security > > >constraints are "overwritten" in the > > >pages/folder.metadata file (see below). > > >Is that true? > > > > Not exactly. The override is in the > > default-page.psml itself, (user=*, > > permission=view). > > > > >What is the scope of the page.security > definitions > > and > > >where are they used? > > > > See above. > > > > >2. each folder under /pages directory (including > > >/pages itself) has a folder.metadata file where > > more > > > are defined for that
RE: Jetspeed2 M1 security setup
Randy, thanks a lot for your help! I was able to setup a basic access control to my portlet's view and Edit mode. I do have more questions on the user management in J2, though :) I've created a new user, dce-admin, using the "Administrative Portlets" as 'admin' user. This worked fine, and I was able to detect this user through the PortletResponse.getUserPrincipal(). I've also tried to create a new role, say dce-admin-role, and assign this role to the new user. This , unfortunately, did not work. I entered the new role name into the corresponding form ("Add Role") of the "Role Management" tab, but it was never added to the list of the available roles and when I tried to assign this role to the new user I've got an error from J2 complaining that this role does not exist: *** New Full Path: /role/dce-admin-role failed to add user to role: dce-admin, dce-admin-roleorg.apache.jetspeed.security.SecurityException: The role does not exist. dce-admin-role *** New Full Path: /role/dce-admin-role Any idea why this is not working? Thanks, Marina --- Randy Watler <[EMAIL PROTECTED]> wrote: > Marina, > > Thanks for using the jetspeed user list! > > Comments below. > > Randy > > >-Original Message- > >From: Marina > >To: 'Jetspeed Users List ' > >Sent: 12/6/04 5:06 PM > >Subject: RE: Jetspeed2 M1 security setup (was: > jetspeed-newbie > Roles-Groups-Users)> > > > >Hi, > > > > I've successfully built and installed J2 M1 and > was > >looking into the demo applications to figure out > how > >to setup access control for portlets/pages. > >After checking out some example portlets , like > >RoleSecurityTest and Login, and their source code, > I > >think I have some idea of how to approach the task > but > >I would like to clarify some topics. > > > >First, I'll list my assumptions and then ask > >questions: > > > >1. > >tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security > > file specifies 'Edit'/'View' permissions for the > >default Portal's page, defined in default-page.psml > > The /page.security file defines named security > constraints that can be > referenced here or in individual page, folder meta > data, link, or document > set documents. The scope of this file is global > across the entire site. > References take the form of > , (which > appear only in /page.security), or > . > > >Thus, this part : > > > > > > admin > > view, edit > > > > > >means that only a user with the role 'admin' can > edit > >the layout of the page. > > Yes, since this fragment is referenced in a > , it applies to > all documents in the site. > > >And this fragment: > > > > > > manager > > view > > > > > >means that a user with the role 'manager' can view > the > >page. > > Yes, where used with a . > > >However, anybody can view this default page in > reality > >- even before a user logs in. You don't need any > >special privileges to access > >http://localhost:8080/jetspeed to see the page. > >My assumption is that it is because security > >constraints are "overwritten" in the > >pages/folder.metadata file (see below). > >Is that true? > > Not exactly. The override is in the > default-page.psml itself, (user=*, > permission=view). > > >What is the scope of the page.security definitions > and > >where are they used? > > See above. > > >2. each folder under /pages directory (including > >/pages itself) has a folder.metadata file where > more > > are defined for that folder. > >For example, here is pages/folder.metadata: > >. > > > > > > user > > view > > > > > >manager > > > > This should be commented out in M1. > > > > > > > > > * > > view > > > > > > > >And this is why all users can see the default page. > >(Is that true?) > > It would be the case if default-page.psml did not > override on its own. To be > exact, this allows all users to view the folder and > any content within it > that does not specify its own security constraints. > In effect, this is the > site default for global pages because it is defined > at the root leve. > > >On the other hand, here is > >pages\Administrative\folder.metadata : > > >
RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Group s-Users)
Marina, Thanks for using the jetspeed user list! Comments below. Randy >-Original Message- >From: Marina >To: 'Jetspeed Users List ' >Sent: 12/6/04 5:06 PM >Subject: RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)> > >Hi, > > I've successfully built and installed J2 M1 and was >looking into the demo applications to figure out how >to setup access control for portlets/pages. >After checking out some example portlets , like >RoleSecurityTest and Login, and their source code, I >think I have some idea of how to approach the task but >I would like to clarify some topics. > >First, I'll list my assumptions and then ask >questions: > >1. >tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security > file specifies 'Edit'/'View' permissions for the >default Portal's page, defined in default-page.psml The /page.security file defines named security constraints that can be referenced here or in individual page, folder meta data, link, or document set documents. The scope of this file is global across the entire site. References take the form of , (which appear only in /page.security), or . >Thus, this part : > > > admin > view, edit > > >means that only a user with the role 'admin' can edit >the layout of the page. Yes, since this fragment is referenced in a , it applies to all documents in the site. >And this fragment: > > > manager > view > > >means that a user with the role 'manager' can view the >page. Yes, where used with a . >However, anybody can view this default page in reality >- even before a user logs in. You don't need any >special privileges to access >http://localhost:8080/jetspeed to see the page. >My assumption is that it is because security >constraints are "overwritten" in the >pages/folder.metadata file (see below). >Is that true? Not exactly. The override is in the default-page.psml itself, (user=*, permission=view). >What is the scope of the page.security definitions and >where are they used? See above. >2. each folder under /pages directory (including >/pages itself) has a folder.metadata file where more > are defined for that folder. >For example, here is pages/folder.metadata: >. > > > user > view > > >manager > This should be commented out in M1. > > > > * > view > > > >And this is why all users can see the default page. >(Is that true?) It would be the case if default-page.psml did not override on its own. To be exact, this allows all users to view the folder and any content within it that does not specify its own security constraints. In effect, this is the site default for global pages because it is defined at the root leve. >On the other hand, here is >pages\Administrative\folder.metadata : > > Jetspeed Administrative Portlets > > >manager > > > >This folder corresponds to the "Jetspeed >Administrative Portlets" menu item in the 'Folder and >Pages' menu on the left side of the Portal window. >However, it is displayed only when a user with the >'manager' role logged in. Correct. It also requires that its contents only be visible in the manager role as well. >3. There also are security-constraints in the .psml >files themselves. For example, pages/default-page.psml >has: > > > * > view > > Yes, and it is this that enables any user to view the default page, no matter what the folder that the page belongs to is permitted. >4. Also, there are defined in the >portlet.xml files of individual portlets. For example: > >. > > Administrator > admin > > > Manager > manager > > > User > user > > > >and corresponding are defined in the >web.xml file of the portlet application: > > > >The admin role >admin > > >The manager role >manager > > >The user role >user > > Yes, but this is portlet level security within the page. I am not sure if it functional as of M1. If it is, it will apply only to the rendering and actions of the individual portlets. If it is not implemented at this time, it will probably be soon. Let me know if you find out it does not function as per the portlet spec... i'll probably dig in and get it working at some point. >Questions: >-- How do all the security declarations in #1, 2, 3 >and 4 relate to each other? 1-3 are document level security and 4 is restricted to t
RE: Jetspeed2 M1 security setup (was: jetspeed-newbie Roles-Groups-Users)
Hi, I've successfully built and installed J2 M1 and was looking into the demo applications to figure out how to setup access control for portlets/pages. After checking out some example portlets , like RoleSecurityTest and Login, and their source code, I think I have some idea of how to approach the task but I would like to clarify some topics. First, I'll list my assumptions and then ask questions: 1. tomcat-5.0.30-j2-M1\webapps\jetspeed\WEB-INF\pages\page.security file specifies 'Edit'/'View' permissions for the default Portal's page, defined in default-page.psml Thus, this part : admin view, edit means that only a user with the role 'admin' can edit the layout of the page. And this fragment: manager view means that a user with the role 'manager' can view the page. However, anybody can view this default page in reality - even before a user logs in. You don't need any special privileges to access http://localhost:8080/jetspeed to see the page. My assumption is that it is because security constraints are "overwritten" in the pages/folder.metadata file (see below). Is that true? What is the scope of the page.security definitions and where are they used? 2. each folder under /pages directory (including /pages itself) has a folder.metadata file where more are defined for that folder. For example, here is pages/folder.metadata: . user view manager * view And this is why all users can see the default page. (Is that true?) On the other hand, here is pages\Administrative\folder.metadata : Jetspeed Administrative Portlets manager This folder corresponds to the "Jetspeed Administrative Portlets" menu item in the 'Folder and Pages' menu on the left side of the Portal window. However, it is displayed only when a user with the 'manager' role logged in. 3. There also are security-constraints in the .psml files themselves. For example, pages/default-page.psml has: * view 4. Also, there are defined in the portlet.xml files of individual portlets. For example: . Administrator admin Manager manager User user and corresponding are defined in the web.xml file of the portlet application: The admin role admin The manager role manager The user role user Questions: -- How do all the security declarations in #1, 2, 3 and 4 relate to each other? -- What declarations take precedence? -- what declarations are mandatory for others to work? 5. By looking at the jakarta-jetspeed-2-M1\applications\demo\src\webapp\WEB-INF\web.xml file I noticed that there were two example SSO servlets registered - SSODemoServlet and SSOBasicDemoServlet, and they were mapped to /sso-demo and /sso-basic URLs respectively. Here is how /sso-basic is protected: HTTPBasicDemo /sso-basic/* tomcat BASIC Jetspeed When I access this servlet as http://localhost:8080/demo/sso-basic I am getting a login screen that prompts me to enter username and password, as expected. The /sso-demo is not protected in the web.xml and when accessing it as http://localhost:8080/demo/sso-demo you just get an authentication error. Source code of the SSODemoServlet gives some explanation: /** * SSODemoServlet - looks for username, password in the URL for single * signon to this servlet from a SSO portlet. * Username request parameter: ssouser * Password request parameter: ssopw A few questions here: -- how can you use these servlets from your portlets if you want to utilize the Basic authentication mechanism? Should I just call RequestDispatcher.include("/demo/sso-basic")? If not - how else could I use these servlets in portlets? Or, maybe, not use servlets at all but get the Basic authentication working for portlets somehow? -- when supplying incorrect username/password for the SSOBasicDemo servlet, you get an error page in the browser and if you try to reload it it would not work and would not let you to retry login, until you start a new browser session. I checked my browser settings (both Mozilla and IE) and made sure they do not cache pages between requests - still the same problem. I'm sure it's something very simple - but what? Thanks fo rreading this till the end :) Marina __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]