Authentication using LDAP

446 views
Skip to first unread message

RBlackmon

unread,
Jan 12, 2018, 2:21:18 PM1/12/18
to RSNA MIRC CTP/TFS User Group
Can the MIRC - TFS implementation support secure LDAP over port 636?

I reviewed the documentation for CTP Authentication Using LDAP, but never saw anything about secure LDAP or port references 389 vs 636

CTP Authentication Using LDAP

From MircWiki

Jump to: navigation, search

This article describes how to configure CTP to use an LDAP server to authenticate users. The intended audience for this article is CTP administrators.

CTP's default authentication mechanism uses an XML file stored in the CTP directory. This file contains one element for each user, specifying the username, password, and the various roles assigned to the user. Roles determine the system functions available to the user. The LDAP authentication mechanism uses the same XML file to provide the roles, but it uses the LDAP server to authenticate the user's credentials (username and password). To be authenticated, a user must be known to both the LDAP server and the XML file. Any passwords contained in the XML file are ignored. The standard CTP User Manager can be used to create users and assign roles in the XML file, but CTP provides no way to update the LDAP server.

The authentication mechanism used by CTP is specified in the LDAP child element of the Server element in the CTP configuration file (config.xml). The Server element is described in the top-level CTP article. To configure CTP to use LDAP authentication, The usersClassName attribute of the Server element must be set to org.rsna.server.UsersLdapFileImpl, and the LDAP child element must be appended to the Server element. The LDAP child element is shown below:

        <LDAP
            initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
            providerURL="ldaps://example.org"
            securityAuthentication="simple"
            securityPrincipal="cn=${username}, ou=people, dc=med, dc=university, dc=edu"
            ldapAdmin="adminUserName"
            referral="ignore"
            derefAliases="never" />

where:

  • initialContextFactory specifies the Java class used to link to the LDAP server. The value shown above is the default. Unless there is a specific reason to specify a different class, it is best to omit this attribute.
  • providerURL specifies the URL of the LDAP server. It typically begins with ldap:// or ldaps://. This URL can be obtained from the LDAP system administrator.
  • securityAuthentication specifies the way the credentials are passed to the server. The default is shown above. Unless there is a reason to use a different value, it is best to omit this attribute.
  • securityPrincipal specifies a string that itentifies where in the LDAP directory to find the user. The string must correspond to the organization of the information in the LDAP server. The example shown above is for one particular university's LDAP implementation. The string is sent to the LDAP server after substituting the username of the user being authenticated for the ${username} token. Other implementations may require different strings. The required string can be obtained from the LDAP system administrator.
  • ldapAdmin specifies the name of a user known to LDAP who is to be given admin privileges in CTP when it starts. There must be at least one user with admin privileges known to LDAP and the XML file in order for anyone to manage the CTP application. When CTP starts, it ensures that a user exists with the specified name in the XML file and it assigns that user the admin role. It does not check that the user exists in the LDAP server nor does it modify any other user in the XML file.
  • referral specifies how to respond to referrals in LDAP searches. The options are ignore and follow. The default is to ignore referrals. In some LDAP systems, it may be necessary to enable following referrals.
  • derefAliases specifies how to whether to dereference aliases in LDAP searches. The options are never and always. The default is never to dereference aliases.

The securityPrincipal attribute supports multiple security principals. For example, if multiple organizational units are to be searched, the attribute can be coded as:

securityPrincipal="cn=${username}, ou=(Radiology|Service), dc=med, dc=university, dc=edu"

This example produces two securityPrincipal values:

cn=${username}, ou=Radiology, dc=med, dc=university, dc=edu

cn=${username}, ou=Service, dc=med, dc=university, dc=edu

Only one set of alternatives is allowed, but there is no limit to the number of alternatives in the set.

Alternatives can encompass multiple values. For example:

securityPrincipal="cn=${username}, (ou=Radiology, dc=med|ou=Service, dc=admin), dc=university, dc=edu"

This example produces two securityPrincipal values:

cn=${username}, ou=Radiology, dc=med, dc=university, dc=edu

cn=${username}, ou=Service, dc=admin, dc=university, dc=edu

The securityPrincipal values are searched in order, left-to-right, until the authentication succeeds. For efficiency, it is best to put the most commonly used alternative first.

LDAPTest

There is a simple test program that may help in finding the right configuration for a specific LDAP server. The program is available at http://mirc.rsna.org/download/LDAPTest.jar. Run the program on any computer that has Java on it and that can communicate with the LDAP Server. It displays a window like this:

 

Error creating thumbnail: Unable to save thumbnail to destination

 

The default values are ones that were used at the University of Michigan when they set up their MIRC site to use LDAP, so they won’t necessarily be useful in your case.

  1. Set the Provider URL field to point to your LDAP server.
  2. In the Security Principal field, change username to a username known to the LDAP server. Change the rest of the Security Principal field to whatever is required on your server.
  3. In the Security Credentials field, put in the user’s password.
  4. Now try clicking the Connect button.

You may need to experiment with the Security Principal field and/or the Search Filter and Returned Attributes until you get something that looks like the server authenticated the user.

The LDAP authentication mechanism in CTP doesn’t use the passwords stored in the CTP/users.xml file. It only uses that file to obtain the roles that have been assigned to an authenticated user.

Retrieved from "http://mircwiki.rsna.org/index.php?title=CTP_Authentication_Using_LDAP&oldid=7908"

 

Inserted from <http://mircwiki.rsna.org/index.php?title=CTP_Authentication_Using_LDAP>

John Perry

unread,
Jan 12, 2018, 2:44:14 PM1/12/18
to rsnas-ctpmir...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "RSNA MIRC CTP/TFS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rsnas-ctpmirc-user...@googlegroups.com.
To post to this group, send email to rsnas-ctpmir...@googlegroups.com.
Visit this group at https://groups.google.com/group/rsnas-ctpmirc-user-group.
For more options, visit https://groups.google.com/d/optout.

John Perry

unread,
Jan 12, 2018, 3:07:42 PM1/12/18
to rsnas-ctpmir...@googlegroups.com
The Javadocs for the LdapUtil class in CTP (https://github.com/johnperry/Util/blob/master/source/java/org/rsna/util/LdapUtil.java) say you can include the protocol and the port in the providerURL parameter:
 
/**
* Authenticate a securityPrincipal with an LDAP provider
* @param initialContextFactory the factory class (e.g., "com.sun.jndi.ldap.LdapCtxFactory")
* @param providerURL the URL of the provider (e.g., "ldap://ip:port/path")
* @param securityAuthentication the authentication type (e.g., "simple")
* @param securityPrincipal the username (e.g., "cn=username, ou=NewHires, o=JNDITutorial"
* @param securityCredentials the password (e.g., "mysecret")
* @param referral whether to follow referrals (default: "ignore")
* @param derefAliases whether to deref aliases (default: "never")
* @return true if the authentication succeeds; false otherwise.
*/
 
I don't have an LDAP server (and I didn't when I wrote this stuff), so Bill Weadock at U. Mich. tested it for me. I don't know if he tested with ldaps and a specified port. It's worth trying a providerURL like ldps://ip:636. It would be interesting to know what happens.
 
Note that the UsersLdapFileImpl class (specified in the usersClassName attribute of the server element in the CTP config.xml file) only uses LDAP to confirm the password; it uses an internal; XML file to obtain the user's roles. That means you must have all the users who are to be given access to the system in both the LDAP server and the XML file. The XML file is managed by the CTP User Manager. When creating the users in the User Manager, the password field can be left blank since it isn't used.
 
JP
 
From: RBlackmon
Sent: Friday, January 12, 2018 1:21 PM
Subject: [MIRC CTP/TFS User Group] Authentication using LDAP
 
--
Reply all
Reply to author
Forward
0 new messages