Documentation Home · End Users · App Contributors · Tutorials · Systems · Tenant Admin · Reference

This guide covers administrative tasks for OneSciencePlace (OSP) tenant leads: managing user roles, configuring the publication editorial workflow, and coordinating identity and access settings across the deployment. An administrator role is required for the tasks described here.

On this page

  1. Roles overview
  2. Managing user roles
  3. Creating and editing custom roles
  4. Role permissions
  5. Publication editorial workflow
  6. Identity and access configuration

Roles overview

Site-wide access control is based on role-based access controls (RBAC). Users can have multiple roles, and their permissions are cumulative. Fine-grained policy-based access controls are on the development roadmap.

Current roles

  1. Anonymous user — no account. Can view public content.
  2. Authenticated user — has an account.
  3. Publication creator — can create new publications.
  4. Publication manager — can view, edit, and delete any publication in any state (draft, review, published, archived).
  5. Group manager — manages groups.
  6. Editor — can review and publish publications.
  7. App creator — can create apps.
  8. App manager — can manage apps.
  9. System creator — can create systems.
  10. System manager — can manage systems.
  11. Site manager — site-level administrative role.
  12. Administrator — has all site-wide privileges.

Only the Administrator can view and change user roles.

↑ Back to top

Managing user roles

All of the tasks in this guide currently require the Administrator role.

See all users' roles

Click People in the top admin bar (right of center).

Change a user's role(s)

  1. Click People.
  2. Find the user in the table.
  3. Click Edit (last column).
  4. Scroll to the Roles section (about halfway down).
  5. Check or uncheck roles as desired.
  6. Click Save.

↑ Back to top

Creating and editing custom roles

Create a new role

  1. Go to People → Roles → Add role.
  2. Enter the role's name.
  3. Click Save.

Edit a role's name

  1. Go to People → Roles.
  2. Find the role in the table and click Edit.
  3. Make the change and click Save.

↑ Back to top

Role permissions

Edit a single role's permissions

  1. Go to People → Roles.
  2. Find the role in the table.
  3. In the Operations column dropdown, choose Edit permissions.
  4. Make changes and click Save.

Edit all roles' permissions at once

  1. Go to People → Permissions.
  2. Make changes and click Save.

↑ Back to top

Publication editorial workflow

Publications move through three states: Draft (edit freely), Review (editor approves), and Published (citable, locked). End users with the Publication creator role drive content from Draft to Review; users with the Editor role take it from Review to Published.

For the user-facing workflow (creating, editing, submitting publications), see the End User Guide. The remainder of this section covers the editor's responsibilities.

Editor privileges

  • Review publications in the Review state.
  • Change a publication's state (for example, Review → Published).
  • View any unpublished content.
  • Update, edit, or delete any publication media.
  • View, delete, or revert any publication revision.

Reviewing and approving a publication

When a publication is in the Review state, editors can view it through the publications listing. After review, the editor changes the state to Published to make the publication publicly available and assign its persistent identifier if applicable.

Once a publication is Published, it cannot be edited or deleted — this is by design, to preserve the integrity of citable records. New versions of a publication can be created, and each version carries its own persistent identifier.

Publication permissions reference

The full permissions matrix for publications:

  • All users, including anonymous visitors, can view the list of published publications and see authors (with ORCID if provided), description, DOI, publication type, published date, related info, title, and version.
  • Users with the Publication creator role can create new publications, edit and delete their own publications, clone a publication, add keywords (but not edit or delete existing keywords), and change the publication state from Draft (default) to Review.
  • Users with the Publication manager role can view, edit, and delete any publication in any state.
  • Users with the Editor role have the privileges listed above.

↑ Back to top

Identity and access configuration

OSP's identity and access management is built on Drupal's contributed module ecosystem, with custom modules added where research-specific providers require them. This means OSP inherits the maturity, documentation, and community support of the underlying modules rather than maintaining a parallel custom identity stack.

Recommended path: CILogon or Globus Auth

For most research and education deployments, OSP recommends authenticating through CILogon or Globus Auth. Both are built as OSP-developed extensions on top of Drupal's standard OpenID Connect (OIDC) module.

CILogon brokers institutional identity through InCommon — which itself uses Shibboleth and SAML under the hood — so configuring CILogon gives users sign-in with their home institution credentials without OSP needing to integrate each institution separately. Globus Auth offers similar federated identity coverage and is preferred where Globus is already part of the deployment's data movement story.

For the great majority of OSP deployments, CILogon or Globus is sufficient and there is no need to configure separate SAML, Shibboleth, or LDAP integrations.

Other supported mechanisms

Where the recommended path doesn't fit — for example, an institution that requires direct SAML or LDAP integration outside any federation — OSP can be configured with additional Drupal contributed modules:

  • Standard OIDC — Drupal's OpenID Connect module supports any OIDC-compliant identity provider directly.
  • SAML / Shibboleth — Drupal's SAML and SimpleSAMLphp Authentication modules support direct SAML integration where federation through CILogon or Globus isn't appropriate.
  • CAS — Drupal's CAS module supports campus CAS-based SSO.
  • LDAP — Drupal's LDAP module supports campus directory authentication.
  • Standard web accounts — username and password, optionally with multi-factor authentication, for cases where federated identity isn't required.

Web account creation vs. per-system account linking

It's worth distinguishing two things that often get conflated:

Creating an OSP web account is automatic. When a user signs in through CILogon, Globus Auth, or any other configured authentication mechanism, OSP creates and maintains their web account without administrator intervention. This is the standard Drupal authentication flow with the modules described above.

Linking that web account to the user's actual account on each connected compute system is a separate problem. Federated identity tells OSP who the user is — it doesn't, by itself, tell a target system how to run a job under that user's local Unix account. This linkage requires explicit configuration, and there are two practical paths.

Option 1: Each user manages their own SSH key pair per system

The user generates (or has OSP generate) an SSH key pair, then installs the public key on their account on each target system by adding it to that account's ~/.ssh/authorized_keys. From that point, OSP can submit jobs to that system on the user's behalf using their own Unix account.

This option requires no per-system customization on the OSP side, but it does require each user to perform the key installation step on every system they want to use — and to repeat the step if they gain access to a new system. For deployments where users are technically capable and the system count is small, this is workable.

Option 2: Automated account linking via Tapis Trust Manager System (TMS) or a custom mechanism

For deployments where the user-managed approach creates too much friction — large user communities, frequent onboarding, or systems where users shouldn't need to think about SSH keys at all — account linking can be automated.

The Tapis Trust Manager System (TMS) provides one well-supported path. TMS lets Tapis automatically generate and use SSH key pairs on behalf of users rather than requiring them to provide their own. Tapis system definitions configured for TMS use defaultAuthnMethod=TMS_KEYS and credentials are created with createTmsKeys=true. TMS requires the Tapis site installation and the target host's sshd configuration to be set up appropriately. See the Tapis documentation on TMS support for the full picture.

Other deployments use customized mechanisms appropriate to their institutional environment — for example, integration with a campus account-provisioning system or a tenant-specific automation built around the deployment's identity setup.

Automation removes the user-facing step but requires per-system or per-tenant configuration work. The right approach depends on the systems being connected, the institution's account provisioning conventions, and the size and technical sophistication of the user community.

Configuration

Initial identity configuration — both the authentication mechanism and the per-system account linking strategy — is typically done during deployment by the OSP team in coordination with your institution's identity administrator and system administrators. For ongoing changes such as adding a new provider, adjusting attribute mappings, or revising the per-system linking approach, contact the OSP team at osp@oarc.ucla.edu.

↑ Back to top

Previous: ← System Administrator Guide  |  Next: Reference →