You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 13
Next »
Syndeia Cloud offers delegated authentication to industry-standard and commercial LDAP Identity Providers
In LDAP authentication, Syndeia Cloud connects to your organization’s LDAP server for authentication. Only the LDAP username is stored on Syndeia Cloud, and authentication is handled by your LDAP server for Syndeia Cloud.
Preparation Tasks
Deploy Syndeia Cloud according to Intercax Documentation.
Read as much of https://ldap.com/learn-about-ldap/ as you need to be fluent in LDAP terms and administration.
Browse to and authenticate into your organization’s choice of IdP’s administration web site (or LDAP Directory desktop utility such as Azure AD or Apache Directory Studio)
Enter the integrations management portion of this administration web site
Find or Create a new LDAP service for the IdP’s users
Browse the IdP’s LDAP “tree” to discover all of the following
The administrator credentials necessary to bind to the LDAP query URL to search the entire tree for groups and users
the IdP might grant query rights to anonymous users but often a client user or script has to provide administrator credentials to query the IdP (via LDAP) for the existence of other user identities
This is the “Bind Distinguished Name” (Bind DN) and its password
The topmost node in the LDAP tree where user identities are stored.
The topmost node in the LDAP tree where groups are defined
If you are setting up an LDAP service for the organization, you will need to configure the LDAP tree before attempting to integrate Syndeia with the LDAP service.
With LDAP, all management of user identities and of permissible passwords are all the responsibility and choice of the organization.
Users in the organization will not be able to access Syndeia Cloud through LDAP until the organization grants them, through the administration in the LDAP IdP, an LDAP user identifier that has a password and an email address.
ssh log into the Syndeia Cloud server with a user that can perform “passwordless sudo” operations. Root access is not necessary, if sudo access has been established.
cd to /opt/icx/syndeia-cloud-current/confs/web-gateway-impl/conf
copy all of the following into silhouette.conf
, adding or replacing any existing ldap.
settings.
Replace all EXAMPLE values – like MYCOMPANY.MYCOM:LDAPPORT
– with the values for your organization.
slihouette.conf template
# LDAP provider
ldap.hostname="MYLDAPSERVICE.MYCOMPANY.MYCOM"
# ldap.port=389|636(TLS)|<custom>
ldap.port=LDAPPORT
ldap.baseDN="dc=MYCOMPANY,dc=MYCOM"
ldap.adminUserDN="cn=MYADMIN,ou=MYADMINGROUP,dc=MYCOMPANY,dc=MYCOM"
ldap.adminPassword="MYADMINPASS"
ldap.userBindAttribute="uid"
ldap.mailAttribute="userPrincipalName"
# [optional]: For SSL/TLS + certificate-based LDAPS
# ldap.startTLS=false|true
ldap.startTLS=false
ldap.truststorePath=""
ldap.truststorePassword=""
ldap.trustStoreType = ""
# ldap.trustAllCertificates=true|false
ldap.trustAllCertificates=true
# --------------------------------------------------
# If you want to limit Syndeia access to the members of
# a single LDAP group, then supply appropriate values for each and every one of
# the group settings below in addition to the settings for the general LDAP authentication.
# --------------------------------------------------
#
# Base DN where Syndeia looks for <memberAttribute> to identify groups and/or users to authenticate for Syndeia Cloud
# ldap.groupSettings.dn="ou=MYTEAMS,dc=MYCOMPANY,dc=MYCOM"
#
# Necessary OU attribute value to help Syndeia identify LDAP group nodes
# Syndeia will search through nested groups of any depth but all must be within the base DN above specified in ldap.groupSettings.dn)
# ldap.groupSettings.ou="groups"
#
# Simple name of the group used to restrict access to Syndeia Cloud
# ldap.groupSettings.name="MYSYNDEIAUSERGROUP"
#
# Attribute used to indicate group instances
# for example, given a DN: "cn=MYSYNDEIAUSERGROUP,ou=MYTEAMS,dc=MYCOMPANY,dc=MYCOM", then use "cn" next
# ldap.groupSettings.bindAttribute="cn"
#
# Attribute used in group instances to indicate members of that group
# ldap.groupSettings.memberAttribute="uniqueMember"
Curious about the purpose of each and every setting? Expand this:
Purpose of each Syndeia Silhouette LDAP setting
Setting | Purpose | Mandatory? | Typical |
---|
ldap.hostname
| names the server that is providing the LDAP service | YES | ldap.company.com |
ldap.port
| identifies the port on the LDAP server | YES | 389 or 636 |
ldap.adminUserDN
| the LDAP Distinguished Name for the LDAP Administrator | Usually | cn=MYADMIN,ou=MYADMINGROUP,dc=MYCOMPANY,dc=MYCOM |
ldap.adminPassword
| encrypted value of the LDAP Admin’s password | Usually | MYADMINPASS (like #$%^&*_NOSOUPFORYOU) |
ldap.baseDN
| base Distinguished Name for the start of user queries | YES | ou=MYUSERS,dc=MYCOMPANY,dc=MYCOM |
ldap.userBindAttribute
| organization’s choice of LDAP attribute that uniquely identifies each user even without a full DN | YES | uid or sAMAccountName |
ldap.mailAttribute
| organization’s choice of LDAP attribute that uniquely identifies each user’s Email address | YES | email or userPrincipalName |
ldap.startTLS
| should Syndeia first attempt to establish an HTTPS session with the LDAP service before making queries? | YES | false for LDAP, true for Secure-LDAP |
ldap.trustAllCertificates
| should Syndeia allow the LDAP service to use an untrustworthy or self-signed SSL certificate? | YES | false (production), true (testing) |
ldap.truststorePath
| file location on the Syndeia server for the Java Keystore which holds public certificates that sign the public SSL certificate used by the LDAP server | NO | /opt/icx/syndeia-cloud-current/some/secure/path/to/keystore.jks |
ldap.truststorePassword
| password for the JKS file at ldap.truststorePath | NO | Often it is left as “changeme” - but it should be changed when it a proper JKS keystore is being used |
ldap.trustStoreType
| the type of Keystore. JKS is typical. This depends on what the running JVM has been configured to support. | NO | “jks” - but only when a ldap.truststorePath is present. |
ldap.groupSettings.dn
| Distinguished Name for where to start looking for LDAP Group instances | NO | ou=MYTEAMS,dc=MYCOMPANY,dc=MYCOM |
ldap.groupSettings.ou
| A string within an OU value that identifies a Group instance | NO | MYTEAMS |
ldap.groupSettings.name
| a common name value that indicates the team of Syndeia Users | NO | MYSYNDEIAUSERGROUP |
ldap.groupSettings.bindAttribute
| the LDAP attribute in a group instance that identifies the common name | NO | cn |
ldap.groupSettings.memberAttribute
| the LDAP attribute in a group instance that identifies one or more member entries | NO | member or uniqueMember |
Operation
Restart the web-gateway service
sudo systemctl restart sc-web-gateway
At this point, if a user authenticates via LDAP with the Syndeia client, it should automatically create an account with default user read-level permissions, ie: you can open a project and read information but not create new connections, repositories, or projects.
When a user requires more permissions, use the User Management feature in the Web Admin Portal to change this.