Difference between revisions of "CTP Authentication Using LDAP"
Line 1: | Line 1: | ||
This article describes how to configure CTP to use an LDAP server to authenticate users. The intended audience for this article is CTP administrators. | 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 <b><tt>CTP</tt></b> 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 both to 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 <b><tt>Server</tt></b> element in the CTP configuration file (<b><tt>config.xml</tt></b>). This element is described in the [[CTP-The_RSNA_Clinical_Trial_Processor#Server|top-level CTP article]]. To configure CTP to use LDAP authentication, several additional attributes are added to the element. | The authentication mechanism used by CTP is specified in the <b><tt>Server</tt></b> element in the CTP configuration file (<b><tt>config.xml</tt></b>). This element is described in the [[CTP-The_RSNA_Clinical_Trial_Processor#Server|top-level CTP article]]. To configure CTP to use LDAP authentication, several additional attributes are added to the element. | ||
Line 25: | Line 27: | ||
*<b>securityAuthentication</b> specifies the way the credentials are passed to the server. The default is shown above. Unless there is a reason to use a different valule, it is best to omit this attribute. | *<b>securityAuthentication</b> specifies the way the credentials are passed to the server. The default is shown above. Unless there is a reason to use a different valule, it is best to omit this attribute. | ||
*<b>securityPrincipal</b> specifies a string that is processed before being passed to the server when the context is created. For more on this attribute, see below. | *<b>securityPrincipal</b> specifies a string that is processed before being passed to the server when the context is created. For more on this attribute, see below. | ||
+ | |||
+ | The <b>securityPrincipal</b> must correspond to the organization of the information in the LDAP server. The example shown above is for one particular university's implementation. The string is sent to the LDAP server after substituting the username of the user being authenticated for the <b><tt>${username}</tt></b> token. |
Revision as of 19:17, 10 October 2011
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 both to 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 Server element in the CTP configuration file (config.xml). This element is described in the top-level CTP article. To configure CTP to use LDAP authentication, several additional attributes are added to the element.
<Server port="80" ssl="no" requireAuthentication="no" proxyIPAddress="" proxyPort="" proxyUsername="" proxyPassword="" usersClassName="org.rsna.server.UsersLdapFileImpl" initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory" providerURL="org.rsna.server.UsersXmlFileImpl" securityAuthentication="simple" securityPrincipal="cn=${username}, ou=people, dc=med, dc=university, dc=edu" />
where:
- port, ssl, requireAuthentication, proxyIPAddress, proxyPort, proxyUsername, proxyPassword are described in the article referenced above.
- usersClassName specifies the Java class to be used for authentication of users. To use the LDAP authentication mechanism described in this article, the value shown above must appear in the attribute.
- 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 will 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 valule, it is best to omit this attribute.
- securityPrincipal specifies a string that is processed before being passed to the server when the context is created. For more on this attribute, see below.
The securityPrincipal must correspond to the organization of the information in the LDAP server. The example shown above is for one particular university's implementation. The string is sent to the LDAP server after substituting the username of the user being authenticated for the ${username} token.