[OASIS Issue Tracker] (CAMP-217) Use cases for "Row Filtering"

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CAMP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63421#comment-63421 ] 

David Laurance commented on CAMP-217:
-------------------------------------

There are two families of filtering use cases. Exemplars below:

> Usability:  A management user wants to show only Assemblies that originate from a given Plan.

The filtering attribute ("plan") is available from the Assembly resource, and therefore filtering is a matter of pattern matching against that attribute. Note that the Assembly refers to the Plan by URI, and this can be relatively opaque. 

A management user may prefer to filter on the Plan name rather than on the URI, but even filtering on the URI will meet the simplest requirement for filtering.

In our discussions, we recognize that there are challenges in filtering on attributes that are not directly in the resources being retrieved.  For example, when selecting Assemblies, the Plan name is associated not with the Assembly but with the Plan.  This may affect implementation choices, but does not materially affect the requirement.

> Authorization: A management user is allowed to see a subset of Assemblies; the CAMP Provider must not deliver information about Assemblies for which the management user does not have appropriate access permission.

Authorization requirements are complex by nature and cannot be resolved in a general way within the current CAMP specification. Existing implementations of the CAMP specification (e.g., Pantheon) have implemented partial solutions for this family of use cases, restricting visibility based upon user role and permissions. End user identity is communicated between CAMP Consumer and CAMP Provider. The permission decision and filtering of results are implemented within the CAMP Provider. Results are returned to the CAMP Consumer based upon the identified user's permission.



> Use cases for "Row Filtering"
> -----------------------------
>
>                 Key: CAMP-217
>                 URL: https://issues.oasis-open.org/browse/CAMP-217
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>            Reporter: David Laurance
>            Assignee: Gilbert Pilz
>            Priority: Minor
>
> Use cases for filtering collections can be broken into three groups
> 1. In displaying a long collection, an end user may want to filter on some attribute or attributes of the collection elements: 
>     * As a cloud administrator, I want to view only the Assemblies that are currently in an Active state. 
>     * As a cloud administrator, I want to view only the Assemblies that were created from a specific Plan. 
> (Note that for smaller Cloud installations, Sort functionality will provide an adequate substitute for use cases in this category.) 
> 2. In displaying a long collection, a user may want to filter elements on attributes that are not directly available from the elements; for example, filtering Assemblies based upon attributes associated with their corresponding Plans.
>     * As a cloud administrator, I want to view Assemblies that trace to a specific Plan version.
> 3.  In order to meet data visibility requirements, a provider may be required to filter collection elements to reflect visibility rules, and show only those elements that a user is allowed to see. 
>  In this case, visibility is not requested by the user, but rather it is determined by the server, based upon the user identity or other user attributes. 
> We have agreed that ownership of collections will not be managed within the CAMP model. If ownership or other permission attributes are required, they must be associated with collection elements by a separate mapping or mechanism, and any policy engine or other access control mechanism must understand and use that mechanism. 
>  However, note that the server must be able to determine the user identity or other user attributes in order to evaluate and enforce access control rules. If requests are truly stateless, this will mean that user attributes (at a minimum, user identity) must be provided in the user's request for the collection. If session state is maintained so that the server can track a session across requests, then it is possible for the server to authenticate a user in a separate interaction and rely on session identity to track the user and authorize user access. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)