Re: [wsrp][security] minutes from 5/15 telecon

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

Mark, Thomas,

My understanding after the conference call was that we agreed that a 
portlet would define a set of logical roles it supports and they would 
be mapped at binding time to a set of operational roles. Then, it would 
be the responsibility of the administrator to do a valid/correct mapping 
between the logical roles defined by the portlet and the operational 
roles of the portal/consumer.

As it was pointed out during the discussion and it was captured in the 
minutes:

"Dictating specific role behavior would be more or less arbitrary, and 
this would be too constraining and inflexible. Any given portlet could 
have a need for roles that are unique to that portlet and for which it 
doesn't make sense to define a standard"

For example, having a single administration role would not work in an 
environment where there is delegated administration and this delegation 
is partial (administrators with less power than others).

I would see as part of the WSRP spec a set of recommendations or best 
practices on how to name roles. In addition, the logical role definition 
should include a description that defines the role purpose and 
application scope.

We may need to spend more time on this matter.

Regards.

Alejandro


Cassidy, Mark wrote:

>Thanks for the correction Thomas.   I agree, we left it that a
>portlet-defined mechanism was desirable but that it could in fact co-exist
>with standardized roles as well.  We didn't get very far into specifics of
>what/how standard roles would behave however.
>
>The central point of the debate I believe is around access control semantics
>associated with standard roles.   I think of anonymous/authenticated user as
>being more of an authentication assertion, since that fact alone doesn't
>carry any access control semantics.  We do have requirements captured
>related to communicating authentication status from portal to portlet.  I
>suppose one could think of these as roles but without any access control
>implied.  Are you thinking we should also associate access control behavior
>with these two states?  If so, what would you propose?  
>
>Portal administrator, on the other hand, typically implies broad access to
>configure portal/portlet functionality and view portal/portlet contents.  We
>would need to agree on some access control semantics for portal
>administrator.  Unrestricted access to all portlet functions?  Something
>different?
>
>Seems like the most unambiguous way to define standard roles is to associate
>roles with fundamental actions that are directly tied to the WSRP protocols.
>For example, we could associate roles with executing:
>- create/delete instances
>- set configuration parameters
>- view content
>- ...
>
>One of the most common use cases for roles is distinguishing who is allowed
>to set which parameters of a portlet.  Seems that if we're going to tackle
>defining standard roles and their access control semantics, we need to
>address this common case.  Defining a role for 'set configuration
>parameters' is not sufficient since it wouldn't differentiate access for
>specific parameters.  In order to support something like this, seems like
>we'd need per-parameter metadata describing which role is required to set
>each parameter. 
>
>Here is one possible way to define standard roles and a set of semantics
>associated with them.  This is not meant to be complete, only a starting
>point for refinement:
>- administrator:  this role can execute any functions on the interface.
>This role would typically perform the initial bind and set template-level
>parameters for each template created in the portal. 
>- owner:  this role can create/delete instances, and modify all non-template
>parameters of instances they create
>- personalizer:  this role can modify instance parameters that are
>designated "personalizable"
>- viewer:  this role can only view the portlet's content.  
>
>I think we need to step back for a moment though and answer a basic question
>related to standardized roles:  whose job would it be to enforce access
>control associated with standard roles?  If we make it the portlet's job,
>that will increase the burden on portlet authors.  If we make it the
>portal's job, do we really need to specify how the portal should do this(the
>portlet wouldn't care; it would just receive already-authorized requests to
>perform some action)?
>
>I'd like to see some more discussion around these concepts.  I personally am
>not necessarily biased against having standardized roles, but there are
>still a number of open issues that need to be addressed.
>
>
>-----Original Message-----
>From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
>Sent: Sunday, May 19, 2002 11:16 AM
>To: Cassidy, Mark
>Cc: 'wsrp@lists.oasis-open.org'
>Subject: Re: [wsrp][security] minutes from 5/15 telecon
>
>
>Mark,
>
>thanks for the minutes.
>
>I have one important remark - there was no consensus that we should not
>define a set of standard roles. At least Petr Palas and I think that a set
>of basic standard roles should be defined.
>
>Some roles to consider are these:
>anonymous user
>authenticated user
>portal administrator
>Defining these basic roles would allow that portlets that restrict
>themselves still plug & play with portal servers without requiring manual
>role mapping by administrators.
>
>Also, I believe there was a discussion point about something like "implicit
>roles" e.g. "somebody who may edit the portlet", "somebody who may view the
>portlet" ...
>
>Best regards,
>
>Thomas
>
>
>"Cassidy, Mark" <mcassidy@Netegrity.com> on 05/18/2002 08:21:17 PM
>
>Please respond to "Cassidy, Mark" <mcassidy@Netegrity.com>
>
>To:    "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
>cc:
>Subject:    [wsrp][security] minutes from 5/15 telecon
>
>
>
>  
>
>>attached are minutes from this week's telecon.
>>
>> <<wsrp security minutes 515.htm>>
>>    
>>
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>