WSRP Security minutes 5/15

Attendees: Mark Cassidy, Jeff Broberg, Yossi Tamari, Adam Noland, Andre Kramur, Petr Palas, Thomas Schaek, Alejandro Abdelnur, Rich Thompson

Agenda:

Discussion of requirements related to access control and roles.

- The concept of roles was introduced in the context of allowing portlets to have their own access control mechanism. A common case is that a portlet provides some administrative function for editing the portlet’s configuration that exposes different parameters depending on the role of the user performing the edit function.

Another scenario could be a portlet that processes a purchase order; in this case the portlet might define levels of purchasing authority in terms of purchasing roles. A service request to this portlet would include role information for the end user which would be used by the portlet to determine whether the purchase order is processed or not.

Key discussion points:

1. Should WSRP support the ability for portlets to implement these types of access control functions?

Nobody suggested that this type of functionality should not be supported.

2. Should WSRP define standard roles?

Considerable debate over this. Several felt that without some standard names/semantics, roles would be problematic. Suggestion that we define some basic roles to prevent the situation where different portal implementations make different assumptions about roles which could result in the portlet not being interoperable across portal implementations. It was also argued that a proliferation of producer-defined roles would be difficult to support by portals.

Petr suggested some possible standard role definitions:

- administrator: access/modify basic/global settings

- editor: edit configuration settings(?)

- reader: views a portlet’s markup

The other side of the argument was that we should not call out specific role definitions. 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.

Alejandro stated that this issue was examined in JSR168 and that no standard roles were going to be specified as part of that initiative.

It was proposed that portlets be able to define their own roles in their metadata, and that portals should provide a means to map users/groups/roles known to the portal to the roles defined by the portlet. The portal would pass the appropriate role to the portlet with each service request based on the mapping established for the current user. In the case where the portlet defines roles but the portal can not assert them, it may still be possible to have integration but there could be a reduced level of functionality in this scenario.

After further discussion, a consensus emerged around the latter scenario. This is consistent with the direction of JSR168. One issue for additional consideration is how to ensure that role descriptions are clear and unambiguous, such that a portal administrator will know exactly what capabilities they are granting portal users through portlet role mappings.

There was additional discussion surrounding a suggestion by Alejandro that there be separation of interfaces and roles for administrative vs. non-administrative usage. Argument was that there could be cases where someone configuring an administrative setting on a portlet should not have access to the portlet’s content output if the nature of the content is highly sensitive, and having separate interfaces for administrative interaction with the portlet would be provide more security. General consensus was that:

a) this scenario could be accommodated with a single interface and appropriate role partitioning and access control enforcement by the portlet

b) single interface for invoking administrative and non-administrative actions did not pose a significantly increased security risk

3. Discussion closed on the issue of how to make it as easy as possible for portlet authors to implement the most common access control case, which is to differentiate access to administrative functions(mainly setting configuration parameters).