[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