Page Comparison

Syndeia Cloud offers delegated authentication to industry-standard and commercial LDAP Identity Providers

In LDAP authentication, the Syndeia Cloud application (generically referred to here as “Service Provider (SP)”) connects to your organization’s LDAP server (aka “Directory [Store|Server] (DS)”) for authentication. Only the LDAP username is stored on Syndeia Cloud, and authentication is handled by your LDAP server for Syndeia Cloud.

Preparation Tasks

1. Deploy Syndeia Cloud according to Intercax Documentation.

2. Read as much of https://ldap.com/learn-about-ldap/ as you need to be fluent in LDAP terms and administration.

3. Assure that the browsers on the user workstations which are going to interact with Syndeia Web Dashboard and with the chosen DS can connect to both the SP and the DS and that there are no SSL certificate denials.

4. Assure that there are no traffic shapers on the corporate network that alter HTTP Request and HTTP Response Headers - especially those headers involved in LDAP protocols.

5. Assure that there are no network routers or proxies on the corporate network that alter HTTP URLs or HTTP Headers.

6. Obtain the Fully-qualified Network Domain (FQDN) scheme, host, and port of the Syndeia Cloud SP.

...

2. Obtain the FQDN scheme, host, and port of the chosen LDAP DS.

3. Test your assumptions about your organization’s LDAP DS with either curl or ldapsearch - Syndeia uses a third-party library for LDAP queries and if external, simple LDAP queries do not work, your configuration of Syndeia based on incorrect assumptions is not going to be successful.

   1. Read https://devconnected.com/how-to-search-ldap-using-ldapsearch-examples/

Configure the Directory Store/Server (DS)

• Browse to and authenticate into your organization’s choice of IdP’s DS’s administration web site website (or LDAP Directory desktop utility such as Azure AD or Apache Directory Studio)

  • In Syndeia Silhouette, this is the ldap.hostname and ldap.port setting

• Enter the integrations management portion of this administration web sitewebsite

• Find or Create a new LDAP service for the IdP’s DS’s users

• Browse the IdP’s DS’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 DS might grant query rights to anonymous users but often a client user or script has to provide administrator credentials to query the IdP DS (via LDAP) for the existence of other user identities

    • This is the “Bind Distinguished Name” (Bind DN) and its password

      • In Syndeia Silhouette, this is the ldap.adminUserDN and the ldap.adminPassword

  • The topmost node in the LDAP tree where user identities are stored.

    • This is the “Base Distinguished Name” (Base DN)

      • In Syndeia Silhouette, this is the ldap.baseDN

  • 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.

• Assure the LDAP IdP DS has a directory of user identities

• Know which users or groups should be permitted access to the Syndeia Service Provider

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 IdPDS, 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-<SC_version>-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.

  ldap.hostname="MYLDAPSERVICE.MYCOMPANY.MYCOM"
  ldap.baseDN="dc=MYCOMPANY,dc=MYCOM"

The above illustrates how little configuration is mandatory - if the organization has an OpenLDAP service.

  ldap.hostname="MYLDAPSERVICE.MYCOMPANY.MYCOM"
  ldap.baseDN="dc=MYCOMPANY,dc=MYCOM"
  ldap.userBindAttribute="sAMAccountName"
  ldap.mailAttribute="userPrincipalName"

The above illustrates how little configuration is mandatory - if the organization has a Microsoft AD service.

  # LDAP provider
  # The values for hostname, baseDN and adminUserDN are placeholder values.
  # Please provide actual values, and the value for adminPassword, before using an LDAP provider
ldap.
  #
  # the hostname where the LDAP service is served
  # Default if absent is no LDAP service
  #ldap.hostname="MYLDAPSERVICE.MYCOMPANY.MYCOM"

  # the ldap.port=389|636(TLS)|<custom>
ldap.port=LDAPPORT
ldapport on the host for the LDAP service
  # Default if absent is 389 (for insecure LDAP)
  #ldap.port=636

  # Topmost DN where Syndeia looks for users to authenticate for Syndeia Cloud
  # Default if absent is no LDAP service
  #ldap.baseDN="dc=MYCOMPANY,dc=MYCOM"
ldap
  # DN of an LDAP Administrator
  # Default if absent is unauthenticated LDAP searches
  #ldap.adminUserDN="cn=MYADMIN,ou=MYADMINGROUPadmin,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

  # Password for the LDAP Administrator in plain text
  # Default if absent is unauthenticated LDAP searches
  #ldap.adminPassword

  # the LDAP Attribute that indicates a user identity
  # Default if absent is "uid" (MS AD uses sAMAccountName)
  #ldap.userBindAttribute="uid"

  # the LDAP Attribute that indicates each user's email emailAddress
  # Default if absent is "mail"
  #ldap.mailAttribute="mail"

  # should Transport Layer Security be used for the LDAP searches
  # Default if absent is false (must be true for LDAPS)
  #ldap.startTLS=true

  # the SSL Protocol to use for TLS
  # Default if absent is negotiation by client and server
  #ldap.sslProtocol="TLSv1.2"

  # the Cipher to use for TLS
  # Default if absent is negotiation by client and server
  #ldap.sslCipher="TLS_RSA_WITH_AES_256_CBC_SHA256"

  # the path to an SSL certificates trust trustStore
  # Default if absent is all certificates from the LDAP servers are trusted
  #ldap.truststorePath="/some/path/jssecacerts"

  # the password for the SSL certificates trust trustStore
  # Default if absent is the well-known JKS password
  #ldap.truststorePassword="WeReallyDidChangeIt"
  
  # type of the Trust Store
  # Default if absent is jks for a Java Key Store
  #ldap.trustStoreType

  # --------------------------------------------------
  # If you want to limit Syndeia access to the members of
# a single# LDAP groupgroups, then supply appropriate values for each and every one of
#at least one and any more appropriate values
  # for the group settings below in addition to the settings for the general LDAP authentication.
  # Syndeia will search through nested groups of any depth but all Group DNs must be within the DN of ldap.groupSettings.dn
  # --------------------------------------------------
  #
  # BaseTopmost DN where Syndeia looks for <memberAttribute> to identify groups and/or users to authenticate for Syndeia Cloud
  # Default if absent would be the ldap.baseDN for where Users are searched
  # ldap.groupSettings.dn="ou=MYTEAMSMYGROUPS,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 ObjectClass that indicates an entry is a Groups
  # Default if absent would be "groupOfUniqueNames"
  # ldap.groupSettings.objectClass="groupOfUniqueNames"
  #
  # Obsolete OU attribute value to help Syndeia identify LDAP group nodes
  # ldap.groupSettings.ou="groups"
  #
  # Simple name of the group used to restrict access to Syndeia Cloud
  # Default if absent would be the ldap.baseDN for where Users are searched
  # ldap.groupSettings.name="MYSYNDEIAUSERGROUPSyndeiaUsers"
  #
  # Attribute used to indicate group instances
  # Default if absent would be "cn"
  #   for example, given a DN: "cn=MYSYNDEIAUSERGROUPSyndeiaUsers,ou=MYTEAMSMYGROUPS,dc=MYCOMPANY,dc=MYCOM", then use "cn" next
  # ldap.groupSettings.bindAttribute="cn"
  #
  # Attribute used in group instances to indicate members of that group
  # Default if absent would be "uniqueMember"
  # ldap.groupSettings.memberAttribute="uniqueMember"
  

Curious about the purpose of each and every setting? Expand this:

Operation

1. Restart the web-gateway service

   1. sudo systemctl restart sc-web-gateway

...

2. Open a modern web browser (Chrome, Edge, Safari) and visit http:SYNDEIA.MYCOMPANY.MYCOM:MYSYNDEIAPORT/login or https:SYNDEIA.MYCOMPANY.MYCOM:MYSECURESYNDEIAPORT/login

3. In the Login Form dialog, enter the LDAP user credentials for an existing LDAP user that is within the ldap.baseDN tree or within the ldap.groupSettings.name LDAP Group (if group-limited LDAP access was configured)

4. Choose LDAP from the Account chooser

When a user authenticates via LDAP with the into Syndeia client, it should automatically create Syndeia will create Just In Time an account with default rudimentary user read-level permissions , ie: you can open a project and read information but not create new connections, repositories, or projects- if the account is not already present.

When a user requires more permissions, use the User Management feature in the Web Admin Portal to change this.