###############################################################################
#                                                                             #
# Configuration for LDAP-Based Authentication to the						  #
# Administrative Console/API and/or role assignment                           #
#                                                                             #
###############################################################################

#
# This file is used to configure LDAP for authenticating users and granting
# them permissions in PingFederate based on their role assignment(s) in LDAP.
#
# Note: It can also be used only for defining permissions when RADIUS is used
# as the authentication mechanism (see radius.properties). In this case, LDAP
# Group-Based Permissions should be used to define such permissions.
#

# *****************************************************************************
#                         Basic Connection Properties
# *****************************************************************************

# ===================
# Required Attributes
# ===================

# Note that the following are all required attributes, regardless of the
# method that you are using for permission management--LDAP User or LDAP
# Group:
#
# - LDAP server address (ldap.url)
# - LDAP credentials (ldap.username, and ldap.password), if anonymous
#   binding to the LDAP server is not set, or is set to false
# - Search Base (search.base)
# - Search Filter (search.filter)


# ------------------------------
# LDAP server address (REQUIRED)
# ------------------------------

# For failover configuration, you may supply multiple URLs in the following
# property, separated by a space.  PingFederate will attempt to make a
# connection to each server in the order listed until a successful connection
# is obtained.  Please note that if multiple servers are specified, they must
# all use the same credentials and the same protocol.
#
# To enable SSL for a particular connection, use the LDAPS protocol.
#
#   Example (using multiple URLs):
#     ldap.url=ldaps://server1:636 ldaps://server2:636
#
# Note: For LDAPS, the SSL certificate or any portion of the certificate
# chain must be trusted either as part of cacerts in the Java runtime or
# as a Trusted CA in PingFederate.
#
ldap.url=ldaps://ldap.int.wal-ping.com:636


# -------------------------------
# LDAP Binding for Authentication
# -------------------------------
# Uncomment the property below to use anonymous binding for user-search
# operations.  Otherwise, credentials must be provided below.
#
# Note: The directory server must be set to allow anonymous access, and
# anonymous access rights in the LDAP server must include user-search
# privileges.
#
# The allowed values for the following property are true|false.  The default
# value is false if unspecified.
#
#ldap.anonymousBinding=true



# ------------------------------------------------------------
# LDAP credentials (REQUIRED, if anonymous binding is not set)
# ------------------------------------------------------------

# Set credentials if the ldap.anonymousBinding property above is not used or
# set to false.

#   ----------------------------------------------------
#   Username (REQUIRED, if anonymous binding is not set)
#   ----------------------------------------------------
# This is the username for an account within the LDAP Directory Server
# that can be used to perform user lookups for authentication and other
# user level search operations.
#
#   Example for Oracle Directory Server:
#     ldap.username=UID=user1,OU=People,DC=domain,DC=com
#
#   Example for Microsoft Active Directory:
#     ldap.username=CN=user1,CN=Users,DC=domain,DC=com
#
ldap.username=cn=Administrator,DC=wal-ping,DC=com


#   ----------------------------------------------------
#   Password (REQUIRED, if anonymous binding is not set)
#   ----------------------------------------------------
# This is the password for the Username specified above.
#
# The password property should be obfuscated using one the following
# utilities in this directory (../bin):
#
#   On Windows:
#     >obfuscate.bat <password>
#
#   On Linux:
#     >./obfuscate.sh <password>
#
#   Example:
#     obfuscate.bat secret
#       Result:
#       OBF:JWE:eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2Iiwia2lkIjoiVEU0dVZjcU1wayIsInZlcnNpb24iOiI3LjEuMjAwLjQtU05BUFNIT1QifQ..8Zf_xQ4PuXuYkdE0culPpA.E2Lh_zAne5YpaJo9wbl39A.Z8wVd6SFB8lcQbvutU1u-Q
#   Copy complete result into property value, as shown in the example below:
#     ldap.password=OBF:JWE:eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2Iiwia2lkIjoiVEU0dVZjcU1wayIsInZlcnNpb24iOiI3LjEuMjAwLjQtU05BUFNIT1QifQ..8Zf_xQ4PuXuYkdE0culPpA.E2Lh_zAne5YpaJo9wbl39A.Z8wVd6SFB8lcQbvutU1u-Q
#
ldap.password=OBF:JWE:eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2Iiwia2lkIjoiRXUyZHNEQ0dGdSIsInZlcnNpb24iOiI4LjMuMC4xIn0..p8RohE_u7rVyJ5prrp4NIQ.ifiucAHw-_081VQalRzQAw.V0pSuAcq_RDqa32ZTJV1NQ

# -------
# Timeout
# -------

# Connection creation timeout period in milliseconds. This is the amount of
# time the PF server will wait before failing the connection.  If the value
# is 0, the PF server will wait indefinitely for a response from
# the LDAP server.
#
ldap.connectTimeout=10000

# Read timeout period in milliseconds. This is the amount of time in milliseconds
# that PF will wait for a response from the server.  If the value
# is 0, the PF server will wait indefinitely for a read response from
# the LDAP server.
ldap.readTimeout=3000

# ----------------------
# Search Base (REQUIRED)
# ----------------------

# This is the location in the LDAP directory server from which the search
# begins.  This is used for both initial user authentication, as well as for
# determining LDAP Username based permissions.
#
#   Example for Oracle Directory Server:
#     search.base=OU=People,DC=domain,DC=com
#
#   Example for Microsoft Active Directory:
#     search.base=CN=Users,DC=domain,DC=com
#
search.base=DC=wal-ping,DC=com


# ------------------------
# Search Filter (REQUIRED)
# ------------------------

# This is the mapping from the Username entered in the login form to the
# attribute in the User object that contains the value of the Username that
# matches.  This is used for both initial user authentication, as well as for
# determining LDAP Username based permissions.
#
# The form of this entry is <attribute>={<value>}, where <attribute> is the
# name of the attribute in the user object that is used to compare to the
# name that is entered on the login page for authentication.
#
# In most cases, {<value>} should be {0}, which is the value of a variable
# that contains the Username entered by the administrator in the login form.
#
#   Example for Oracle Directory Server:
#     search.filter=uid={0}
#     In this case, the uid attribute in the user object will be used for
#     username matching.
#
#     search.filter=CN={0}
#     In this case, the CN attribute in the user object will be used for
#     username matching.
#
#   Example for Microsoft Active Directory:
#     search.filter=sAMAccountName={0}
#     In this case, sAMAccountName is the attribute in the user object that
#     will be used for username matching.
#
search.filter=CN={0}


# *****************************************************************************
#                         Assignment of Permissions
# *****************************************************************************

# There are two ways that role assignments (and the permissions associated
# with those roles) may be managed:
# 1) based solely on an explicit mapping between PingFederate roles and
#    individual user accounts, and
# 2) based on a mapping between PingFederate roles and LDAP Groups
#
# Notes:
# - At least one of the above methods must be used, although both may be used.
# - When LDAP user-based assignment is used, users may be assigned to multiple
#   roles.  In this event, the permissions associated with each of the assigned
#   roles are merged.
# - When LDAP Group-based assignment is used, if a user belongs to
#   multiple LDAP Groups and each Group is assigned separate roles within
#   PingFederate, then permissions for that user are merged based on the
#   individual assignments of roles to Groups
# - If permissions are specified using both LDAP user- and Group-based (a.k.a.:
#   "role-based") assignments, the permissions associated with resolution of all
#   of the assignments are merged.
# - The PingFederate auditor role supersedes all other roles. If a user
#   is assigned multiple roles (regardless of the mechanism used) and one of those
#   roles is auditor, the user will retain only those privileges that are
#   associated with the auditor role.


# ===========================
# LDAP User-Based Permissions
# ===========================

# In this mode, you assign LDAP user accounts directly to PingFederate
# administrative roles to specify who has access and what permissions
# they have. For more information on PingFederate roles, see the PingFederate
# Administrator's Manual).
#
# If multiple users are assigned to a single role, each subsequent user must
# be separated from the preceding user by a comma (i.e., comma-separated
# values).
#
# Any special characters in the username must be double-escaped
# (e.g., "\\," for ",").  See RFC 2253 for a list of characters that need
# escaping.
#
#   Example:
#     role.admin=user1, user2
#     role.cryptoManager=user2
#     role.auditor=user3
#     role.userAdmin=user1
#   In this example, user1 will have permissions associated with the "admin" and "userAdmin"
#   roles, and user2 will have permissions associated with both the "admin" role
#   role and the "cryptoManager" role, while user3 will have permissions
#   associated only with the "auditor" role. (Note: the auditor role overrides
#   the privileges associated with assignment of any other role for the same
#   user.)
#
role.admin=
role.cryptoManager=
role.auditor=
role.userAdmin=



# ============================
# LDAP Group-Based Permissions
# ============================

# There are two ways to map roles from LDAP:
# A) By mapping an attribute stored in the LDAP User object to the PF Admin
#    role.  This occurs if the role.search.user.attribute is set.  This is
#    more useful for those directory servers that support a two-way mapping
#    between the User objects and the Group objects (such as Microsoft Active
#    Directory).
# B) By mapping an attribute stored in the LDAP Group object in the LDAP
#    Directory to the PF Admin role.  This occurs if the role.search.attribute
#    is set. This is more useful for those directory servers that support only
#    a one-way mapping from the Group object to the User object (such as Oracle
#    Directory Server).
#
# If neither of the properties above is set, then only the simple username to
# role mapping (LDAP User-Based Permissions defined above) is used.
#
# If you use option A above for LDAP Group-based permissions,
# then each of the following attributes need to be specified:
# - Role Attribute Stored in LDAP User Object (role.search.user.attribute)
# - Role Mapping  (the role.map.* attributes, based on the role assignments
#   that need to be made).
# In this case, the role mapping(s) must be specified using the Group DN
# of the Group that is assigned the role.  In addition, if multiple Groups are
# assigned to a given role, each Group assignment must be defined on its own
# line, using the numbering convention defined below under "Role Mapping."
#
# If you use option B above for LDAP Group-based permissions,
# then all of the following attributes must be specified:
# - Role Attribute Stored in LDAP Group Object (role.search.attribute)
# - LDAP Group Base DN (role.search.base)
# - LDAP Group Subtree Search (role.search.subtree).
# - LDAP Group Search Filter (role.search.filter)
# - Role Mapping (the role.map.* attributes, based on the role assignments
#   that need to be made)
#
# If both options A and B are used, option A takes precedence; properties
# associated with option B are ignored.


# -----------------------------------------
# Role Attribute Stored in LDAP User Object
# -----------------------------------------

# This is the attribute name on the user object that contains the mapping to
# the LDAP Group object(s) used to determine access to the PF Admin
# Console/API.  If the user object contains any of the LDAP Groups that are
# mapped in the Role Mapping below, then the user will be given access and
# the associated permissions based on that mapping.
#
# This property must be a string and can have multiple values.
#
#   Example for Active Directory
#     role.search.user.attribute=memberOf
#
role.search.user.attribute=



# ------------------------------------------
# Role Attribute Stored in LDAP Group Object
# ------------------------------------------

# This property is the name of an attribute contained within the LDAP Group
# object(s) returned from the search (as specified in the role.search.filter
# property) that will be used to map to the Role Mapping as specified below.
# This is typically the DN for the LDAP Group object.
#
# This property can have multiple values, but it must be a string.  It can be the
# special four-character string "<DN>" which means that the Group entry DN should
# be used instead of the value of a specific named attribute.
#
# NOTE:  If the DN is used, then the value of the DN for the LDAP Group object
# needs to be specified in the Role Mapping below.  Similarly, if another
# attribute is used, then any of the values for each of the LDAP Group objects
# returned from the search should be used in the Role Mapping below.
#
#   Example 1:
#     role.search.attribute=<DN>
#
#   Example 2:
#     role.search.attribute=uid
#
role.search.attribute=<DN>



# ------------------
# LDAP Group Base DN
# ------------------

# This is the Base DN for searching the directory for the LDAP Group Objects.
#
#   Example for Oracle Directory Server:
#     role.search.base=OU=People,DC=domain,DC=com
#
role.search.base=OU=groups,DC=wal-ping,DC=com



# -------------------------
# LDAP Group Subtree Search
# -------------------------

# This attribute defines whether the search should stay at the level of the
# node defined by the role.search.base attribute, or whether it should also
# search subnodes of the node defined by the role.search.base attribute.
# Allowed values for this property are true|false.  The default value is true
# if it is unspecified.
#
role.search.subtree=false



# ------------------------
# LDAP Group Search Filter
# ------------------------

# This is the search filter that should be used to determine Group membership.
# Typically, this can be set to the attribute in the Group object that is used
# to store the list of users that belong to that Group.  This is of the form
# <attribute>=<value>.  <attribute> should be the name of the attribute in the
# LDAP Group object that maintains membership information for that LDAP Group.
# <value> is the value that will be matched to determine membership.  <value>
# can be set to either of the following:
#   {0} - username.       This means that the LDAP Group stores its membership
#                         information in the form of the username entered
#                         at the time that authentication occurs.
#   {1} - user entry DN.  This means that the LDAP Group Object stores its
#                         membership information in the form of the DN of each
#                         of the LDAP User objects that belong to that LDAP
#                         Group.  In this case, the username entered
#                         at the time authentication occurs will be used to
#                         look up the DN for the associated User Object, which
#                         will subsequently be used to look up that DN within
#                         each LDAP Group object that contains it.
#
#   Example 1:
#     role.search.filter=member={1}
#     In this example, the search will be for all objects that contain an
#     attribute named member, with the value based on the User Object DN.
#
#   Example 2:
#     role.search.filter=(&(member={1})(objectClass=group))
#     This example is similar to Example 1.  However, the search is restricted
#     to only those objects where the objectClass is Group.  This allows for
#     a further refinement of search filters for more efficient lookups.
#
role.search.filter=(&(member={1})(objectClass=groupOfNames))



# ------------
# Role Mapping
# ------------

# This set of properties map the membership information to the
# associated role(s) and permissions defined within PingFederate.
# Please note that trailing white spaces are not trimmed, so care should be
# taken when entering this information.  Unless specifically identified
# as a DN (i.e., via role.search.attribute above), DNs are not parsed and
# will be compared exactly as entered.
#
# Any special characters in the value that needs to be evaluated
# must be escaped (e.g., "\ " for " ").  This is also true for spaces that
# occur at the beginning of the string.  See the Javadoc for the load method
# for the java.util.Properties class for a definitive description of what
# characters need to be escaped and how escaping should occur.
#
# The configuration values are case-sensitive.
#
# Only one value can be entered per line. If multiple LDAP Groups map to one
# PingFederate role, then multiple properties must be created using a numeric,
# incremental suffix, starting with 1. For example:
#     role.map.admin.1=
#     role.map.admin.2=
#     role.map.admin.3=
#
#   Example Mapping:
#     role.map.admin=CN=PFAdminGroup,OU=People,DC=domain,DC=com
#     role.map.cryptoManager=CN=PFCryptoGroup,OU=People,DC=domain,DC=com
#     role.map.auditor=CN=PFAuditorGroup,OU=People,DC=domain,DC=com
#     role.map.userAdmin=CN=PFUserAdminGroup,OU=People,DC=domain,DC=com
#
# Note:the auditor role overrides the privileges associated with assignment of
# any other role for the same user.
role.map.admin=CN=administrator,OU=groups,DC=wal-ping,DC=com
role.map.cryptoManager=CN=administrator,OU=groups,DC=wal-ping,DC=com
role.map.auditor=CN=manager,OU=groups,DC=wal-ping,dc=com
role.map.userAdmin=