Authentication backends

This plugins allows to use alternative authentication backends for Rudder: LDAP/AD and radius.

Rudder compatibility and breaking changes

Version 5.0-1.2 needs Rudder 5.0.2 or above

There was a problem in the initialization order that cause the plugin backends to never be loaded correctly.

Configure enabled backends

By default, both authentication and authorization are handle in the rudder-users.xml file. But you may want to rely on your existing entreprise Active Directory or LDAP to take care of the authentication part. To choose the scheme to use, either use 'file' or 'ldap' for the rudder.auth.provider parameter. You can also use a comma separated list of authentication provider to use, like 'ldap,file' in which case each one will be tested in turned for authentication.

When set to 'ldap' or 'radius', passwords in rudder-users.xml are ignored and the authentication is delegated to the LDAP or radius server configured.

By convention, when LDAP authentication is enable, 'password' field in rudder-users.xml are set to 'LDAP'.

For example, to use first and ldap authentication, and then in case the user is not found in ldap, fall-back in file authentication, you will specify:

rudder.auth.provider=ldap,file

For example, that rudder-users.xml file will configure "admin" by file access, and "joe" by LDAP:

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

Be careful to have only one rudder.auth.provider property in your file!

In case your authentication backend does not work, you can still configure the rootAccount in /opt/rudder/etc/rudder-web.properties to regain an administrator access. Once logged as an administrator, you can go to the Plugins > Authentication Backends page to check that Rudder interpreted correctly your configuration.

In particular, check that Computed list of providers entry matches your will.

LDAP / AD backend

The configuration properties that need to be added in /opt/rudder/etc/rudder-web.properties file to configure the LDAP or AD authentication backend are displayed below.

For convenience, the part betweeb ---- add in rudder-web.properties ---- and ---- end of add in rudder-web.properties ---- can be directly added in your /opt/rudder/etc/rudder-web.properties file.

Note that key "rudder.auth.provider" is likelly to already exists. In that case, just update it with the sequence of authentication backend you want to try.

---- add in rudder-web.properties ----

###########################
# Rudder Authentication    #############################################################
###########################

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


###########################
# 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 seperate the user DN (especially RDN) from the search criteria.
#
# Be careful, the authorization is still done in the rudder-user.xml, what means
# 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 (safe logout).
#

#
# 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
# LDAP dn, no default value.
#
rudder.auth.ldap.connection.bind.dn=cn=admin,dc=mycorp,dc=com

#
# Bind password used by Rudder to do the search.
# String, no default value.
#
rudder.auth.ldap.connection.bind.password=secret

#
# 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 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 add in rudder-web.properties ----

Radius backend

Below follow the configuration properties that need to be added in /opt/rudder/etc/rudder-web.properties file to configure the Radius authentication backend.

For convenience, the part under "---- add in rudder-web.properties----" can be directly added in your /opt/rudder/etc/rudder-web.properties file.

Note that key rudder.auth.provider is likelly to already exists. In that case, just update it with the sequence of authentication backend you want to try.

---- add in rudder-web.properties ----

###########################
# Rudder Authentication    #############################################################
###########################

# update provider list:
rudder.auth.provider=radius

###########################
# Radius Authentication    #############################################################
###########################

#
# The following parameters allow to configure authentication with a
# Radius server.
#


#
# Use "radius" auth type to enable radius authentication
#
#rudder.auth.provider=file,radius

#
# IP or hostname of the Radius server. Both work, but it is prefered to use an IP.
#
rudder.auth.radius.host.name=192.168.42.80

#
# Authentication port for the Radius server
#
rudder.auth.radius.host.auth.port=1812

#
# The shared secret as configured in your Radius server for Rudder application / host.
#
rudder.auth.radius.host.sharedSecret=secret

#
# Time to wait in seconds when trying to connect to the server before giving up.
#
rudder.auth.radius.auth.timeout=10

#
# Number of retries to attempt in case of timeout before giving up.
#
rudder.auth.radius.auth.retries=0

#
# Authentication protocol to use to connect to the Radius server. The default
# one is 'pap' (PAP).
# Available protocols::
# - pap
# - chap
# - eap-md5
# - eap-ttls
#
# For `eap-ttls`, you can append `key=value` parameters, separated by `:` to the
# protocol name to specify protocol option, for example:
# `eap-tls:keyFile=keystore:keyPassword=mypass`
#
rudder.auth.radius.auth.protocol=pap

---- end of add in rudder-web.properties ----

← API Authorizations CIS →