[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 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> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC