Arvados™ Docs
WARNING - you are viewing the documentation for an old version of Arvados. For the latest version, click here.
  1. Concepts
    1. API Reference
    2. API Authorization
    3. REST API syntax
    4. Common resource methods
    5. Common resource fields
  2. Permission and authentication
    1. api_client_authorizations
    2. api_clients
    3. authorized_keys
    4. groups
    5. users
    6. user_agreements
  3. System resources
    1. keep_services
    2. links
    3. logs
    4. nodes
    5. virtual_machines
    6. keep_disks (deprecated)
  4. Data management
    1. WebDAV
    2. S3 API
    3. Keep-web URL patterns
    4. Projects and filter groups
    5. collections
    6. repositories
  5. Container engine
    1. container_requests
    2. containers
    3. workflows
  6. Management (admin/system)
    1. cloud dispatcher
  7. Jobs engine (legacy)
    1. Crunch scripts
    2. jobs
    3. job_tasks
    4. pipeline_instances
    5. pipeline_templates
  8. Metadata for bioinformatics (deprecated)
    1. humans
    2. specimens
    3. traits

API Authorization

All requests to the API server must have an API token. API tokens can be issued by going though the login flow, or created via the API. At this time, only browser based applications can perform login from email/password. Command line applications and services must use an API token provided via the ARVADOS_API_TOKEN environment variable or configuration file.

Login

Browser based applications can log in using one of the two possible flows:

Authenticate via a third party

  1. The web application instructs the user to click on a link to the /login endpoint on the API server. This link should include the return_to parameter in the query portion of the URL. For example https://pirca.arvadosapi.com/login?return_to=XXX , where return_to=XXX is a page in the web application.
  2. The /login endpoint redirects the user to the configured third party authentication provider (e.g. Google or other OpenID Connect provider).
  3. The user logs in to the third party provider, then they are redirected back to the API server.
  4. The API server authenticates the user, issues a new API token, and redirects the browser to the URL provided in return_to=XXX with the addition of ?api_token=xxxxapitokenxxxx.
  5. The web application gets the authorization token from the query and uses it to access the API server on the user’s behalf.

Direct username/password authentication

  1. The web application presents username and password fields.
  2. When the submit button is pressed, using Javascript, the browser sends a POST request to /arvados/v1/users/authenticate
    • The request payload type is application/javascript
    • The request body is a JSON object with username and password fields.
  3. The API server receives the username and password, authenticates them with the upstream provider (such as LDAP or PAM), and responds with the api_client_authorization object for the new API token.
  4. The web application receives the authorization token in the response and uses it to access the API server on the user’s behalf.

Using an OpenID Connect access token

A cluster that uses OpenID Connect as a login provider can be configured to accept OIDC access tokens as well as Arvados API tokens (this is disabled by default; see Login.OpenIDConnect.AcceptAccessToken in the default config.yml file).

  1. The client obtains an access token from the OpenID Connect provider via some method outside of Arvados.
  2. The client presents the access token with an Arvados API request (e.g., request header Authorization: Bearer xxxxaccesstokenxxxx).
  3. Depending on configuration, the API server decodes the access token (which must be a signed JWT) and confirms that it includes the required scope (see Login.OpenIDConnect.AcceptAccessTokenScope in the default config.yml file).
  4. The API server uses the provider’s UserInfo endpoint to validate the presented token.
  5. If the token is valid, it is cached in the Arvados database and accepted in subsequent API calls for the next 10 minutes.

Diagram

User activation

Creation and activation of new users is described here.

Creating tokens via the API

The browser login method above issues a new token. Using that token, it is possible to make API calls to create additional tokens. To do so, use the create method of the API client authorizations resource.

Trusted API clients

The api_clients resource determines if web applications that have gone through the browser login flow may create or list API tokens.

After the user has authenticated, but before an authorization token is issued and browser redirect sent (sending the browser back to the return_to login page bearing api_token), the server strips the path and query portion from return_to to get url_prefix. The url_prefix is used to find or create an ApiClient object. The newly issued API client authorization (API token) is associated with this ApiClient object.

API clients may be marked as “trusted” by making an API call to create or update an api_clients resource and set the is_trusted flag to true. An authorization token associated with a “trusted” client is permitted to list authorization tokens on API client authorizations .

A authorization token which is not associated with a trusted client may only use the current method to query its own api_client_authorization object. The “untrusted” token is forbidden performing any other operations on API client authorizations, such as listing other authorizations or creating new authorizations.

Authorization tokens which are not issued via the browser login flow (created directly via the API) inherit the api client of the token used to create them. They will always be “trusted” because untrusted API clients cannot create tokens.

Scopes

Scopes can restrict a token so it may only access certain resources. This is in addition to normal permission checks for the user associated with the token.

Each entry in scopes consists of a request_method and request_path. The request_method is a HTTP method (one of GET, POST, PATCH or DELETE) and request_path is the request URI. A given request is permitted if it matches a scopes exactly, or the scope ends with / and the request string is a prefix of the scope.

As a special case, a scope of ["all"] allows all resources. This is the default if no scope is given.

Using scopes is also described on the Securing API access with scoped tokens page of the admin documentation.

Scope examples

A scope of GET /arvados/v1/collections permits listing collections.

  • Requests with different methods, such as creating a new collection using POST /arvados/v1/collections, will be rejected.
  • Requests to access other resources, such as GET /arvados/v1/groups, will be rejected.
  • Be aware that requests for specific records, such as GET /arvados/v1/collections/962eh-4zz18-xi32mpz2621o8km will also be rejected. This is because the scope GET /arvados/v1/collections does not end in /

A scope of GET /arvados/v1/collections/ (with / suffix) will permit access to individual collections.

  • The request GET /arvados/v1/collections/962eh-4zz18-xi32mpz2621o8km will succeed
  • Be aware that requests for listing GET /arvados/v1/collections (no / suffix) will be rejected, because it is not a match with the rule GET /arvados/v1/collections/
  • A listing request GET /arvados/v1/collections/ will have the trailing / suffix trimmed before the scope check, as a result it will not match the rule GET /arvados/v1/collections/.

To allow both listing objects and requesting individual objects, include both in the scope: ["GET /arvados/v1/collections", "GET /arvados/v1/collections/"]

A narrow scope such as GET /arvados/v1/collections/962eh-4zz18-xi32mpz2621o8km will disallow listing objects as well as disallow requesting any object other than those listed in the scope.

Previous: API Reference Next: REST API syntax

The content of this documentation is licensed under the Creative Commons Attribution-Share Alike 3.0 United States licence.
Code samples in this documentation are licensed under the Apache License, Version 2.0.