OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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 

"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.



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
>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
>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,
>"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>
>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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC