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


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






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


Powered by eList eXpress LLC