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. A role definition can be:

• unlimited (i.e. administrator - can invoke any service method operation)
• limited (i.e. based on properties of the resource )

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 limited 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)

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. (Note: the latter has to be thoroughly checked by Torsten, as Natasa is not certain about the exact reasoning for policies).
• 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

Architecture and alternatives

See more at Authorization architecture in eSciDoc

ToDo: Nice to 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