Authorization Service Description and Assumptions

Unknown macro: {multi-excerpt} The authorization service provides the means to authorize a system entity to use system resources. It also provides control over access to those resources by system entities.

Unknown macro: {multi-excerpt-include}

Unknown macro: {multi-excerpt}

Let's define some terms regarding authorization and access control to understand what is required (in security context) to perform an access control on a resource in CollectionSpace. We are relying on Internet Security Glossary and XACML glossary to define these terms.

Authorization is the process by which a properly appointed person or persons grants permission to perform some action on system resources on behalf of an organization.

Access control means protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy.

Resource could be data, service or system component (e.g. CollectionObject, Collection X of musuem, etc.)

Access control policy is a set of rules. A policy may identify the set of roles that are permitted to perform a particular action on a resource.

Subject is an actor whose attributes may be referenced by a predicate in a rule. One such attribute could be a role (e.g. CollectionsManager, Curator or Researcher).

Role is an abstract logical grouping of users that is created by the application/system users. A role could be a functional position in an organization.

Unknown macro: {multi-excerpt}

Issue: Identifying a tenant(s) at the time of login

As discussed in Account Provisioning, each user is associated with one or more tenant. This information is retrieved as soon as the login is successful but before any CollectionSpace service related operations are performed. This information is kept in the security context. In case where user is associated with more than one tenant, the user would have access to collections of those tenants using the same session.

More restricted case would be where user could choose to operate on a single tenant's collection.

Unknown macro: {multi-excerpt}

Once the authentication is successful, the security context should contain tenant-qualified information about the authenticated principal. The CollectionSpace [Authorization Service] should make sure that the context is tenant-qualified post authentication.

Java Subject - some background

In Java, the security context could be in the form of a Subject if JAAS framework is used for authentication. A subject may be any entity, such as a person or a service. Once the subject is authenticated, a Java Subject is populated with associated identities, or principals. A Java Principal could represent any entity, such as an individual, a corporation, and a login id. A Subject may also own credentials. Sensitive credentials that require special protection, such as private cryptographic keys, are stored within a private credential Set. Credentials intended to be shared, such as public key certificates, are stored within a public credential Set. Access to credentials is provided based on permissions.

Security context in the form of a Subject is made available by the Java Application Server to application (mostly, attached to the thread context) once the authentication completes.

CollectionSpace Tenant Group

The CollectionSpace security runtime could further populate the Subject with tenant-specific information post successful authentication. This information could be in the form of a special group called "Tenants". Each member of this group would represent a tenant to whose resources the user principal would have access to. This context could then be used for the following purposes.

1. Retrieve [tenant-specific bindings] in order to process the service request
2. Enforce access control policies/permissions (using roles implemented as groups)

Unknown macro: {multi-excerpt}

Issue: Role ambiguity

In a multi-tenant system such as CollectionSpace, resources could be divided into the following two categories:

1. System specific resources, e.g database, files, administration console, etc.
2. Resources "owned" by a tenant, e.g. Collection "A" owned by ucmp.berkeley.edu.

There could be three kinds of roles.

1. System-defined roles (e.g. SystemAdmin) having access to all the resources (e.g. Collections) including those belonging to individual tenants.
2. Tenant-specific roles having access limited to resources owned by an individual tenant only.
3. Then there would be some roles that would have access to resources owned by more than one tenant. (e.g. bnhm-administrator would have access to collections of all Berkeley museums). Such a role could be a container of "tenant-specific roles".

Also, there would be three kinds of policies.

1. Policies that are system-specific, defined by the designers of CollectionSpace
2. Tenant-specific policies for resources owned by and specific to an individual tenant only.
3. Container policies having one or more "tenant-specific" policies.

Consider the following scenario: a role named CollectionsManager may have complete control over all actions (e.g. create, view, delete, update) on resource such as Collection A of tenant X (e.g. hearstmuseum.berkeley.edu), however, it may have only limited access (e.g. view only) for actions performed on Collection B of tenant Y (e.g. ucmp.berkeley.edu) even though tenant X and tenant Y both might be part of a larger organization (e.g. berkeley.edu). What this means is that no two seemingly similar roles among the tenants of CollectionSpace may have similar privileges to tenant's respective resources.

Unknown macro: {multi-excerpt}