understanding security roles

[Ken Weiner <kw...@unicon.net>]

David,

My request to make the security roles configurable within the 
TestPortlet may not have been necessary.  The reason I wanted the 
configuration was because I thought that the role values would have to 
change depending on the roles available in the portal driver.  After 
rereading the portlet spec, my understanding now is that during 
deployment, the web.xml file should be modified to contain a 
security-role-ref element which maps a local role to the security-role 
configured in the web.xml that comes with the portlet.

So for example, if I want the Security Mapping Test to pass and the user 
has a role within my portal driver of "portletTester", I would keep the 
expectedResults.properties and the portlet.xml as is, and during 
deployment I would change the web.xml by adding the element:

<security-role-ref>
     <role-name>tomcat</role-name>
     <role-link>portletTester</role-link>
</security-role-ref>

Then the portlet code should return "true" for all of these calls:

req.isUserInRole("plutoTestRole") // the mapped role within portlet.xml
req.isUserInRole("tomcat") // the mapped role within web.xml
req.isUserInRole("portletTester") // the role

Am I understanding this correctly?  If not, maybe someone could 
summarize what should happen with respect to portlet code and the 
portlet.xml and web.xml before and after deployment if a portlet author 
wants to exercise an authorization check in his/her portlet code.

-Ken

====
This message and any attachments are confidential. Unauthorized use
or disclosure of this message is strictly prohibited, and this message
must be destroyed immediately if received by an unauthorized recipient.
====

Re: understanding security roles

[Ken Weiner <kw...@unicon.net>]

David,

I have to admit, I'm still a little confused.  I'm trying to put myself 
in the shoes of a portlet developer that 1) wants to check if the user 
is in a certain role and 2) doesn't have any idea what roles are 
configured in the servlet container.  In other words, I want to declare 
a role "myPortletRole" and have that role mapped to a real role 
(understood by the servlet container) at deployment time.

So if I'm the portlet developer and the role I want to check is 
"myPortletRole", would I do this?:

1) Add to portlet.xml (part of authoring the portlet app):

<security-role-ref>
     <role-name>myPortletRole</role-name>
     <role-link>arbitraryServletRole</role-link>
</security-role-ref>

2) Add to web.xml (part of authoring the portlet app):

<security-role>
     <role-name>arbitraryServletRole</role-name>
</security-role>

3) Add to web.xml (as part of deployment)

<security-role-ref>
     <role-name>theRealRole</role-name>
     <role-link>arbitraryServletRole</role-link>
</security-role-ref>

4) Call within my portlet:

req.isUserInRole("myPortletRole");

If I'm not making sense, maybe I can ask in the context of the TestSuite 
portlet.  In that portlet, the portlet author makes up the role 
"plutoTestRole" because he doesn't know what the appropriate role in the 
servlet container will be.  Only the deployer knows this.  When 
deploying the portlet application, the deployer would say "Hmmm, this 
portlet application needs to work with a role of 'plutoTestRole'.  I 
need to map this to am actual role within my container.  I will choose 
the role 'tomcat'.  Is this a reasonable scenario?  If so, I am confused 
about why "tomcat" shows up in the portlet.xml and web.xml in our 
TestSuite since it implies that the portlet developer knew what roles 
were in the servlet container that the portlet will get deployed into.

Thanks in advance to anyone who is willing to think through this with me.

-Ken


David H. DeWolf wrote:
> There are two sets of <security-role-ref> tags to which we are referring.
> 
> 1) Portlet Security Role Reference:
> 
> Maps a web application's security role (as defined by the authentication 
> realm) to the role name which will be used programatically within the 
> portlet.
> 
> 2) Servlet Security Role references:
> 
> Maps a web application's security role (as defined by the authentication 
> mechanism) to the role name which will be used programatically within 
> the servlet.
> 
> The interesting point, which is what I think you are referring to and 
> which I agree with, is that in pluto's implementation these will work in 
> conjunction with one another when a portlet is dispatched through a 
> servlet invocation.  Thus, the following scenario:
> 
> 1) User "U" is identified as having Role "A" by the 
> authentication/authorization provider.
> 
> 2) Pluto's Dispatching Servlet for Portlet "P" is configured to map role 
> "A" to "B" as follows:
> <servlet>
> . . .
> <security-role-ref>
>   <role-name>B</role-name>
>   <role-link>A</role-link>
> </security-role-ref>
> </servlet>
> 
> Thus, any invocation of isUserInRole(String) within the scope of this 
> servlet returns true for both "A" and "B".
> 
> 3) Portlet "P" is configured to map role "B" to role "C" as follows:
> <portlet>
> . . .
> <security-role-ref>
>   <role-name>C</role-name>
>   <role-link>B</role-name>
> </security-role-ref>
> </portlet>
> 
> Thus, any invocation of isUserInRole(String) within the scope of this 
> portlet returns true for "A", "B", and "C" due to the conditions 
> specified in 20.3 of the Portlet Spec:
> 
>   "If the security-role-ref element does not define
>    a role-link element, the container must default
>    to checking the role-name element argument against
>    the list of securityrole elements defined in the
>    web.xml deployment descriptor of the portlet
>    application."
> 
> I'd be interested to know if anyone disagrees with this interpretation.
> 
> Finally, I think the value that your patch adds is that it allows us to 
> configure to TEST to ensure that we are testing exactly what is intended 
> to be tested.  For instance, we want to make sure that the unmapped role 
> test always looks for "A", a role that is defined by the realm but NOT 
> mapped through the role refs -- and thus test's the default behavior 
> described above.
> 
> David
> 
> Ken Weiner wrote:
> 
>> David,
>>
>> My request to make the security roles configurable within the 
>> TestPortlet may not have been necessary.  The reason I wanted the 
>> configuration was because I thought that the role values would have to 
>> change depending on the roles available in the portal driver.  After 
>> rereading the portlet spec, my understanding now is that during 
>> deployment, the web.xml file should be modified to contain a 
>> security-role-ref element which maps a local role to the security-role 
>> configured in the web.xml that comes with the portlet.
>>
>> So for example, if I want the Security Mapping Test to pass and the 
>> user has a role within my portal driver of "portletTester", I would 
>> keep the expectedResults.properties and the portlet.xml as is, and 
>> during deployment I would change the web.xml by adding the element:
>>
>> <security-role-ref>
>>     <role-name>tomcat</role-name>
>>     <role-link>portletTester</role-link>
>> </security-role-ref>
>>
>> Then the portlet code should return "true" for all of these calls:
>>
>> req.isUserInRole("plutoTestRole") // the mapped role within portlet.xml
>> req.isUserInRole("tomcat") // the mapped role within web.xml
>> req.isUserInRole("portletTester") // the role
>>
>> Am I understanding this correctly?  If not, maybe someone could 
>> summarize what should happen with respect to portlet code and the 
>> portlet.xml and web.xml before and after deployment if a portlet 
>> author wants to exercise an authorization check in his/her portlet code.
>>
>> -Ken
>>
>> ====
>> This message and any attachments are confidential. Unauthorized use
>> or disclosure of this message is strictly prohibited, and this message
>> must be destroyed immediately if received by an unauthorized recipient.
>> ====
>>

Re: understanding security roles

["David H. DeWolf" <dd...@apache.org>]

There are two sets of <security-role-ref> tags to which we are referring.

1) Portlet Security Role Reference:

Maps a web application's security role (as defined by the authentication 
realm) to the role name which will be used programatically within the 
portlet.

2) Servlet Security Role references:

Maps a web application's security role (as defined by the authentication 
mechanism) to the role name which will be used programatically within 
the servlet.

The interesting point, which is what I think you are referring to and 
which I agree with, is that in pluto's implementation these will work in 
conjunction with one another when a portlet is dispatched through a 
servlet invocation.  Thus, the following scenario:

1) User "U" is identified as having Role "A" by the 
authentication/authorization provider.

2) Pluto's Dispatching Servlet for Portlet "P" is configured to map role 
"A" to "B" as follows:
<servlet>
. . .
<security-role-ref>
   <role-name>B</role-name>
   <role-link>A</role-link>
</security-role-ref>
</servlet>

Thus, any invocation of isUserInRole(String) within the scope of this 
servlet returns true for both "A" and "B".

3) Portlet "P" is configured to map role "B" to role "C" as follows:
<portlet>
. . .
<security-role-ref>
   <role-name>C</role-name>
   <role-link>B</role-name>
</security-role-ref>
</portlet>

Thus, any invocation of isUserInRole(String) within the scope of this 
portlet returns true for "A", "B", and "C" due to the conditions 
specified in 20.3 of the Portlet Spec:

   "If the security-role-ref element does not define
    a role-link element, the container must default
    to checking the role-name element argument against
    the list of securityrole elements defined in the
    web.xml deployment descriptor of the portlet
    application."

I'd be interested to know if anyone disagrees with this interpretation.

Finally, I think the value that your patch adds is that it allows us to 
configure to TEST to ensure that we are testing exactly what is intended 
to be tested.  For instance, we want to make sure that the unmapped role 
test always looks for "A", a role that is defined by the realm but NOT 
mapped through the role refs -- and thus test's the default behavior 
described above.

David

Ken Weiner wrote:
> David,
> 
> My request to make the security roles configurable within the 
> TestPortlet may not have been necessary.  The reason I wanted the 
> configuration was because I thought that the role values would have to 
> change depending on the roles available in the portal driver.  After 
> rereading the portlet spec, my understanding now is that during 
> deployment, the web.xml file should be modified to contain a 
> security-role-ref element which maps a local role to the security-role 
> configured in the web.xml that comes with the portlet.
> 
> So for example, if I want the Security Mapping Test to pass and the user 
> has a role within my portal driver of "portletTester", I would keep the 
> expectedResults.properties and the portlet.xml as is, and during 
> deployment I would change the web.xml by adding the element:
> 
> <security-role-ref>
>     <role-name>tomcat</role-name>
>     <role-link>portletTester</role-link>
> </security-role-ref>
> 
> Then the portlet code should return "true" for all of these calls:
> 
> req.isUserInRole("plutoTestRole") // the mapped role within portlet.xml
> req.isUserInRole("tomcat") // the mapped role within web.xml
> req.isUserInRole("portletTester") // the role
> 
> Am I understanding this correctly?  If not, maybe someone could 
> summarize what should happen with respect to portlet code and the 
> portlet.xml and web.xml before and after deployment if a portlet author 
> wants to exercise an authorization check in his/her portlet code.
> 
> -Ken
> 
> ====
> This message and any attachments are confidential. Unauthorized use
> or disclosure of this message is strictly prohibited, and this message
> must be destroyed immediately if received by an unauthorized recipient.
> ====
>