Prashanth,

The portal does not enforce portlet level security, (neither permissions nor constraints). We have discussed this and have opted to stay the course for now since we are not sure how to implement this functionality and how it should interoperate with the portlet API. As you know, there are standard portlet API mechanisms that enable the portlet to perform security checks and handle access errors in their own way.

Of course, feedback is welcome. If you feel that this functionality is required at the portal level, feel free to create a JIRA issue that describes how you feel the portal should interpret access violations for view and edit actions. This has come up before... so I for one will consider your proposal.

Randy

Prashanth Gujjeti wrote:

Randy/David and others,
 I enabled Permissions security model (along with constraints security)
and added an entry for PortletPermission with 'view' access on a portlet
- ClientStruts - in the SECURITY_PERMISSION table. I assigned this
permission to the principal "user" in PRINCIPAL_PERMISSION.
+---------------+------------------------------------------------+------
----------------------------+------------+---------------------+--------
-------------+
| PERMISSION_ID | CLASSNAME                                      | NAME
| ACTIONS    | CREATION_DATE       | MODIFIED_DATE       |
+---------------+------------------------------------------------+------
----------------------------+------------+---------------------+--------
-------------+
|            16 | org.apache.jetspeed.security.PortletPermission |
ClientStruts                     | view       | 2005-08-25 23:16:20 |
2005-08-25 21:20:29 |
+---------------+------------------------------------------------+------
----------------------------+------------+---------------------+--------
-------------+

The user "user" has a PSML page which contains this portlet
       <fragment id="dp-9-clientstruts" type="portlet"
name="client::ClientStruts">
           <property name="row" value="0" layout="TwoColumns"/>
           <property name="column" value="1" layout="TwoColumns"/>
       </fragment>

And the portlet itself has view, help, and edit modes (in portlet.xml)

   <supports>
     <mime-type>text/html</mime-type>
     <portlet-mode>VIEW</portlet-mode>
     <portlet-mode>HELP</portlet-mode>
     <portlet-mode>EDIT</portlet-mode>
   </supports>

Yet, when the user "user" logs in, the "Edit" button is still enabled. I
tried various combinations, including disabling the Constraints security
model, but with no positive result. I tried Folder/page level security
based on the Permissions Security model, and that seems to be working.
Any ideas?

Thanks,
Prashanth



-----Original Message-----
From: Randy Watler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 12:54 PM
To: Jetspeed Users List
Subject: Re: [J2] Security - Specifying the policies

Prashanth,

There are two security models available... see this in page-manager.xml:

<bean id="org.apache.jetspeed.page.PageManager"
name="pageManager"
class="org.apache.jetspeed.page.impl.CastorXmlPageManager">
<constructor-arg index="0"><ref bean="IdGenerator"/></constructor-arg>
<constructor-arg index="1"><ref
bean="DocumentHandlerFactory"/></constructor-arg>
<constructor-arg index="2"><ref bean="FolderHandler"/></constructor-arg>
<constructor-arg index="3"><ref bean="PageFileCache"/></constructor-arg>
<!-- permissions security enabled flag, default=false -->
<constructor-arg index="4"><value>false</value></constructor-arg>
<!-- constraints security enabled flag, default=true -->
<constructor-arg index="5"><value>true</value></constructor-arg>
</bean>

You will want to disable the constraints, (PSML), and enable the
permissions, (java.security/FilePermission). Then, look here in
populate-userinfo-for-default-psml.sql:

INSERT INTO SECURITY_PERMISSION
VALUES(1,'org.apache.jetspeed.security.FolderPermission','<<ALL FILES>>','view, edit','2004-05-22 16:27:12.572','2004-05-22 FILES>>16:27:12.572');
INSERT INTO SECURITY_PERMISSION
VALUES(2,'org.apache.jetspeed.security.FolderPermission','<<ALL FILES>>','view','2004-05-22 16:27:12.572','2004-05-22 16:27:12.572');
INSERT INTO SECURITY_PERMISSION
VALUES(3,'org.apache.jetspeed.security.FolderPermission','/','view','200
4-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(4,'org.apache.jetspeed.security.FolderPermission','/*','view','20
04-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(5,'org.apache.jetspeed.security.FolderPermission','/non-java/-','
view','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(6,'org.apache.jetspeed.security.FolderPermission','/third-party/-
','view','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(7,'org.apache.jetspeed.security.FolderPermission','/Public','view
,
edit','2004-05-22 16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(8,'org.apache.jetspeed.security.FolderPermission','/Public/-','vi
ew,
edit','2004-05-22 16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(9,'org.apache.jetspeed.security.FolderPermission','/anotherdir/-'
,'view','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(10,'org.apache.jetspeed.security.FolderPermission','/top-links/-'
,'view','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(11,'org.apache.jetspeed.security.PagePermission','/default-page.p
sml','view','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(12,'org.apache.jetspeed.security.PagePermission','/rss.psml','vie
w','2004-05-22
16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(13,'org.apache.jetspeed.security.FolderPermission','/_user/user',
'view,
edit','2004-05-22 16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
SECURITY_PERMISSION
VALUES(14,'org.apache.jetspeed.security.FolderPermission','/_user/user/-
','view,
edit','2004-05-22 16:27:12.572','2004-05-22 16:27:12.572'); INSERT INTO
PRINCIPAL_PERMISSION VALUES(3,13); INSERT INTO PRINCIPAL_PERMISSION
VALUES(3,14); INSERT INTO PRINCIPAL_PERMISSION VALUES(6,1); INSERT INTO
PRINCIPAL_PERMISSION VALUES(7,2); INSERT INTO PRINCIPAL_PERMISSION
VALUES(8,3); INSERT INTO PRINCIPAL_PERMISSION VALUES(8,4); INSERT INTO
PRINCIPAL_PERMISSION VALUES(8,5); INSERT INTO PRINCIPAL_PERMISSION
VALUES(8,6); INSERT INTO PRINCIPAL_PERMISSION VALUES(8,8); INSERT INTO
PRINCIPAL_PERMISSION VALUES(8,9); INSERT INTO PRINCIPAL_PERMISSION
VALUES(8,10); INSERT INTO PRINCIPAL_PERMISSION VALUES(10,3); INSERT INTO
PRINCIPAL_PERMISSION VALUES(10,7); INSERT INTO PRINCIPAL_PERMISSION
VALUES(10,8); INSERT INTO PRINCIPAL_PERMISSION VALUES(10,11); INSERT
INTO PRINCIPAL_PERMISSION VALUES(10,12);

This attempts to set similar permissions to the constraints in the PSML
for the demo site. Note that the two models differ slightly and the
constraint model has a few features that cannot be supported here.

HTH,

Randy

Prashanth Gujjeti wrote:

Hi all,
We are trying to hook-up our own custom security valve into the
Jetspeed2 pipeline to bypass the J2's authentication mechanism as suggested in the forums. We created the Security Valve and we are able to bypass the authentication successfully. Thanks a bunch to Randy and others who answered our previous queries.

However, I have a couple of questions regarding the authorization policies. How do we define Security permissions, say for a role? One way to accomplish this is through the PSML pages/folder metadata/global

security preferences. But, how do we define a policy that defines the security preferences based on a Principal (role/group/user). Here is what I could figure out from J2's schema:

- SECURITY_PRINCIPAL defines roles, groups, and users.

- SECURITY_PERMISSION defines security permissions (on folders, and pages. I didn't find any for portlets)

- PRINCIPAL_PERMISSION relates the principals and permissions effectively providing different permissions based on role/user/group

How could we add permission entries to these tables (effectively defining policies per user/group/role)? And how would these permissions

aggregate. i.e. If a given user's principals (user/role/geoup) have conflicting permissions, which one would take precedence?

Essentially, we are trying to create a security policy based on the principals, rather than having to manage the distributed security constraints under the various PSML/folder.metadata files. The security design-doc - {JETSPEED-SRC}/design-docs/src/security/SecurityDesignNotes.txt - mentions something about granting principals:

###########
grant principal o.a.j.security.RolePrincipal "theRolePrincipal" {
permission o.a.j.security.PagePermission "mypage", "view";
permission o.a.j.security.PortletPermission "myportlet", "view,edit,minimize,maximize";
permission o.a.j.security.TabPermission "mytab", "view";
}; ###########

Where do we define these security policies/prinicipals? I am not well-versed with JAAS - so please excuse my ignorance, if these questions are too fundamental. I could provide more details, if required.

Your comments/answers are much appreciated.

Thanks
- Prashanth

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

Reply via email to