com.sapportals.wcm.protocol.webdav.repository.acl

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

SAP NetWeaver 7.30 SP01 KMC

PREV PACKAGE NEXT PACKAGE

FRAMES NO FRAMES

Package com.sapportals.wcm.protocol.webdav.repository.acl

Maps WebDAV ACL concepts onto the WCM IResourceAclManager and friends interfaces.

See:
Description

Interface Summary
IAce	Represents a single grant or deny of a set of `IPrivilege`s, a Access Control Entry (part of an Access Control List, see `WDAcl`).
IPrivilege	Represents a DAV:privilege as defined in WebDAV Access Control Protocol.

Class Summary
WDAcl	Handles all information related to WebDAV ACL handling for a resource.
WDPrivilege	Default implementation of `IPrivilege`.
WDPrivilegeTree	Represents a tree of DAV:privilege as defined in WebDAV Access Control Protocol.

Exception Summary
AclPreconditionException	Information about a failed ACL precondition.
MissingDavPrivilegeException	Exception used to indicate the missing DAV privilege DAV:write-acl Copyright (c) SAP AG 2002

Package com.sapportals.wcm.protocol.webdav.repository.acl Description

Maps WebDAV ACL concepts onto the WCM IResourceAclManager and friends interfaces.

WCM com.sapportals.wcm.protocol.repository.manager.security.IResourceAclManager provides one flavour of SecurityManagers for controlling access to repository resources. The WebDAV ACL protocol specifies ways to read and modify access control lists on WebDAV resources. The concepts of WebDAV ACL and WCM are closely related, however there are also significant differences. The job of this package is to bridge these two concepts.

Central access point to all ACL handling is the WDAcl class. A WDAcl is constructed for a com.sapportals.wcm.protocol.repository.IResource. All information can be then retrieved and modified from WDAcl.

The relation between the public classes of this package is as follows:

A WDAcl can be constructed for every IResource.
A WDAcl keeps a list of IAce objects.
IAce objects keep a list of IPrivileges, granting or denying these IPrivileges to a certain user.

Implementation Notes

Goals

As discussed further below, the biggest difference between WCM and WebDAV ACL concepts are found in DAV:Privileges vs. WCM IPermissions. WCM has a quite detailed, extensible permission model, while WebDAV has a quite simple, yet also extensible privilege model.

The goal of this package is to allow WCM-aware clients, to use the full granularity of the WCM permissions. At the same time, generic WebDAV clients, which only care about the WebDAV standard privilege model, should work as well.

As a result, whenever possible, WCM permissions are reported as standard DAV:privileges.

DAV:principals

DAV:principals match directly to com.sapportals.wp.security.usermanagement.IUMPrincipal objects and can be users or groups. The href for the principal is generated from an UIMPrincipal with the help of the com.sapportals.wcm.util.urlgenerator.IURLGenerator.

DAV:all is mapped to the predefined group everybody. The principal DAV:unauthenticated is mapped to the predefined user anonymous. The DAV:principals DAV:authenticated, DAV:self and DAV:property are not supported.

DAV:owner

In WebDAV ACL, every resource has an owner, implicitly assuming that the owner of a resource has non-removable rights to change the access control list.

Resources in WCM do not have an owner, however com.sapportals.wcm.repository.manager.security.IResourceAcl does keep a list of owners (instances of com.sapportals.wp.security.usermanagement.IUMPrincipal).

The acl package maps the first owner of the IResourceAcl to the DAV:owner of a resource. This works well, if there is only one owner of the IResourceAcl. However, since the list of owner has no defined sorting order, this is not overly well defined, when there is more than one owner.

DAV:Privileges and `com.sapportals.wcm.util.acl.IPermission`s

The biggest differences are between WebDAV's privileges and WCM's IPermissions. DAV:privileges build a hierarchy, while IPermissions live in a flat space.

DAV:privilege	IPermission
all	FULL_CONTROL
read	READ, LIST
write	WRITE, WRITE_CONTENT, WRITE_PROPERTIES, CREATE, DELETE, ADMIN_*
read-acl	-
write-acl	owner

Reporting of ACLs

The acl packages reports IPermissions under their name in the sap namespace. Thus, the IPermission READ would be reported as {urn:schemas-sap-com:wcm}read.

DAV:privileges are reported, when all aggregated IPermissions are specified in access control entries for a certain principal. The reporting of all the aggregated IPermissions is then skipped.

Example:

a certain principal is granted the IPermissions READ and LIST in the IResourceAcl of a resource. The DAV:acl property of that resource would then report the privilege DAV:read for that principal, but would not report the {urn:schemas-sap-com:wcm}read and {urn:schemas-sap-com:wcm}list privileges.
All owners of a IResourceAcl would be listed having the DAV:privilege DAV:write-acl.
All principals which have all existing IPermissions granted, would be reported as having the DAV:privilege DAV:all.

Setting of ACLs

The reverse behaviour applies when the ACL is set via WebDAV. It is certainly possible to set each individual IPermission directly by specifying the privilege from the {urn:schemas-sap-com:wcm} namespace.

Setting of a DAV:privilege, like DAV:read, however will result in all aggregated IPermissions (like READ and LIST) to be set on the IResourceAcl. Setting of DAV:write-acl for a principal will result in that principal being added to the owner list of the IResourceAcl.

The DAV:read-acl privilege cannot be set in an ACL and is marked abstract in the DAV:supported-privilege-set.

DAV:acl-semantics

The simulated semantics on ACLs are: DAV:first-match, no particular ordering, no principal-only-one-ace, grant-only depending on the capabilities of the IResourceAclManager and no required principals.