[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][security] minutes from 5/15 telecon
>What we need to discuss is how can the portlet have access control to its >internal functions, ones that are not at the WSRP level, but are governed by >different actions and "portlet modes". The most obvious example for this is >setting specific portlet configuration parameters. I guess I think of setting portlet configuration parameters as being 'at the WSRP level' since this is common to all portlets. Other actions/modes that are portlet-specific I would think would not be good candidates for standard role definitions. >Lastly, my suggestion is that we do not strongly define the "meaning" of the >standard roles, but just set a general understanding that there is a >standard concept of portal administrator, and leave each vendor to define >what this role means in its environment. If we don't have a clear and unambiguous definition of what it means for someone to have a particular role, then what is 'standard' about this and where is its value? -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com] Sent: Monday, May 20, 2002 10:35 AM To: 'Cassidy, Mark' Cc: 'wsrp@lists.oasis-open.org' Subject: RE: [wsrp][security] minutes from 5/15 telecon Hi Mark, I do not think we need to standardize on the WSRP interface functions access control. These operations can easily be handled by the consuming portal. What we need to discuss is how can the portlet have access control to its internal functions, ones that are not at the WSRP level, but are governed by different actions and "portlet modes". The most obvious example for this is setting specific portlet configuration parameters. In this context it seems to me many portlets will be satisfied with two levels of users: admins who can set parameters, and normal users who can not, but can view the resulting markup. Of course, there will also be many portlets that will need more granularity, where perhaps each configuration parameter requires a different role membership. It is also important we remember that each user can be a member of many roles, and the portal will have to pass a list of the relevant roles to the portlet, since, for example, the administrator role may be allowed to set configuration parameters, but not to actually view the markup. Lastly, my suggestion is that we do not strongly define the "meaning" of the standard roles, but just set a general understanding that there is a standard concept of portal administrator, and leave each vendor to define what this role means in its environment. Yossi. -----Original Message----- From: Cassidy, Mark [mailto:mcassidy@Netegrity.com] Sent: Monday, May 20, 2002 8:12 PM To: 'Thomas Schaeck'; Cassidy, Mark Cc: 'wsrp@lists.oasis-open.org' 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>> ---------------------------------------------------------------- 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