Skip to content

Authentication

Jump to bottom
Iaroslav Shepilov edited this page Jul 3, 2023 · 18 revisions

Authentication can be enabled in Script server via configuration (see auth configuration). At the moment the following auth providers are supported:

If authentication is not enabled, please refer to No Auth section

Security note: Script server does not and will not store any user credentials/tokens locally. However, some identification data is stored on users PC in encrypted form. Encryption key is available on server side only. User passwords or any securiry tokens are not stored anywhere.

When authentication is enabled, users are required to login, before accessing the Script server.

Authentication purposes

Authentication is used in the Script server for the following purposes:

  • auditing and logging user actions (executing scripts)
  • controlling access to the Script server or/and to scripts
  • allowing access to user's scripts executions
  • allowing access to user's temp files

LDAP

Requires: python ldap3 module

Script server can authenticate users against your LDAP server. Users would be prompted for username and login to check if the user have access to the LDAP server. Access is validated by a LDAP bind operation with simple authentication.

After the authentication, user credentials are immediately discarded. User login will stay valid in Script server for 1 month (even if he looses access to the LDAP server).

username_pattern
Bind operation usually requires user's full distinguished name (dn). ActiveDirectory accepts some other username formats as well.
However in most cases unique user names are too cumbersome for a user und simpler username is enough. In this case you can use a username_pattern with $username variable. Examples of most popular patterns:

  • uid=$username,ou=users,dc=domain1,dc=domain2
  • $username@my-domain.com
  • my-domain$username

User will have to specify only this simple $username on login, but the authentication will be performed with a full and unique name.

Groups
Script server can fetch user groups from LDAP. These groups can be later used by Authorization. Groups loading is performed only during user login. After that they will stay cached and unchanged. So, if user needs to update his groups in Script server, he has to relogin.

In order to load user groups base_dn property should be defined in the configuration. Groups are always searched under the Base DN.
base_dn can be automatically resolved for the following username_pattern:

  • uid=$username,ou=people,dc=domain1,dc=domain2,dc=domainN
    base_dn= "dc=domain1,dc=domain2,dc=domainN"
  • username@domain1.domain2.domainN
    base_dn= "dc=domain1,dc=domain2,dc=domainN"

Google OAuth

Requires: connection to google.com and googleapis.com

Script server can authenticate users via Google OAuth Service. client_id and secret properties should be acquired from Google and configured in the Script server.

Instructions

{
    "port": 5000,
    "address": "127.0.0.1",
    "title": "My Script Server",
    "auth": {
        "type": "google_oauth",
        "client_id": "COPY PASTE HERE",
        "secret": "COPY PASTE HERE"
    },
    "access": {
        "allowed_users": [ "[email protected]"],
        "admin_users": [ "[email protected]" ]
    }
}

Usernames of the users are their email addresses. These email adresses can and should be used when configuring user access rights.
User emails are the only information which Script server uses from the Google OAuth Service.

allowed_users
Google OAuth doesn't perform any access control itself. So any user with google account would be able to access your instance of Script server. To prevent it, there is a configuration property allowed_users, which is required in case of Google OAuth. Simply put the emails of all allowed users there (or you can even put * for any user).

Gitlab OAuth

Script server can authenticate users via Gitlab server, hosted or cloud. How to acquire client_id and secret you can find at https://docs.gitlab.com/ee/integration/oauth_provider.html. Script server requires read_user scope or api if you want group support.

Gitlab groups can be used in allowed_users and admin_users. Nested groups can be used using the full path (@some/nested/group)

Options:

  • type (required) - should be gitlab
  • client_id (required) - acquired gitlab client id
  • secret (required) - acquired gitlab secret
  • url - base url of Gitlab instance. Default - https://gitlab.com
  • auth_info_ttl - time to live for info user cache. After expiry, script server will request GitLab for the updated information (e.g. read new groups). Default: 0 (never check GitLab again)
  • state_dump_file - path to a dump file, where current authentication data is persisted. If not defined, then the data is not persisted between server restarts, thus all the users are logged out on a restart.
  • session_expire_minutes - user inactivity time before logged out. Default: 0 (never expires)
  • group_support - import user's Gitlab groups, require 'api' scope. Default: true
  • group_search - search string used for filter groups, useful if users have too many groups because only 100 first returned. Default: do not filter

Keycloak OpenID

(since v1.18)
Script server can authenticate users via Keycloak server using OpenID protocol. You should create a new client for Script server: documentation.
Important configuration notes:

  • valid redirect URL: script-server-host/login.html
  • Capability config:
    • Client Authentication: ON
    • Authentication Flow: Standard flow
    • Everything else: OFF

Keycloak groups are supported, but groups mapping should be configured via: Keycloak clients -> Script server client -> Client scopes -> script-server-dedicated -> Add mapper (by configuration) -> Group membership. With the following options:

  • Name: Group Mappers
  • Token Claim Name: groups
  • Add to userinfo: ON

Also, make sure to add "groups_support": true to script server auth configuration.

Options:

  • type (required) - should be keycloak_openid
  • realm_url (required) - can be acquired from Keycloak -> Realm Settings -> OpenID Endpoint configuration. From the opened json object, take the issuer field. Usually has a form: https://host/realms/realm_name
  • client_id (required) - acquired Keycloak client id
  • secret (required) - acquired Keycloak secret (from client's Credentials tab)
  • url - base URL of Gitlab instance. Default - https://gitlab.com
  • auth_info_ttl - time to live for info user cache. After expiry, Script server will request Keycloak for the updated information (e.g. read new groups). Default: 0 (never check Keycloak again)
  • state_dump_file - path to a dump file, where current authentication data is persisted. If not defined, then the data is not persisted between server restarts, thus all the users are logged out on a restart.
  • session_expire_minutes - user inactivity time before logging out. Default: 0 (never expires)
  • group_support - import user's Keycloak groups. See the instructions above on how to enable it in Keycloak. Default: false

.htpasswd file

If you would like to have a simple authentication, you can use a .htpasswd file
You need to configure a path to this file in Script server.

Requirements

Preferably, htpasswd utility should be installed on a machine. In this case Script server will delegate verification to this utility.

Otherwise, as a fallback, Script server will verify user credentials itself. In this case only the encryption algorithms from this page are supported: https://httpd.apache.org/docs/2.4/misc/password_encryptions.html. Also, if bcrypt algorithm is used, it requires bcrypt python module

Configuration

To enable htpasswd authentication, you need to set auth type and a path to the file, in the server configuration
Example configuration:

"auth": {
    "type": "htpasswd",
    "htpasswd_path": "path/to/.htpasswd"
}

No Auth

Script server needs to identify users even if authentication is not enabled. Identification is needed for the same Authentication purposes

There are 3 possible identificators in the Script server:

Access rights are configured based on these identificators.

personal token

To my knowledge, there is no reliable way to identify anonymous users. Therefore on the initial connection, a user gets a unique personal token, which will stay valid for at least several days.
The token is encrypted by the server and stored on the client-side.

This token can be retrieved from the server logs or from an execution log file.

This token can be used for access configuration. However, by its nature, this token is not the best option for configuration: it's hard to remember and find out and it's temporal. So if possible, it's always better to configure IP identification.

IP

Identifying users by IP has multiple problems:

But if you have trusted users and restricted network, you can add your users to trusted_ips list (see config).
After that, you would be able to configure users' access by their IP.

reverse proxy
If you are using a reverse proxy, real user IPs are not resolved by default. However, if you add the proxy's IP in the trusted_ips list, a real IP will be taken from X-Forwarded-For or X-Real-IP headers (proxy has to fill them).

Please note, that this will cause all the users coming through a proxy to be trusted as well.

Reverse proxy auth

If you are using reverse proxy with authentication, you can pass authenticated user to Script server using HTTP header (for example X-Forwarded-User)
And then you can enable this particular header in Script server for user identification. To do it, use access.user_header_name field

Check ticket #219 for proxy configuration examples

Clone this wiki locally