jupyterhub.auth
Base Authenticator class and the default PAM Authenticator
Authenticator
jupyterhub.auth.
Base class for implementing an authentication provider for JupyterHub
admin_users
Set of users that will have admin rights on this JupyterHub.
Use the admin panel to see list of users logged in
Add / remove users in some authenticators
Restart / halt the hub
Start / stop users’ single-user servers
Can access each individual users’ single-user server (if configured)
Admin access should be treated the same way root access is.
Defaults to an empty set, in which case no user has admin access.
allowed_users
Set of usernames that are allowed to log in.
Use this with supported authenticators to restrict which users can log in. This is an additional list that further restricts users, beyond whatever restrictions the authenticator has in place.
If empty, does not perform any additional restriction.
Changed in version 1.2: Authenticator.whitelist renamed to allowed_users
Authenticator.whitelist
auth_refresh_age
The max age (in seconds) of authentication info before forcing a refresh of user auth info.
Refreshing auth info allows, e.g. requesting/re-validating auth tokens.
See refresh_user() for what happens when user auth info is refreshed (nothing by default).
refresh_user()
auto_login
Automatically begin the login process
rather than starting with a “Login with…” link at /hub/login
/hub/login
To work, .login_url() must give a URL other than the default /hub/login, such as an oauth handler or another automatic login handler, registered with .get_handlers().
.login_url()
.get_handlers()
New in version 0.8.
blocked_users
Set of usernames that are not allowed to log in.
Use this with supported authenticators to restrict which users can not log in. This is an additional block list that further restricts users, beyond whatever restrictions the authenticator has in place.
Changed in version 1.2: Authenticator.blacklist renamed to blocked_users
Authenticator.blacklist
delete_invalid_users
Delete any users from the database that do not pass validation
When JupyterHub starts, .add_user will be called on each user in the database to verify that all users are still valid.
.add_user
If delete_invalid_users is True, any users that do not pass validation will be deleted from the database. Use this if users might be deleted from an external system, such as local user accounts.
If False (default), invalid users remain in the Hub’s database and a warning will be issued. This is the default to avoid data loss due to config changes.
enable_auth_state
Enable persisting auth_state (if available).
auth_state will be encrypted and stored in the Hub’s database. This can include things like authentication tokens, etc. to be passed to Spawners as environment variables.
Encrypting auth_state requires the cryptography package.
Additionally, the JUPYTERHUB_CRYPT_KEY environment variable must contain one (or more, separated by ;) 32B encryption keys. These can be either base64 or hex-encoded.
If encryption is unavailable, auth_state cannot be persisted.
New in JupyterHub 0.8
post_auth_hook
An optional hook function that you can implement to do some bootstrapping work during authentication. For example, loading user account details from an external system.
This function is called after the user has passed all authentication checks and is ready to successfully authenticate. This function must return the authentication dict reguardless of changes to it.
This maybe a coroutine.
Example:
import os, pwd def my_hook(authenticator, handler, authentication): user_data = pwd.getpwnam(authentication['name']) spawn_data = { 'pw_data': user_data 'gid_list': os.getgrouplist(authentication['name'], user_data.pw_gid) } if authentication['auth_state'] is None: authentication['auth_state'] = {} authentication['auth_state']['spawn_data'] = spawn_data return authentication c.Authenticator.post_auth_hook = my_hook
refresh_pre_spawn
Force refresh of auth prior to spawn.
This forces refresh_user() to be called prior to launching a server, to ensure that auth state is up-to-date.
This can be important when e.g. auth tokens that may have expired are passed to the spawner via environment variables from auth_state.
If refresh_user cannot refresh the user auth data, launch will fail until the user logs in again.
username_map
Dictionary mapping authenticator usernames to JupyterHub users.
Primarily used to normalize OAuth user names to local users.
username_pattern
Regular expression pattern that all valid usernames must match.
If a username does not match the pattern specified here, authentication will not be attempted.
If not set, allow any username.
whitelist
Deprecated, use Authenticator.allowed_users
Authenticator.allowed_users
add_user
Hook called when a user is added to JupyterHub
When a user first authenticates
When the hub restarts, for all users.
This method may be a coroutine.
By default, this just adds the user to the allowed_users set.
Subclasses may do more extensive things, such as adding actual unix users, but they should call super to ensure the allowed_users set is updated.
Note that this should be idempotent, since it is called whenever the hub restarts for all users.
user (User) – The User wrapper object
authenticate
Authenticate a user with login form data
This must be a coroutine.
It must return the username on successful authentication, and return None on failed authentication.
Checking allowed_users/blocked_users is handled separately by the caller.
Changed in version 0.8: Allow authenticate to return a dict containing auth_state.
handler (tornado.web.RequestHandler) – the current request handler
data (dict) – The formdata of the login form. The default form has ‘username’ and ‘password’ fields.
The username of the authenticated user, or None if Authentication failed.
The Authenticator may return a dict instead, which MUST have a key name holding the username, and MAY have two optional keys set: auth_state, a dictionary of of auth state that will be persisted; and admin, the admin setting value for the user.
name
auth_state
admin
user (str or dict or None)
check_allowed
Check if a username is allowed to authenticate based on configuration
Return True if username is allowed, False otherwise. No allowed_users set means any username is allowed.
Names are normalized before being checked against the allowed set.
Changed in version 1.0: Signature updated to accept authentication data and any future changes
Changed in version 1.2: Renamed check_whitelist to check_allowed
check_blocked_users
Check if a username is blocked to authenticate based on Authenticator.blocked configuration
Return True if username is allowed, False otherwise. No block list means any username is allowed.
Names are normalized before being checked against the block list.
Changed in version 1.0: Signature updated to accept authentication data as second argument
Changed in version 1.2: Renamed check_blacklist to check_blocked_users
delete_user
Hook called when a user is deleted
Removes the user from the allowed_users set. Subclasses should call super to ensure the allowed_users set is updated.
get_authenticated_user
Authenticate the user who is attempting to log in
Returns user dict if successful, None otherwise.
This calls authenticate, which should be overridden in subclasses, normalizes the username if any normalization should be done, and then validates the name in the allowed set.
This is the outer API for authenticating a user. Subclasses should not override this method.
authenticate turns formdata into a username
normalize_username normalizes the username
normalize_username
check_allowed checks against the allowed usernames
Changed in version 0.8: return dict instead of username
get_handlers
Return any custom handlers the authenticator needs to register
Used in conjugation with login_url and logout_url.
login_url
logout_url
app (JupyterHub Application) – the application object, in case it needs to be accessed for info.
list of ('/url', Handler) tuples passed to tornado. The Hub prefix is added to any URLs.
('/url', Handler)
handlers (list)
is_admin
Authentication helper to determine a user’s admin status.
authentication – The authetication dict generated by authenticate.
The admin status of the user, or None if it could not be determined or should not change.
admin_status (Bool or None)
Override this when registering a custom login handler
Generally used by authenticators that do not use simple form-based authentication.
The subclass overriding this is responsible for making sure there is a handler available to handle the URL returned from this method, using the get_handlers method.
base_url (str) – the base URL of the Hub (e.g. /hub/)
The login URL, e.g. ‘/hub/login’
str
Override when registering a custom logout handler
The logout URL, e.g. ‘/hub/logout’
Normalize the given username and return it
Override in subclasses if usernames need different normalization rules.
The default attempts to lowercase the username and apply username_map if it is set.
post_spawn_stop
Hook called after stopping a user container
Can be used to do auth-related cleanup, e.g. closing PAM sessions.
pre_spawn_start
Hook called before spawning a user’s server
Can be used to do auth-related startup, e.g. opening PAM sessions.
refresh_user
Refresh auth data for a given user
Allows refreshing or invalidating auth data.
Only override if your authenticator needs to refresh its data about users once in a while.
user (User) – the user to refresh
handler (tornado.web.RequestHandler or None) – the current request handler
Return True if auth data for the user is up-to-date and no updates are required.
Return False if the user’s auth data has expired, and they should be required to login again.
Return a dict of auth data if some values should be updated. This dict should have the same structure as that returned by authenticate() when it returns a dict. Any fields present will refresh the value for the user. Any fields not present will be left unchanged. This can include updating .admin or .auth_state fields.
authenticate()
.admin
.auth_state
auth_data (bool or dict)
run_post_auth_hook
Run the post_auth_hook if defined
authentication (dict) – User authentication data dictionary. Contains the username (‘name’), admin status (‘admin’), and auth state dictionary (‘auth_state’).
The hook must always return the authentication dict
Authentication (dict)
validate_username
Validate a normalized username
Return True if username is valid, False otherwise.
LocalAuthenticator
Base class for Authenticators that work with local Linux/UNIX users
Checks for local users, and can attempt to create them if they exist.
add_user_cmd
The command to use for creating users as a list of strings
For each element in the list, the string USERNAME will be replaced with the user’s username. The username will also be appended as the final argument.
For Linux, the default value is:
[‘adduser’, ‘-q’, ‘–gecos’, ‘””’, ‘–disabled-password’]
To specify a custom home directory, set this to:
[‘adduser’, ‘-q’, ‘–gecos’, ‘””’, ‘–home’, ‘/customhome/USERNAME’, ‘–disabled-password’]
This will run the command:
adduser -q –gecos “” –home /customhome/river –disabled-password river
when the user ‘river’ is created.
allowed_groups
Allow login from all users in these UNIX groups.
If set, allowed username set is ignored.
create_system_users
If set to True, will attempt to create local system users if they do not exist already.
Supports Linux and BSD variants only.
group_whitelist
DEPRECATED: use allowed_groups
uids
Dictionary of uids to use at user creation time. This helps ensure that users created from the database get the same uid each time they are created in temporary deployments or containers.
add_system_user
Create a new local UNIX user on the system.
Tested to work on FreeBSD and Linux, at least.
Hook called whenever a new user is added
If self.create_system_users, the user will attempt to be created if it doesn’t exist.
check_allowed_groups
If allowed_groups is configured, check if authenticating user is part of group.
system_user_exists
Check if the user exists on the system
PAMAuthenticator
Authenticate local UNIX users with PAM
admin_groups
Authoritative list of user groups that determine admin access. Users not in these groups can still be granted admin status through admin_users.
allowed/blocked rules still apply.
check_account
Whether to check the user’s account status via PAM during authentication.
The PAM account stack performs non-authentication based account management. It is typically used to restrict/permit access to a service and this step is needed to access the host’s user access control.
Disabling this can be dangerous as authenticated but unauthorized users may be granted access and, therefore, arbitrary execution on the system.
encoding
The text encoding to use when communicating with PAM
open_sessions
Whether to open a new PAM session when spawners are started.
This may trigger things like mounting shared filsystems, loading credentials, etc. depending on system configuration, but it does not always work.
If any errors are encountered when opening/closing PAM sessions, this is automatically set to False.
pam_normalize_username
Round-trip the username via PAM lookups to make sure it is unique
PAM can accept multiple usernames that map to the same user, for example DOMAINusername in some cases. To prevent this, convert username into uid, then back to uid to normalize.
service
The name of the PAM service to use for authentication
DummyAuthenticator
Dummy Authenticator for testing
By default, any username + password is allowed If a non-empty password is set, any username will be allowed if it logs in with that password.
New in version 1.0.
password
Set a global password for all users wanting to log in.
This allows users with any username to log in with the same static password.