WEBDIENSTE/NLnetLabs-krill
1
0
Fork 0
mirror of https://github.com/NLnetLabs/krill.git synced 2026-08-30 19:59:44 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
4f2a8fcffeeaadb05ab59e2ef88aae3e27956bc4
NLnetLabs-krill/defaults/krill-multi-user.conf
T
Martin HoffmannandGitHub fc104247ae Restructure authentication policies. (#1232) 
This PR restructures how authentication policies are used in Krill. It
removes the use of Oso and its policy definition language and instead
switches to simple, straightforward mappings between permissions, roles,
and users.

The existing concept of roles is augmented to serve as the central
configuration option for limiting a user’s access to certain action and
resources. Roles are now user configurable via the new auth_roles
configuration directive. For each role, a set of permissions has to be
provided. Optionally, a list of resource handles (vulgo: CAs) can be given
in which case access is limited to these resources.

The authentication providers now assign one of these roles to each logged
in user.

The OpenID Connect provider now only determines claims for “id,” i.e., the
user name, and the “role.” Since we replaced the previous use of JMES
paths with custom functions with a more stringent model of matching and
substitution, the configuration had to change in a non-compatible way,
anyway, so we cleaned it up a bit and switched from a map to an array for
the claims.

For the config file provider, this was already possible by adding a “role”
attribute. This has now been changed into a “role” field of the user
details. In order to make upgrading seamless, the “role” attribute is
still accepted but a deprecation warning is logged. Since the auth_users
configuration is not used for the OpenID Connect provider any more, the
password_hash and salt fields of the user details are now mandatory.

Custom policies have been removed.

This is a breaking change.
2025-02-05 11:45:49 +01:00

611 lines
29 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
##############################################################################
# #
# ----==== WEB UI MULTI-USER LOGIN CONFIGURATION ====---- #
# #
# The settings below can be used to permit multiple users with configurable #
# access rights to login to the Krill web interface. #
# #
##############################################################################
# Global auth(entication & authorization) settings
#
# These control which auth provider in Krill will be used to authenticate
# users and settings common to all auth providers. See below for more details.
#
# auth_type = "admin-token"
# Auth type (optional)
#
# Which provider to use for authentication (AuthN), identity (ID), and
# authorization (AuthZ). Also affects which login form the Krill web UI
# displays, or (in the case of auth_type = "openid-connect") the user is
# redirected to.
#
# Supported values: "admin-token" (default), "config-file" or "openid-connect".
#
# At-a-glance comparison:
# =======================
#
# Setting Value AuthN ID AuthZ
# --------------------------------------------------------------------------
# "admin-token" token matches "admin-token" special built-in
# admin_token role with full access
# config value
# --------------------------------------------------------------------------
# "config-file" login username login username role name from user’s
# appears as key role field in
# in [auth_users] [auth_users] section
# section
# ----------------------------------------------------------------------------
# "openid-connect" provider provider role name provider
# checked supplied supplied
#
# The role names determined by the "openid-connect" and "config-file" types
# are looked up in the [auth_roles] section to determine access permissions.
# See "Auth roles" below.
#
# NOTE: At present the admin-token provider is used as a fallback provider
# when using "openid-connect" or "config-file" as the primary provider. This is
# to ensure that krillc, which uses admin-token authentication, is still able
# to communicate with the Krill daemon.
#
### auth_type = "admin-token"
# Config File auth provider details (mandatory when auth_type = "config-file")
#
# The Config File auth provider allows you to define one or more users which
# can then be used to login to the Krill web UI.
#
# Example:
# auth_type = "config-file"
#
# [auth_users]
# "joe@example.com" = { role="admin", password_hash="...", salt="..." }
# "jill@example.com" = { role="read-ca1", password_hash="...", salt="..." }
#
# Syntax:
# auth_users = { "some id" = { ... } [, "another id" = { ... }, ...] }
#
# Alternative syntax:
# [auth_users]
# "some id" = { ... }
# "another id" = { ... }
#
#
# The "some id" and "another id" terms indicate the email address or other
# identifier for the user. It will need to be entered in the username form
# field in the web UI when logging in. Krill also shows it in the event
# history as the actor to which the action is attributed.
#
# The { ... } above can contain the following fields:
#
# Field Mandatory? Notes
# --------------------------------------------------------------------------
#
# password_hash Yes Generate these values using the
# 'krillc config user' command on the command
# salt Yes line. The web UI will hash the password entered
# in the login form and submit it to Krill for
# comparison to this hash, thereby ensuring that
# passwords are neither transmitted nor
# persisted. Per password salts prevents use of
# rainbow table attacks. Dual salting prevents
# use of stolen password hashes from the config
# file being used to login without knowing the
# passwords.
#
# role Yes The name of the role which determines the
# user’s access rights. See "Auth roles" below.
#
### auth_type = "config-file"
###
### [auth_users]
### ...
# OpenID Connect auth provider details
# (mandatory when auth_type = "openid-connect")
#
# The OpenID Connect auth provider delegates authentication of users to an
# external provider that implements the OpenID Connect Core 1.0 specification.
# Krill uses user attributes (known as "claims" [*1]) from the provider to
# determine the user ID and role name for a user.
#
# Syntax:
# auth_openidconnect = { issuer_url="...", client_id="...", client_secret="..." }
#
# Alternative syntax:
# [auth_openidconnect]
# issuer_url = "..."
# client_id = "..."
# client_secret = "..."
# insecure = false
# extra_login_scopes = ["...", ...]
# extra_login_params = ["...", ...]
# prompt_for_login = false
# logout_url = "..."
#
# [[auth_openidconnect.id_claims]]
# ...
#
# [[auth_openidconnect.role_claims]]
# ...
#
# Where [auth_openidconnect] can contain the following fields:
#
# Field Mandatory? Notes
# --------------------------------------------------------------------------
# issuer_url Yes Provided by your OpenID Connect provider. This
# is the URL of the OpenID Connect provider
# discovery endpoint.
# "/.well-known/openid_configuration"
# will be appended if not present. Krill will
# fetch the OpenID Connect Discovery 1.0
# compliant JSON response from this URL when
# Krill starts up. If this URL does not match the
# "issuer" value in the discovery endpoint
# response or if the discovery endpoint cannot be
# contacted, Krill will fail to start.
#
# client_id Yes Provided by your OpenID Connect provider.
#
# client_secret Yes Provided by your OpenID Connect provider.
#
# insecure No Defaults to false. Setting this to true will
# disable verification of the signature of the
# OpenID Connect provider token ID endpoint
# response. Setting this to false may allow
# attackers to modify responses from the provider
# without being detected. Setting this to false
# is strongly discouraged.
#
# extra_login_scopes No Provider specific. Defaults to "". A
# comma-separated list of OAuth 2.0 scopes to be
# passed to the provider when a user is directed
# to login with the provider. Scopes are
# typically used to instruct the provider to send
# additional user details along with provider
# token responses. One common scope is "profile"
# which often causes the server to respond with
# email addresses and other personal details
# about the user. If the OpenID Connect provider
# discovery endpoint shows that "email" is a
# supported scope then the "email" scope will be
# requested automatically, you don't need to
# specify it here in that case.
#
# extra_login_params No A { key=value, ... } map of additional HTTP
# query parameters to send with the authorization
# request to the provider when redirecting the
# user to the OpenID Connect provider login form.
# Section 3.1.2.1. Authentication Request in the
# OpenID Connect Core 1.0 specification [*2]
# lists various parameters that can be sent but
# the supported set varies by provider. The
# prompt=login parameter is automatically sent by
# the provider (though this behavior can be
# disabled, see prompt_for_login below) and thus
# does not need to be provided using this
# setting. Can also be specified as a separate
# TOML table, e.g.:
#
# [openid_connect.extra_login_params]
# display=popup
# ui_locales="fr-CA fr en"
#
# prompt_for_login No Defaults to true. Setting this to false will
# disable the default behaviour of sending the
# prompt=login parameter to the provider. This
# also allows a different prompt=<value> to be
# specified using extra_login_params, from the
# set defined in Section 3.1.2.1. Authentication
# Request in the OpenID Connect Core 1.0
# specification [*2]: "none", "login", "consent"
# or "select_account".
#
# logout_url No A URL to direct the browser to redirect the
# user to in order to logout. Ideally this is not
# needed as the provider OpenID Connect Discovery
# response should contain the details Krill
# needs, but for some providers a logout_url must
# be specified explicitly. If the provider
# discovery response doesn't announce support for
# any supported mechanisms and no logout_url
# value is set then Krill will default to
# directing the user back to the Krill UI index
# page from where the user will be directed to
# login again via the OpenID Connect provider.
#
# id_claims No A list used to extract the user ID from the
# claim values in the OpenID Connect provider
# response. These will typically given as
# separate TOML array tables. The fields are
# described in the following section.
#
# If this field is missing, the default rule
# is used which uses the value of the "email"
# claim as the user ID.
#
#
# role_claims No A list used to extract the user role from the
# claim values in the OpenID Connect provider
# response. These will typically given as
# separate TOML array tables. The fields are
# described in the following section.
#
# If this field is missing, the default rule
# is used which uses the value of the "role"
# claim as the user’s role.
#
#
# Each [[auth_openidconnect.id_claims]] and [[auth_openidconnect.role_claims]]
# occurence describes one claim transformation rule. Each rule describes a
# test against the claim values contained in the OpenID Connect provider
# response [*3, *4]. If a tests succeeds, the value is transformed and used as
# either the user ID or user role. For each attribute of the two fields, only
# the first succeeding rule is considered.
#
# Field Mandatory? Notes
# --------------------------------------------------------------------------
#
# source No If the 'source' subfield is not provided, all
# available token and userinfo claim responses
# from the OpenID Connect provider will be
# searched for a field that matches the 'claim'
# value.
#
# If specified the value identifies a specific
# claim set to search and can be one of the
# following values:
#
# id-token-standard-claim
# id-token-additional-claim
# user-info-standard-claim
# user-info-additional-claim
#
# claim No The name of the field that is being looked at.
# If this field is missing, then the 'subst'
# field contains the value to be used for the
# user ID or role, independently of any claims-
#
# match No A regular expression that is applied to the
# value of the claim provided by the 'claim'
# field.
#
# A claim value matches if the regular expression
# matches. This could be a partial match, i.e.,
# the rexpression "foo" matches "foo" but also
# "foobar" and "barfoobar". Enclose the text in
# a leading hat and trailing dollar sign for a
# full match, i.e., "^foo$" will only match "foo".
#
# If the expression matches, the claim value will
# be transformed using the expression given in
# the 'subst' field.
#
# Simple claim values are compared using their
# string representation. E.g. a boolean value is
# treated as having the string values "true" or
# "false" and numbers are similarly converted
# using standard JSON rules.
#
# For arrays, each element is matched and the
# first match is used.
#
# Objects never match.
#
# If the 'match' field in missing, any simple
# values matches and is used as is, i.e., the
# expression in the 'subst' field is ignored.
# For array claim values, the first element is
# used.
#
# subst No This field describes a transformation of a
# value matched via the 'match'. It can be a
# simple string or can contain references to
# substrings captured by the 'match' regular
# expression.
#
# All instances of "$ref" in the subst expression
# are replaced with the substring corresponding
# to the capture group identified by "ref".
#
# "ref" may be an integer corresponding to the
# index of the capture group (counted by order
# of opening parenthesis where 0 is the entire
# match) or it can be a name (consisting of
# letters, digits or underscores) corresponding
# to a named capture group.
# If "ref" isn’t a valid capture group (whether
# the name doesn’t exist or isn’t a valid index),
# then it is replaced with the empty string.
#
# The longest possible name is used. For example,
# "$1a" looks up the capture group named "1a" and
# not the capture group at index 1. To exert more
# precise control over the name, use braces,
# e.g., "${1}a".
#
# To write a literal "$" use "$$".
#
# References:
# *1: https://openid.net/specs/openid-connect-core-1_0.html#Claims
# *2: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
# *3: https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse
# *4: https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse
#
#
# ----------------------------------------------------------------------------
# Registering Krill with an OpenID Connect provider:
# ----------------------------------------------------------------------------
# In order to communicate with an OpenID Connect provider, Krill must first be
# registered with that provider. As a result of registration you will be
# issued a client_id and a client_secret, and possibly also an issuer_url (or
# you may have to consult the provider documentation to determine the
# issuer_url).
#
# When registering you will usually need to specify a callback URL. For Krill
# this should be <service_uri>auth/callback (replace <service_uri> with the
# actual value set above).
#
# When auth_type = "openid-connect" the client details MUST be provided to
# Krill via settings in the [auth_openidconnect] section of the configuration
# file.
#
# ------------------------------------------------------------------------------
# Required OpenID Connect provider capabilities:
# ------------------------------------------------------------------------------
#
# The OpenID Connect provider must implement the following specifications:
#
# https://openid.net/specs/openid-connect-core-1_0.html
# https://openid.net/specs/openid-connect-discovery-1_0.html
# https://openid.net/specs/openid-connect-rpinitiated-1_0.html
#
# At the issuer_url endpoint the provider MUST announce support for at least
# the following:
#
# "issuer": ".."
# "authorization_endpoint": "..",
# "token_endpoint": "..", ("userinfo_endpoint" is supported if available)
# "jkws_uri": "..",
# "scopes_supported": ["openid"]
# "response_types_supported": ["code"]
# "response_modes_supported": ["query"]
# "grant_types_supported": ["authorization_code"]
# "id_token_signing_alg_values_supported": ["RS256"]
# one of: "end_session_endpoint": ".." or "revocation_endpoint": ".."
#
# ------------------------------------------------------------------------------
# A note about HTTPS certificates:
# ------------------------------------------------------------------------------
# If the provider URLS are HTTPS URLs (which they should be unless this
# deployment of Krill is only for testing) then the HTTPS certificate must
# have been issued by a CA in the O/S CA certificate store, i.e. either a well
# known authority that is included in the store by default, or a custom CA
# that you have added to the store yourself. Krill will fail to connect to a
# provider that uses a self-signed certificate or a certificate from an
# unknown root certificate authority. For more information see for example:
# http://manpages.ubuntu.com/manpages/xenial/man8/update-ca-certificates.8.html
# ----------------------------------------------------------------------------
#
# ------------------------------------------------------------------------------
# A note about end_session_endpoint and revocation_endpoint:
# ------------------------------------------------------------------------------
# "end_session_endpoint" is defined by various [*1] OpenID Connect draft
# specifications relating to logout. In Krill it is used for the purpose
# defined in the OpenID Connect RP-Initiated Logout 1.0 spec [*1], namely for
# Krill as the RP (OpenID Connect terms Krill a Relying Party in this context,
# which is particularly confusing given that the term Relying Party also has
# meaning in Krill's native RPKI domain) to be able to initiate logout of the
# user at the provider. Krill also requires that the endpoint either honours
# the "post_logout_redirect_uri" HTTP query parameter (defined as OPTIONAL in
# the spec) or that the provider can be configured with corresponding
# behaviour, i.e. to redirect the end-user user-agent (browser) back to Krill
# after logout is completed at the provider. If support for this is lacking it
# is undefined where the user will end up after logout, which is not an issue
# if the user was finished with Krill, but is annoying if the logout was done
# in order to re-login to Krill as a different user. At least one provider has
# been observed which does NOT support this endpoint.
#
# As an alternative Krill also supports "revocation_endpoint"
# (see https://tools.ietf.org/html/rfc7009 "OAuth 2.0 Token Revocation") which
# is used to terminate the users login session at the provider without leaving
# the Krill web UI.
#
# Finally if neither of these mechanisms are supported a logout_url can be
# specified explicitly via configuration.
#
# References:
# *1: https://openid.net/specs/openid-connect-session-1_0.html
# *2: https://openid.net/specs/openid-connect-rpinitiated-1_0.html
# *3: https://tools.ietf.org/html/rfc7009
#
# ------------------------------------------------------------------------------
# Example RedHat KeyCloak configuration:
# ------------------------------------------------------------------------------
# This example is for a local test deployment of RedHat KeyCloak:
#
# [auth_openidconnect]
# issuer_url = "http://localhost:8082/auth/realms/myrealm"
# client_id = "krill"
# client_secret = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
#
# That's it! For this to work you must already have configured your KeyCloak
# instance e.g. with a realm, client (with redirect URI set), users and an
# attribute mapper (to expose a custom user attribute as a "role" claim) and a
# "role" attribute for each user.
#
# ------------------------------------------------------------------------------
# Example Azure Active Directory configuration:
# ------------------------------------------------------------------------------
# This example is for a Microsoft Azure cloud Active Directory instance that
# permits only read-only and read-write access to users that login via the
# Krill web UI:
#
# [auth_openidconnect]
# issuer_url = "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0"
# client_id = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
# client_secret = "zzzzzzzz"
# extra_login_scopes = ["offline_access"]
#
# [[auth_openidconnect.id_claims]]
# claim = "name"
#
# [[auth_openidconnect.role_claims]]
# claim = "role"
# match = "^gggggggg-gggg-gggg-gggg-gggggggggggg$"
# subst = "readonly"
#
# [[auth_openidconnect.role_claims]]
# claim = "role"
# match = "^hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh$"
# subst = "readwrite"
#
# For this to work you must already have configured in the Azure portal your
# AD tenant, app registration and enterprise application settings (with
# redirect URI), users, group assignments and optional claim configuration
# (in the above example AD was configured to expose groups as roles).
#
# The 'match' expression matches on Azure AD group GUID values, taking the
# first match it finds and then setting the "role" attribute to either
# "readonly" or "readwrite" depending on which GUID was matched. The GUIDs
# for your groups will be different than those used in this example, see your
# Krill log for the GUIDs to match on.
#
# The offline_access scope is required in order to trigger Azure Active
# Directory to issue a refresh token to Krill.
#
# ------------------------------------------------------------------------------
# Example Amazon Web Services Cognito configuration:
# ------------------------------------------------------------------------------
# [auth_openidconnect]
# issuer_url = "https://cognito-idp.eu-central-1.amazonaws.com/eu-central-1_xxxxxxx"
# client_id = "yyyyyyyy"
# client_secret = "zzzzzzzz"
# logout_url = "https://dddddddd.auth.eu-central-1.amazoncognito.com/logout?client_id=yyyyyyyy&logout_uri=https://your.krill.domain/"
#
# [[auth_openidconnect.role_claims]]
# claim = "cognito:groups"
# match = "^KrillAdmins$"
# subst = "admin"
#
# For this to work you must already have configured in the AWS Cognito console
# a group called KrillAdmins and have added the logging in user to that group.
# Otherwise the "cognito:groups" claim will not be present in the ID token
# response issued by AWS Cognito. You also need to have set a "Sign Out URL"
# for in your AWS Cognito "App client settings" which should match the value
# you use for the "logout_uri" query parameter in the logout_url Krill
# setting.
#
# logout_url needs to be set because AWS Cognito doesn't advertise support for
# any of the OpenID Connect logout mechanisms that Krill understands.
#
# dddddddd should be replaced by your AWS Cognito domain prefix that you
# specified in hte AWS Cognito "App integration" -> "Domain name" console
# setting. The regions in the URLs should also match those that you are using.
#
#
# ------------------------------------------------------------------------------
# Example Google Cloud Platform configuration:
# ------------------------------------------------------------------------------
# [auth_openidconnect]
# issuer_url = "https://accounts.google.com/.well-known/openid-configuration"
# client_id = "xxxxxxxx.apps.googleusercontent.com"
# client_secret = "yyyyyyyy"
# extra_login_scopes = ["profile"]
#
# [[auth_openidconnect.role_claims]]
# claim = "picture"
# match = "^.+photo\.jpg$"
# subst = "admin"
#
# For this to work you must already have created Credentials in the Google
# developer console and have set the redirect URI to your Krill API
# /auth/callback public URL.
#
# In this example we have included the ".well-known/..." part of the
# issuer_url to demonstrate that Krill will accept the URL with or without
# it.
#
# The match expression in this example is not a useful real world example as
# it grants "admin" rights to any Google account that has an associated
# picture whose URL ends in photo.jpg.
#
# Note that, while not visible in the configuration above, the GCP OpenID
# Connect provider advertizes an RFC 7009 OAuth 2.0 Token Revocation
# compatible `revocation_endpoint` which Krill will use to revoke the Google
# login token when the user logs out of Krill.
# Auth roles (optional)
#
# What an authenticated user has access to is configured through roles. Each
# role contains a set of permissions that are granted to any user having this
# role. Optional, the role allows limiting the CAs that these permissions
# apply to.
#
# Roles are defined through the 'auth_roles' configuration value.
#
# Syntax:
# auth_roles = { "role name": { ... }, ... }
#
# Alternative syntax:
# [auth_roles]
# "role_name" = { ... }
# ...
#
# "role_name" is the name of the role referenced in either the config file
# provider’s user table or the OpenID Connect providers’s role attribute.
#
# The { ... } above can contain the following fields:
#
# Field Mandatory? Notes
# --------------------------------------------------------------------------
#
# permissions Yes A list of permissions to be granted to the
# role. The following permissions currently
# exist:
#
# login log into the Krill UI
#
# Access to the publication server:
#
# pub-admin, pub-list, pub-read, pub-create,
# pub-delete
#
# Access to CAs
#
# ca-list, ca-read, ca-create, ca-update,
# ca-admin, ca-delete
#
# Access to the ROAs of a CA
#
# routes-read, routes-update, routes-analysis
#
# Access to the ASPAs of a CA
#
# aspas-read, aspas-update, aspas-analysis
#
# Access to the router keys of a CA
#
# bgpsec-read, bgpsec-update
#
# cas No A list of CA handles that the role should
# grant access to. If this field is missing,
# access is granted to all CAs.
#
# If the [auth_roles] section is missing, three default roles will be
# used. These are:
#
# admin Allows full acess to everything
# readonly Allows list and read access to everything.
# readwrite Allows read, create, update, and delete access to everything.
#
### [auth_roles]
### ...
Reference in New Issue View Git Blame Copy Permalink