##############################################################################
#                                                                            #
#           ----==== 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]
### ...

