Role Based Access Control

Intro

Sirepo supports proprietary simulation types with three types of role-based authorization modes:

• Command line authorization
• GUI authorization with email-triggered notification
• OAuth authorization

Command line authorization

The simplest mode of role-based authorization is to give users roles on the command line. There are two steps to enable this:

• configuring the proprietary simulation types
• adding roles for allowed users

Configure Sirepo proprietary simulation types

To set up this mode of authorization, you pass the environment variable $SIREPO_FEATURE_CONFIG_PROPRIETARY_SIM_TYPES to the sirepo server.

If your server was configured with RSConf, you can simply edit the file /srv/sirepo/env and change the SIREPO_FEATURE_CONFIG_PROPRIETARY_SIM_TYPES to include the simulation types that need to be controlled.

For example, to restrict access to jspec and srw, the line would in /srv/sirepo/env would look like:

export 'SIREPO_FEATURE_CONFIG_PROPRIETARY_SIM_TYPES=jspec:srw'

The colon (:) seperates the simulation types.

Then restart sirepo using systemct:

systemctl restart sirepo

Give user role(s)

If your server has been configured with RSConf, you can use the /srv/sirepo/start program to execute the command line utility sirepo.pkcli.roles with the proper environment:

/srv/sirepo/start bash sirepo roles add user@example.com sim_type_jspec sim_type_srw

This commands gives user@example.com the ability to execute jspec and srw immediatetly. There is no cache or wait period.

Note: The user must already be registered with Sirepo.

If the user isn't registered, you can ask them to visit the app, e.g. https://www.sirepo.com/jspec. It will ask them to login. Once logged in, they will get a forbidden message.

At this point, you can add the role to the user. They get immediate access once you, when they click on the Simulations list or visit the app's link, they'll get

List a user's roles

You can see what roles a user has with:

/srv/sirepo/start bash sirepo roles list user@example.com

GUI based authorization

Moderation works as follows:

• A user visits Sirepo and tries to access a moderated code
• The user is prompted to provide a reason for needing access to the code
• An admin gets an email asking them to moderate the user
• On Sirepo the admin can view a list of users awaiting moderation. There they can approve, deny, or clarify each user's authorization status.
• In all three cases, the user gets an email with their status after moderation.

Moderation requires email authentication to be setup in Sirepo. It also needs some configuration. The rest is handled in real-time as requests come in.

Configure GUI based authorization

Sirepo must already be set up for email authentication, which includes SMTP configuration so that the server can send emails.

Two environment variables need to be configured:

• $SIREPO_FEATURE_CONFIG_MODERATED_SIM_TYPES - which simulation types require approval
• $SIREPO_AUTH_ROLE_MODERATION_MODERATOR_EMAIL - where the moderation email goes. This is also the address of the email to the users so typically this is the site support email address.

If your server was configured with RSConf, you can simply edit the file /srv/sirepo/env and change these values.

For example, to moderate access to zgoubi, add the following lines to /srv/sirepo/env:

export 'SIREPO_FEATURE_CONFIG_MODERATED_SIM_TYPES=zgoubi
export 'SIREPO_AUTH_ROLE_MODERATION_MODERATOR_EMAIL=admin@example.com

admin@example.com is the email address for the moderators.

Moderation access request

When an unauthorized user visits a moderated simulation type, they will be asked to explain why they want access to the code:

Once they click submit, they will get a message Response submitted.

Moderation actions

When the user submits an access request, an email is sent to the configured administrator, e.g. admin@example.com. The email looks something like:

To: admin@example.com
Subject: zgoubi Access Request

Name: Hermione Granger
Simulation Type: zgoubi
Reason: I would like to learn about polarization dynamics in synchrotrons.
Email: user@example.com
DNS: some-synchrotron.org
IP: 1.2.3.4

To accept or deny:
<link>

When the admin clicks on <link>, they will be presented with a view something like this:

There may be multiple users awaiting moderation, but in this case, there's only one. The three buttons are:

• Deny: No access is allowed
• Clarify: An email asking for more information is sent
• Approve: Access is granted

In all three cases, an email is sent to the user explaining their status. Only in the Clarify case does the moderation request stay in the moderation list. Once denied, a user is not presented with the choice to get access.

Note that email-triggered moderation simply automates the process of Command line authorization, that is, you can see the roles for a user who has been granted access via email-triggered moderation by going to the command line and listing the roles for that user.

OAuth authorization

OAuth authorization is a real-time validation of a user's authorization using the OAuth protocol. The purpose of this protocol is to support third parties control over access to their codes running within Sirepo. For example, The Flash Center for Computational Science controls access to the FLASH code. Sirepo controls access to FLASH via Oauth authorization.

OAuth configuration

Currently, OAuth authorization is hard-coded to only support Sirepo FLASH. There is some configuration that is required, however.

Again, if your server was configured with RSConf, you can simply edit the file /srv/sirepo/env and add the following variables:

export 'SIREPO_FEATURE_CONFIG_PROPRIETARY_OAUTH_SIM_TYPES=flash'
export 'SIREPO_SIM_OAUTH_FLASH_INFO_VALID_USER=some-validation-value'
export 'SIREPO_SIM_OAUTH_FLASH_KEY=oauth-key-value'
export 'SIREPO_SIM_OAUTH_FLASH_KEY=oauth-secret-value'

The last three values are obtained with coordination with The Flash Center.

Oauth actions

All actions are performed by the user. When they visit Sirepo FLASH, a user will be presented with the following page:

The user enters their credential, and click Login. At which point, they will be redirected to the Sirepo FLASH page and can begin work.

No admin intervention is required.