Authentication backends

rudder.auth.provider=ldap,file

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

---- 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 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
# enought rights to be able to walk the user branch configured below.
# LDAP dn, no default value.
#
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

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

---- 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 preferred 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 ----