[wsia][security] WSRP Security minutes from 5/22 telecon

[Rich Thompson <richt2@us.ibm.com>]

----- Forwarded by Rich Thompson/Watson/IBM on 05/23/2002 08:05 AM -----
                                                                                                                    
                      "Cassidy, Mark"                                                                               
                      <mcassidy@Netegri        To:       "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>  
                      ty.com>                  cc:                                                                  
                                               Subject:  [wsrp][security] minutes from 5/22 telecon                 
                      05/22/2002 10:24                                                                              
                      PM                                                                                            
                                                                                                                    
                                                                                                                    



are attached.

To continue the discussion where we left off in the telecon, we're trying
to
identify use cases for standard access control roles.  One approach is to
take an inventory of what the access control roles are that various portal
products understand and see if there are any commonalities.   Following is
a
summarized view of the access control roles that Netegrity's portal
understands relating to portlets, and behavior associated with these roles.
Others in WSRP who have portal products, please share your views on this so
we can determine whether there's enough in common to consider standardizing
any specific roles.

1.  Portal administrator:
  - installs/uninstalls and categorizes portlets(i.e. portlet types)
  - configures portlet parameters that are global to all instances
  - grants permissions to create portlet instances
  - delegates control of configuration/permissions settings to others

2. Owner/Page designer:
  - creates portlet instances on portal pages
  - has full control over the instance, including:
             o delete the instance
             o default parameter settings(non-global parameters)
             o grants permissions to view the instance, modify its
settings, and
delegating control of these functions to others

3. Instance administrator:
  - can view the instance
  - can modify settings & permissions as delgated by Owner.

4. Viewer:
  - can view the portlet's content.  May or may not be able to personalize
depending on permissions granted.
 <<wsrp security minutes 522.htm>>
(See attached file: wsrp security minutes 522.htm)

Title: Security minutes 5/8

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.