General
The authorization concept used by the ABAP AUTHORITIY-CHECK command implies that some administrator grants rights to groups of users. In many cases, however, it is desirable to let a user decide on their own to whom they want to grant access to the object they are working on. This requirement is met by access control lists (ACLs). This ACLs could be used by the Document Management Systems.
ACLs contain information on activities that are granted / not granted to authorization holders. Authorization holder types used in this ACL implementation are:
- individual users
- user groups
- organizational units and
- user roles from the R/3 role management
Authorizations are checked in the sequence indicated above starting with users. There are two hierarchies that have to be considered. First, there is a
hierarchy of activities, secondly, in case the application objects are part of a hierarchy, authorizations are inherited from superior objects.
This ACL implementation by default knows activities “admin”, “delete”, “write”, “read”and “none”, the latter explicitly denying access to certain objects. Activity
“own” comprises “write” and activity “write” comprises “read”. Thus, if authority checking is performed for activity “read”, the user will be granted the read authorization if he or she has the “own” or “write” authorization for the application object in question.
For each authorization holder type authority checking will check if the user is granted the requested rights in the ACL of the application object’s superior object, if he or she is not granted the rights in the application object’s ACL itself. This procedure is repeated until the top node of the hierarchy is reached.
The design allows for extending allowed activities per object and also allows forhierarchical relationships between activities (as already pointed out above).
Activities
The following activities are concerned:
- Creating, maintaining, copying and deleting of documents
- Managing and working on personal and public document structures and documents
- Sending documents
Authorization groups
It is possible to grant authorizations for any object. Authorizations for a specific user can be granted via 4 holder types:
- user: a user can be assigned directly to an application object
- user group: a user is assigned to a user group – which can be assigned application object
- organizational group: a user is assigned to a organizational group – which is assigned to an application object
- role: a user is assigned to a (backend) role – which is assigned to an application object
For each authorization holder type authority checking will check if the user granted therights in the application object’s ACL itself - then it is checked if the user is granted the requested rights in the ACL of the application object’s superior object. This procedure is repeated until a check is successful. After the top node of the hierarchy is reached the next authorization holder type is proceeded. Sequence of this check: user > user group > organizational group > role. This means that the different authorization holder types have different priorities in case a user is assigned several holder types.
Authorizations
The following authorizations could be selected by using the ACLs for Document Management Systems.
AuthorizationObjectDescription| Admin | Document/Folder | This authorization includes displaying, changing, renaming, copying and deleting of the object.
The owner defines the authorizations of other users at the moment of creating. |
Aurhorization |
Object |
Description |
DeleteFol |
Folder |
This authorization includes the deletion of the whole folder. |
Delete |
Document |
There it will be possible to delete a document (DIS). |
WriteFile |
Document/Folder |
This authorization includes the creation, deletion and change of originals, also the change of metadata. |
Write |
Document/Folder |
The authorization ‚write’ describes the change of a document or a folder, but not the deletion of these objects. |
DelChild |
Folder |
In this case it is possible to delete documents in a document structure. |
CreateDoc |
Folder |
The authorization ‚CreateDoc’ manage the Creation of a document (including originals) and the Creation of subfolders. The authorization will be assigned by the parent folder of the subfolder ort he document. |
ReadFile |
Document/Folder |
There it will be possible to display the metadata and originals of a document. |
Read |
Document/Folder |
There it will be possible to display the metadata and the structure of a document or document -structure. |
NoAuth |
Document/Folder |
The user has no authorization. |
Inheritance
It will be checked for every user if he has the corresponding authorization on the object. If there is no corresponding authorization, the authority check passes through all parent objects. If there were no authorization found in the hierarchy, the user has no authorization.
By creating a new document (DIS) every document gets an own ACL, because the local ‘admin’ authorization should be implemented. This means that the owner of a document has the admin authorization of this. Only with the Admin authorization it will be possible to change the authorization of the document.
The authorizations will be inherited from the parent object to the subordinated objects until the node where the authorizations will be overwritten. The authorization of the authorizations group will be inherited on the same way. The authorization of a role will be inherited to the organizational unit, these goes through the customer specific user group and then through the user. The user, which is related to a role, gets the authorizations of this role. If there are two local authorizations f. e. one for the role and one for the user the more comprehensive authorization will be selected.
In Summary, one can say that the authorizations will be inherited top – down. They can be overwritten at the subordinated objects.
By using links the ACL of the origin document will be selected, expect when the link has an own ACL.
