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.
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.
blacklist
Blacklist 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 blacklist that further restricts users, beyond whatever restrictions the authenticator has in place.
If empty, does not perform any additional restriction.
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
Whitelist of usernames that are allowed to log in.
Use this with supported authenticators to restrict which users can log in. This is an additional whitelist that further restricts users, beyond whatever restrictions the authenticator has in place.
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 whitelist.
Subclasses may do more extensive things, such as adding actual unix users, but they should call super to ensure the whitelist 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 the whitelist 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_blacklist
Check if a username is blocked to authenticate based on blacklist configuration
Return True if username is allowed, False otherwise. No blacklist means any username is allowed.
Names are normalized before being checked against the blacklist.
Changed in version 1.0: Signature updated to accept authentication data as second argument
check_whitelist
Check if a username is allowed to authenticate based on whitelist configuration
Return True if username is allowed, False otherwise. No whitelist means any username is allowed.
Names are normalized before being checked against the whitelist.
Changed in version 1.0: Signature updated to accept authentication data and any future changes
delete_user
Hook called when a user is deleted
Removes the user from the whitelist. Subclasses should call super to ensure the whitelist 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 whitelist.
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_whitelist checks against the user whitelist
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.
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
Whitelist all users from this UNIX group.
This makes the username whitelist ineffective.
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_group_whitelist
If group_whitelist 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.
White/blacklisting 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.