ESciDoc Authorization Authentication

Please use this page to discuss in general on the authorization mechanisms for core services, solutions etc.

Core services

Core services authorize each method of a core service based on a role definition and additional default policies. A role definition consists of a set of policies, defining the user's privileges, and a definition of its scope, i.e. for which resources the policies of the role have to be evaluated. A role definition can be:

• unlimited, i.e. the role is valid for each resource (e.g. system-inspector - can invoke any retrieve method operation).
• limited, i.e. the role is valid for a defined set of resources (e.g. depositor - can invoke service methods for containers and items of a specific context)

Here, unlimited does not mean, any operation is allowed for any resource, but defines the scope of the role, only: Any resource is in the scope of a unlimited role. I.e. if a user requests access to a resource and a unlimited role has been granted to the user, the policies of this role have to be evaluated for request authorization. If a limited role has been granted to the user, the policies of this role only have to be evaluated, if the resource is part of the scope, e.g. it is an item of the context for that the user has a grant for the role.

More details on the core service authorization concept in svn, framework_release, cpt_authorization_authentication

Predefined Roles

At present there are several pre-defined user roles for core services i.e. author, moderator, editor, etc. These roles are in general derived from some basic requirements of the solutions for PubMan and SWB.

A role for the core services is specified as a set of (Resource, Action, Conditions):

• Resource - a resource or subresource (e.g. Item, Item.Component, Item.Metadata, Context) on which an action is executed, where an action is actually a core service method
• Action - an action executed on a resource (e.g. create <resource>, update <resource>, create <subresource>, etc.)
• Conditions - a condition that a resource or a user that is executing the action must fulfill (e.g. Item.status=pending and Item.context = user.isDepositor(context)) etc. (Please consider these as "pseudo" expressions, as the real expressions are written in form of a XACML policy)

For more complete description of the predefined roles, see eSciDoc User Roles and ESciDoc Admin Roles

Default Policies

The default policies define privileges that any user, even the anonymous user or a user without any granted role, has. These are:

• Retrieving released container versions.
• Retrieving released item versions.
• Retrieving contexts in public-status "opened".
• Retrieving binary content of an item version's component if the item version is in state "released", the component is in state "valid", and the component's visibility is "public".
• Retrieving organizational units in public-status "opened" and their children and parent list.
• Retrieving content models.
• Unlocking containers and item that the user has locked.
• Retrieving his/her own user account.
• Retrieving grants of his/her own user account.
• Querying the semantic store (for logged in users, only).

Solutions and other services

Solutions use core services or provide own services that also need to be authorized. The predefined roles or core services at the moment are more close to the Solution specific roles (especially PubMan solution). For example, PubMan has roles such as "Depositor", "Moderator", "MDEditor" (these roles are currently among those predefined within the core infrastructure). But, already within the upcoming releases and introduction of the workflow engine, the actions specified for the roles will have to be "aligned" with the workflow actions i.e. the roles will probably have to be defined for a workflow rather than for a core service method. A workflow action can thus invoke one or more core service methods on several resource handlers.

Glossary

To be able to understand the basic set-up of the current authorization mechanism we need to understand the following terms:

• Role represents a set of actions that can be performed on some resource in accordance with defined conditions e. g. update an item in a context if the item status is "pending".
• Grant object represents the role with which user is granted for specific resource. It is realized by creating a "grant object" and associating it with the user account e.g. a reference to a Context in case of a Administrator grant or a Metadata-Editor grant. Additionally, a grant stores information for the traceability of granting and revoking roles.
• Policy is implemented XACML Policy. Each Role has one or more policies depending on the resource and actions. A policy is defined for a role, resource and set of resource attributes. A policy exclusively belongs to a single role.
• Resource - a resource on which an action is executed e.g. Item, Container, Item.component etc.
• Action - an action that is triggered e.g. create-item, update-item etc.
• Subject - user that is performing a certain action
• Attribute - a property or attribute of the resource that has a certain value. This value is included as a "condition" check when evaluating the right of the subject (i.e. user) to perform an action on a certain resource e.g. status of the item, context of the item etc. These attributes are defined in the XACML policy definition.
• Policy Decision Point (PDP) - a software component that evaluates the policies and decides if a request can be authorized
• Policy Enforcement Point (PEP) - a software component that secures the access, builds authorization decision requests that are sent to the PDP, and enforces the authorization decision

Requirements

• see ESciDoc_Authorization_Requirements

Architecture and alternatives

See more at Authorization architecture in eSciDoc

ToDo: check what NIST have came up with (a loong document that needs reading) Guide to Secure Web Services

Publication Management

Scholary Workbench

eXtensible Access Control Markup Language