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 <global-security-constraints-ref/>, (which appear only in /page.security), or <security-constraints-ref/>.
Thus, this part :
<security-constraints-def name="admin">
<security-constraint>
<roles>admin</roles>
<permissions>view, edit</permissions>
</security-constraint>
</security-constraints-def>
means that only a user with the role 'admin' can
edit
the layout of the page.
Yes, since this fragment is referenced in a <global-security-constraints-ref/>, it applies to all documents in the site.
And this fragment:
<security-constraints-def name="manager">
<security-constraint>
<roles>manager</roles>
<permissions>view</permissions>
</security-constraint>
</security-constraints-def>
means that a user with the role 'manager' can view
the
page.
Yes, where used with a <security-constraints-ref/>.
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
<security-constraints> are defined for that folder.
For example, here is pages/folder.metadata:
.....
<security-constraints>
<security-constraint>
<roles>user</roles>
<permissions>view</permissions>
</security-constraint>
<security-constraints-ref>manager</security-constraints-ref>
</security-constraints>
This should be commented out in M1.
<security-constraints>
<security-constraint>
<users>*</users>
<permissions>view</permissions>
</security-constraint>
</security-constraints> </folder>
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 :
<folder>
<title>Jetspeed Administrative Portlets</title> <!-- allow only manager role -->
<security-constraints>
<security-constraints-ref>manager</security-constraints-ref>
</security-constraints> </folder>
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:
<security-constraints>
<security-constraint>
<users>*</users>
<permissions>view</permissions>
</security-constraint>
</security-constraints>
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 <security-ref> defined in the
portlet.xml files of individual portlets. For
example:
<portlet id="RoleSecurityTest"> ..... <security-role-ref> <role-name>Administrator</role-name> <role-link>admin</role-link> </security-role-ref> <security-role-ref> <role-name>Manager</role-name> <role-link>manager</role-link> </security-role-ref> <security-role-ref> <role-name>User</role-name> <role-link>user</role-link> </security-role-ref> </portlet>
and corresponding <security-roles> are defined in
the
web.xml file of the portlet application:
<web-app>
....
<security-role>
<description>The admin role</description>
<role-name>admin</role-name>
</security-role>
<security-role>
<description>The manager role</description>
=== message truncated ===
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
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]
--------------------------------------------------------------------- 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]
