Authentication backends

rudder.auth.provider=ldap

rudder.auth.provider=ldap,file

<authentication hash="sha512" case-sensitivity="true">
  <user name="admin" password="ab7f...b8a538dc69dd8de907ec" role="administrator" />
  <user name="joe" password="LDAP" role="administrator" />
</authentication>

#
# update provider:
#
rudder.auth.provider=ldap

---- copy into new file /opt/rudder/etc/rudder-web.properties.d/20-ldap-authentication.properties ----


###########################
# LDAP Authentication      #############################################################
###########################


# The following parameters allow to configure the LDAP authentication provider.
# The LDAP authentication procedure is a typical bind/search/rebind, in which
# an application connection (bind) is used to search (search) for an user entry
# given some base and filter parameters, and then, a bind (rebind) is tried on
# that entry with the credential provided by the user.
# That allows to separate the user DN (especially RDN) from the search criteria while
# in the same time supporting users located in several different organisational units.
#
# Be careful, authorizations are still done based on the content of rudder-user.xml,
# meaning that each user should have access to Rudder MUST have a line in that file.
# Without that line, the user can have a successful LDAP authentication, but
# won't be able to do or see anything in Rudder (only logout).
#

# === EXAMPLE / ldapsearch test===
#
# With the example data below, if the user "jon.doe" try to login with password "mypasswd",
# the corresponding `ldapsearch` request are:
#
# 1/ search for user with `service` login:
# ----
# $ ldapsearch -LLL -o ldif-wrap=no -h ldap.mycorp.com -p 389 -x -D "cn=rudder,ou=services,dc=mycorp,dc=com" -w secret -b "ou=Users,dc=mycorp,dc=com" -s sub '(&(cn=jon.doe)(objectclass=person))' 1.1
#
#  dn: cn=jon.doe,ou=Paris,ou=Users,dc=mycorp,dc=com
# ----
#
# Errors and unexpected:
# - an authentication error here means that your rudder service user does not have the
#   rights to do a search and will not be able to find the corresponding user full DN;
# - you should get exactly one result: the DN to use in the second request. If you don't
#   get any results, check the base DN and the LDAP filter.
#
# 2/ bind request with user DN (search user own entry with its credentials):
# ----
# $ ldapsearch -LLL -o ldif-wrap=no -h ldap.mycorp.com -p 389 -x -D "cn=jon.doe,ou=Paris,ou=Users,dc=mycorp,dc=com" -w mypasswd -b "cn=jon.doe,ou=Paris,ou=Users,dc=mycorp,dc=com" -s base 1.1
#
# dn: cn=jon.doe,ou=Paris,ou=Users,dc=mycorp,dc=com
# ----
#
# Errors and unexpected:
# - an authentication error here is likely to mean that the user password is not correct,
#   but you should also check your LDAP directory ACLs.
#

#
# Connection URL to the LDAP server, in the form:
# ldap://hostname:port/base_dn
#
rudder.auth.ldap.connection.url=ldap://ldap.mycorp.com:389/dc=mycorp,dc=com

#
# Bind DN used by Rudder to do the search. This is the "service" or
# "application" DN for Rudder in you LDAP directory, or an LDAP user with
# enough rights to be able to walk the user branch configured below.
# LDAP dn, no default value.
# Be careful to not add quote around the DN, the value is used as provided.
#
rudder.auth.ldap.connection.bind.dn=cn=rudder,ou=services,dc=mycorp,dc=com

#
# Bind password used by Rudder service (the DN configured just above) to do the search.
# String, no default value.
#
rudder.auth.ldap.connection.bind.password=secret

#
# If your directory uses remote links that need to be dereferenced
# for resolving the actual entry, for example in the case of an
# AD forest, you need to uncomment the following option.
#
# rudder.auth.ldap.connection.derefLink=true

#
# Search base and filter to use to find the user.
# The search base can be left empty. In that
# case, the root of directory is used.
#
rudder.auth.ldap.searchbase=ou=People

#
# In the filter, {0} denotes the value provided as
# login by the user.
# The filter must lead to at most one result, which
# will be used to try the (re)bind request.
#
rudder.auth.ldap.filter=(&(uid={0})(objectclass=person))

#
# An AD example would be:
#
#rudder.auth.ldap.searchbase=
#rudder.auth.ldap.filter=(&(sAMAccountName={0})(objectclass=user))

---- end of ldap authentication properties to copy ----

WARN  application - Login authentication failed for user 'xxx' from IP '127.0.0.1|X-Forwarded-For:xxx.xxx.xxx.xxx': simple bind failed: xxx.xxx:636; nested exception is javax.naming.CommunicationException: simple bind failed:

xxx.xxx:636 [Root exception is java.net.SocketException: Connection or outbound has closed]

# copy the certificate somewhere in /opt/rudder

cd path/to/jdk<in-use-version>/lib/security

keytool -importcert -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias "rudder-ldap-certificate" -file <path to AD server certificate>

Root exception is javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits: RSA 1024 bit key used with certificate

# Authentication provider id in rudder.auth.provider:
# - OAUTHv2       : oauth2
# - OpenID Connect: oidc

# Configure the list of Identity provider services. Here, you choose
# an identifier for each service as a comma separated list.
# Identifier should be lower case ascii, -, _. For example, if
# your company uses both "Okta" and "Google", you can choose "okta" and
# "google" (how original) identifiers:
rudder.auth.oauth2.provider.registrations=okta,google

# Now, configure Okta related properties. You will need to do
# the same for each provider with an identifier.

# The identity service provider name as it will be displayed in Rudder
rudder.auth.oauth2.provider.okta.name=Okta
# A more detailed explanation message displayed in authentication page.
rudder.auth.oauth2.provider.okta.ui.infoMessage=OpenID Connect SSO (Okta)

# In Oauth2/OIDC, a client (ie, Rudder) is identifier by a pair of credentials:
# - 1/ an id,
# - 2/ a corresponding secret key.
#
# 1/ Identifier of the application you created in your IdP for Rudder.
#    In Okta, it will be listed under https://xxxx-admin.okta.com/admin/apps/active
#    once you created it with "Create App Integration". If you click on your application,
#    it's located in "Client Credential > Client ID".
#
rudder.auth.oauth2.provider.okta.client.id=0oa3snkopsIRIIHb35d7
#
# 2/ The corresponding "client secret", provided by your Identity Provider.
#    For Okta, it's available when you click on your application in
#    https://xxxx-admin.okta.com/admin/apps/active in "Client Credential > Client Secret"
rudder.auth.oauth2.provider.okta.client.secret=-0Q5jGbdvV5WkfGNJwHfkOP0FdZ5vhqPYav7icYb
#
# Space separated list of OAUTHv2 "scope" for claims that should be included in the identity
# token once authentication is done. These values should be documented by your IdP documentation.
# Rudder only need to have at least scope which provides the attribute that will be used for
# `userId` (see next property)
rudder.auth.oauth2.provider.okta.scope=openid  email profile
#
# The attribute that will be used for `userId` and login matching with rudder users
# (generally, it's a login or email ; OIDC always provides at least `sub` attribute)
# The value of that attribute will be used to retrieved Rudder internal user, its rights, etc.
rudder.auth.oauth2.provider.okta.userNameAttributeName=email
#
# The next 4 URLs are the redirection URLs towards the IdP and which corresponds to
# each step of the authentication process (yes, the protocol does a lot of redirection):
# - `uri.auth`: first URL, Rudder ask for a code request. User is then redirected by
#    the IdP towards its own login form. It then redirect to Rudder with a code to process.
#    If you need to use extra information like an `acr_values` property, just happen it to that URL
# - `uri.token`: Rudder returned the code processed with its client secret. The IdP process it
     and return an authentication token to Rudder.
# - `uri.userInfo`: Rudder uses the authentication token to get user information on that URL
# - `uri.jwkSet`: in the case of OIDC, the token is a signed JWT token. That last url is the
#   URL where Rudder can get the IdP public key to sign the token.
rudder.auth.oauth2.provider.okta.uri.auth=https://xxxx.okta.com/oauth2/v1/authorize
# With an acr_values:
#rudder.auth.oauth2.provider.okta.uri.auth=https://xxxx.okta.com/oauth2/v1/authorize?acr_values=strongAuthRequired
rudder.auth.oauth2.provider.okta.uri.token=https://xxxx.okta.com/oauth2/v1/token
rudder.auth.oauth2.provider.okta.uri.userInfo=https://xxxx.okta.com/oauth2/v1/userinfo
rudder.auth.oauth2.provider.okta.uri.jwkSet=https://xxxx.okta.com/oauth2/v1/keys
#
# Rudder URL towards which the identity provider redirects, ie the URL seen by the IdP
# for Rudder. Apart if directed to do differently, you should keep the
# part after `rudder`, ie: `/login/oauth2/code/{registrationId}` part.
rudder.auth.oauth2.provider.okta.client.redirect=https://my-external-rudder-hostname/rudder/login/oauth2/code/{registrationId}
#
#
# The following properties are necessary for each provider configuration but should not be modified.
#
# The protocol scheme used for authentication - Rudder only supports with authorisation code.
rudder.auth.oauth2.provider.okta.grantType=authorization_code
# Authentication type - Rudder only supports client_secret_basic and client_secret_post.
rudder.auth.oauth2.provider.okta.authMethod=client_secret_basic

#
# Properties to configure roles and users provisioning through the OIDC token
#
# enable Rudder user role provisioning by the OIDC IdP. Use `true` or `false` (default)
rudder.auth.oauth2.provider.okta.roles.enabled=true

# Name of the OIDC token attribute that will hold rudder roles. This is something that you identity provider
# administrator will give you. The attribute value must be a OAuth list of string, ie in the format:
#  attribute: [role-oidc-a, role-oidc-b, etc]
# Each string will be mapped to a rudder role (or ignored if no matching is found). Default value: empty.
rudder.auth.oauth2.provider.okta.roles.attribute=rudderroles

# Define if the provided list of roles should *override* or *be appended to* the list of roles configured for
#the user in the `rudder-users.xml` file. Use `false` for append (default), `true` for override.
rudder.auth.oauth2.provider.okta.roles.override=true

# Mapping between IdP role name ("entitlements") and Rudder internal naming scheme.
#
# It is common for the IdP to use its own naming scheme, or to have several IdP using
# different naming incompatible naming scheme for roles. The following property allows
# to map an IdP entitlement into a rudder role name (custom or pre-defined)
#
# Unitary right like `node_all` `rule_read` `technique_write` cannot be mapped.
# If none of the pre-defined role suits you, please create a custom role to be able to map it.
# see https://docs.rudder.io/reference/8.1/plugins/user-management.html#_custom_roles
#
# Check the list of pre-defined roles: https://docs.rudder.io/reference/8.1/plugins/user-management.html#_pre_defined_roles
rudder.auth.oauth2.provider.okta.roles.mapping.entitlements.rudder_admin=administrator
rudder.auth.oauth2.provider.okta.roles.mapping.entitlements.rudder_readonly=readonly
# You can restrict the role that The IdP can assign to only role mapped to entitlements.
# When the following properties is true, roles that don't appear in `mapping.entitlements`
# will be filtered-out.
rudder.auth.oauth2.provider.okta.roles.mapping.enforced=true
# In some case, you OIDC provided roles will contains illegal character that can't be use in the
# left part of the `entitlement` key - typically an equal. You can reverse the order of mapping with
# the `reverseEntitlements`, in whicn the Rudder role name is on the left and the OIDC IdP role
# name is on the right. If the same key is defined in both `entitlements` and `reverseEntitlements`,
# then the value defined in `reverseEntitlements` is used.
# In the following example, OIDC role `rudder_readonly` will be mapped to local `readonly2` role,
# overriding the value previously defined above:
#rudder.auth.oauth2.provider.okta.roles.mapping.reverseEntitlements.readonly2=rudder_readonly
# And here, we map the IdP role "name=Alice,ou=users" to Rudder role "readonly"
#rudder.auth.oauth2.provider.okta.roles.mapping.reverseEntitlements.readonly=name=Alice,ou=users

# enable Rudder user provisioning by the OIDC IdP. Use `true` or `false` (default).
# Users provisioned through that channel don't have roles, you will need to also
# provisioned roles thanks to IdP.
rudder.auth.oauth2.provider.okta.enableProvisioning=true