WSRP Security minutes 5/22
Attendees: Mark Cassidy, Dave Clegg, Joseph Stanko, Mike
Freedman, Jeff Broberg, Yossi Tamari, Thomas Schaek, Alejandro Abdelnur, Rich
Thompson, Carsten Leue
Agenda:
1.�
Restate goal we're trying to achieve in supporting access control roles
in WSRP
We had general consensus around the following
the following statement:
�Roles allow portlets to exercise control over
portlet-specific behavior for specific classes of users.��
2.�
What kinds of access should portal be enforcing vs the portlet
enforcing:
Mark initiated the discussion with an
assertion that the portal needs to exercise access control over who can perform
actions such as create a portlet instance, view an instance, modify parameters,
etc.
Alejandro & Mike provided some clarity by
introducing the distinction between �declarative� and �programmatic� access
control, as follows:
�
Declarative
access control applies to the entry point into a portlet function.
�
Programmatic
access control applies to behavior internal to a specific portlet function; in
this case, two different users may have access to the function�s entry point,
but may be differentiated within the function based on a role they are
associated with.�
We discussed the idea that portals provide
declarative-type access control, and that portlets provide programmatic access
control.� General consensus around this
idea.� Thomas further pointed out that
if a portlet were to describe in it�s metadata roles associated with invocable
functions(i.e. the function entry points), there would be redundancy in access
checking and no value in the portlet checking for a role that the portal
already assured was present for the current user.� There could, however, still be valid reason for the portal to
assert the role if the portlet also uses the role to generate differentiated
markup(which really crosses over into programmatic access control).
Jeff pointed out that it is common for
portals to add �decorations� around a portlet�s markup(titlebar, border, etc)
that provide functions like minimize, etc.�
He posed a question about the scenario(for example) where the portlet
implements an �Edit Mode� interface:��
would that accessed through these decorations or via a link that is
drawn from the portlet�s markup, and how would access to this interface be
controlled in each case?�
Rich stated that the latter is similar to the
WSIA �customize� case where the consumer(portal) wants to customize some
portion of a producer�s content(rendering of �edit mode� button in this
case).� Suggested we could use roles to
achieve a lighweight customization for this specific case.�
Discussion concluded that either case is
valid:� if accessed from the
decorations, the portlet metadata includes the existance of this function and
the portal can draw access to this function in the decorations based on the
access policies set by the portal administrator.� If the portlet renders access to this function in it�s markup,
the portlet metadata could define a role required to access this function, and
the portal would assert this role with requests to get the portlet�s
markup.� The portlet could then
customize the content output based on the role assertions for the current user.
Dave raised a question about whether
asserting access roles along with the service request is the right way to approach
programmatic access control.� Suggested
an out-of-band approach where the a separate service associated with the
portlet would be responsible for access decisions, and that this service would
communicate back to the portal to get information about the current user.� Some discussion about why that was more
desirable than including role assertions along with the service request.� No conclusions/decisions were reached on this.
3.�
What are the goals and use cases for having standard role definitions.
Mike suggested that standard roles might
reduce the burden of an administrator having to perform role mapping between
portal and portlet roles at portlet bind time.�
Interoperability across portals was another concern.��
Time ran out before we could identify clear
use cases for standard roles.� We agreed
to continue this discussion in the email forum, with each portal vendor
contributing the roles their portals understand to see if there is any
commonality or use cases where having standard role definitions would have
value.