Resource Sharing

Introduction to Tapis Access Controls

Tapis users define resources such as systems, applications, files, streams, functions and workflows. These resources can be used to generate other resources, such as job, workflow and function outputs. The ability to share resources greatly extends their utility and, in general, the usefulness of Tapis. On the other hand, users need to safeguard their data by controlling access to resources. To facilitate both sharing and access control, Tapis provides two built-in authorization mechanisms.

The first facility is implemented using roles and permissions. These controls operate at a low level of abstraction and apply to the individual Tapis resources to which they are associated. The second facility, Tapis shared resources (or simply shared resources), operate at a higher level of abstraction by authorizing complex actions in Tapis. Such actions include running jobs, which authorizes access to an application, execution and archive system. In this case, the granting of a single share affects multiple Tapis resources. We explore both roles/permissions and shared resources in the following sections.

Roles and Permissions

The Security Kernel (SK) implements a distributed, role-based access control (RBAC) facility in which users are assigned roles that limit or allow access to resources. At its most basic, a role is simply a named entity with an owner. Tenant administrators can manage roles in their tenant and Tapis services can manage roles in any tenant. Typically, services only create roles in the administrative tenant at a site (each site defines a restricted administrative tenant).

Access to specific resources is controlled by assigning roles to users. Tapis supports user-based APIs that check if a user has a certain role. Services and other software that perform these checks are free to determine what membership in a role means.

To make managing user authorizations more flexible and convenient, a role can contain zero or more other roles. A contained role is the child of the containing role. A child role can have any number of parents, that is, be contained in any number of other roles. Roles form a forest of directed acyclic graphs.

When checking whether a user has been assigned a particular role, SK APIs check whether the user has been assigned that role or any of its parent roles. When a user is assigned a role, the user is also implicitly assigned all the children of that role.

In addition, roles can contain permissions, which are case-sensitive strings that follow the format defined by Apache Shiro. The permission-creation API adds a permission to a role. The permission-checking API takes a required permission and determines if a user has a matching permission in any of its roles.

Below are examples of permissions enforced by the Tapis Systems service. The first permission allows read/write access to system1 in the MyTenant tenant. A user assigned a role that contains this permission would have access to system1. Similarly, the second permission allows its assignees to create, read, write and delete any system in the MyTenant tenant.


For convenience, each user is automatically assigned a default role that is implicitly created by Tapis. Assigning a permission to a user really means adding the permission to the user’s default role.

Implementations of Roles and Permissions

Below are links to the roles and permissions APIs for each service. Also see the roles and permissions discussions in each service’s documentation.

Tapis Shared Resources

The roles and permissions discussed in the last section allow fine-grained authorization to Tapis resources, such as to systems or applications. Although the semantics of a role or permission can authorize access to multiple resources of the same type, they cannot easily authorize access to all the resources encountered in a complex workflow such as job execution. To get a deeper understanding of the challenge, consider the authorizations needed to run a job:

  1. Read access to the application definition.

  2. Read access to the execution system definition.

  3. Read access to each job input’s storage system.

  4. Read access to each job input’s file path or object ID.

  5. Read/write access to the execution system’s input, output and application staging directories.

  6. Read access to the job’s archive system definition.

  7. Write access to the job’s archive system’s archive path.

If a user simply wants to share an application with another user so that the latter can execute it, many individual role or permission grants would have to be put in place across multiple services.

To solve this problem, Tapis sharing grants access to all resources needed to perform an action. Tapis sharing defines a runtime context in which Tapis authorization is implicitly granted to users performing an action. This context can span multiple services. For example, if a file is shared with a user, then access to Tapis system on which the file resides is implicitly granted when the user attempts access through the Files service.

An important aspect of sharing is that implicit access applies within a certain context and does not apply outside of that context. In the case of a shared file, for instance, read access to the required system definition is only valid when accessing that file through the Files API. If the user tries to access the system definition directly through the Systems API, the request will be rejected as unauthorized (assuming no other authorizations apply).

Another characteristic of sharing is that implicit authorizations apply only to Tapis resources. In the file sharing scenario, the system definition that is part of the shared context is an artifact defined within and under the control of Tapis. Tapis is the controlling agent. Access to the file itself, however, is ultimately under the control of the file system on which the file resides, such as a Posix file system. Tapis sharing has no effect on authorizations enforced by external systems. For example, a user could share a file in their home directory, but unless the grantee already has Posix access to that file, requests to access it will be denied by the operating system.

In addition to sharing resources with individual users, Tapis sharing also supports granting public access to resources. The public-grantee access designation allows all users in a tenant access to the shared resource. Where supported, the public-grantee-no-authn access designation grants access to all users, even those that have not authenticated with Tapis. See individual service documentation for details on public access support.

Shared Application Contexts (SACs)

The concept of a Shared Application Context (SAC) recognizes that applications run in the context of a Tapis job. This context is leveraged by multiple, cooperating services to allow implicit access to all the resources needed to run a job. Specifically, users are able to access systems and files to which they have not been given explicit Tapis permission when they run in a SAC.

When a job runs in a SAC services skip Tapis authorization checking on resources explicitly specified in the application definition. Important characteristics of a SAC are:

  1. The SAC-aware services are Systems, Applications, Jobs and Files.
    1. These services know when they are running in a SAC and how to alter their behavior.

  2. SAC-aware services skip Tapis authorization only during Job execution of a shared application.
    1. Users are not conferred any special privileges on application-specified resources outside of job execution.

    2. Relaxed authorization checking applies only to systems and files referenced in the application definition.

  3. SSH authentication to a host is not affected by SAC processing.
    1. The Tapis system definition still determines the credentials used to login to a host.

    2. The host operating system still authorizes access to host resources.

  4. File system and object store authorization is not affected by SAC processing.
    1. The authenticated user must still be authorized by the persistent storage systems.

In summary, a user can share an application with another user and the Tapis file and system resources referenced in the application definition are also implicitly shared. This implicit sharing is implemented by simply not performing Tapis authorization checks on these resources (and only these resources). The underlying operating systems’ and persistent storage systems’ authentication and authorization mechanisms are unchanged, so users have no more low-level access than they would otherwise. Tapis simply relaxes its access constraints during job execution, but all host authorizations are still enforced.

SAC-Eligible Attributes

The following attributes of application definitions are SAC-eligible, meaning that implicit access to the resources they designate can be granted to jobs running in a SAC.

  1. execSystemId

  2. execSystemExecDir

  3. execSystemInputDir

  4. execSystemOutputDir

  5. archiveSystemId

  6. archiveSystemDir

  7. fileInputs sourceUrl

  8. fileInputs targetPath

If an execution system, for instance, is specified in a shared application definition, and that system is not overridden in the job submission request, then jobs running in a SAC will be granted implicit access to the system’s definition. The same goes for the other SAC-eligible attributes: If their values are specified in the application and those values are not overridden when a job is submitted, Tapis implicitly grants access to the designated Tapis resource.

Implementations of Tapis Sharing

Below are links to the sharing APIs for each service. Also see the sharing discussions in each serivce’s documentation.