Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 4 Implementing ActiveSpaces Security : User Authentication

User Authentication
TIBCO ActiveSpaces security allows you to authenticate the users of security domain requestors.
If the security domain for a metaspace has been configured to perform user authentication, then user authentication occurs when a security domain requestor tries to connect to the metaspace.If authentication fails, the connection to the metaspace fail.s
The authentication setting in the security policy file used by the security domain controller for a metaspace controls how users are authenticated. You can specify two types of user authentication:
Username and password authentication can be performed using the operating system's authentication services or an LDAP server. Certificate-based authentication can only be done using an LDAP server.
The basic format of the authentication setting in the security policy file is:
authentication=<none(default)|userpwd|x509>;[source=<system|ldap>;<source property>;...;hint=<string>]
If you specify userpwd or x509 for the authentication setting. you must specify source settings to enable the security domain controller to connect to the system that performs the authentication:
source=system specifies that the security domain controller should use operating system services to authenticate users.
source=ldap indicates that the security domain controller should connect to and use an LDAP server for authentication.
See the following sections for more detailed information on how to configure the authentication settings for operating system or LDAP authentication:
For each type of authentication, TIBCO ActiveSpaces prompts the user of the security domain requestor to enter the appropriate information needed for authentication (for example, user name and password, location of PKCS#12 file, and the password of the private key in the file).
You can override the default behavior for retrieving authentication information by using a callback mechanism. If a callback function is available, then when a security domain requestor tries to connect to a metaspace, ActiveSpaces uses the callback function to retrieve the user's authentication information instead of using the default behavior provided by TIBCO ActiveSpaces. See Authentication Callback for more detailed information.
Operating System User Authentication
User name and password authentication can be done using the operating system to authenticate the user. When operating system authentication is used and a security domain requestor first tries to connect to a metaspace, TIBCO ActiveSpaces prompts the user to enter their:
1.
2.
3.
For example, suppose you normally log into Windows using “AcmeInc\brady” for your domain and user names and “abc123” for your password. You should enter:
1.
2.
3.
The logon information entered is passed to the security domain controller, which tries to perform user authentication with the operating system.
When operating system based user authentication is configured:
To configure the security policy file to perform user name and password authentication using the operating system, set the authentication setting as follows:
authentication=userpwd;source=system;service=login;hint=<message to display to user>
The service setting specifies the operating system application to use for authentication. Currently this setting is ignored for Windows and is only used for UNIX systems. Specifying service=login causes the UNIX “login” system access application to be used to authenticate security domain requestor users. You can use the service setting to redirect PAM authentication requests to other local authentication applications.
LDAP User Authentication
You can configure user authentication to use an LDAP server to perform user name and password authentication. When user name and password authentication is used with LDAP and a security domain requestor first tries to connect to a metaspace, TIBCO ActiveSpaces prompts the user to enter their:
1.
2.
The logon information entered is passed to the security domain controller, which tries to connect to the LDAP server configured in the security policy file and use the LDAP server to authenticate the user.
To configure the security policy file to perform user name and password authentication with an LDAP server using an unsecure connection to the LDAP server, the authentication setting uses the following format:
authentication=userpwd;source=ldap;name=<LDAP object name>;
host=<LDAP server name>;plainPort=<port number>;
baseDN=<DN of parent>;hint=<message displayed to user>
where the unsecure LDAP connection parameters are:
name   Name of the object to query LDAP for (for example, cn for common name, uid for unique ID).
host   The fully qualified domain name of the LDAP server (for example, ldapsrvr.com).
plainPort   The port on which the LDAP server listens for clear text TCP/IP connections (default: 389).
baseDN   The distinguished name of the parent of the LDAP subtree (for example: dc=users,dc=com).
hint   A message to be displayed to the user as a hint of what they should enter.
If connecting to the LDAP server requires a secure connection using SSL/TLS, the authentication setting uses the following format:
authentication=userpwd;source=ldap;name=<LDAP object name>;
host=<LDAP server name>;securePort=<port number>;trustStore=<LDAP keystore>;
baseDN=<DN of parent>;hint=<message displayed to user>
where the secure LDAP connection parameters are:
name   Name of the object to query LDAP for (for example, cn for common name, uid for unique ID).
host   The fully qualified domain name of the LDAP server (for example, ldapsrvr.com).
securePort  The port on which LDAP clients should connect to the LDAP server using SSL/TLS (default: 636)
truststore  A file that contains the secure LDAP server's certificate chain
baseDN   The distinguished name of the parent of the LDAP subtree (for example: dc=users,dc=com).
hint   A message to be displayed to the user as a hint of what they should enter.
The security domain controller uses the contents of the truststore to authenticate the LDAP server when establishing a connection to the LDAP server. The truststore format can be a p7b file containing only certificates and certificate chains. If the LDAP server certificate is self-signed, the truststore can be a .pem certificate file or a binary DER format file.
LDAP Certificate Authentication
Security domain controllers can be configured to perform certificate authentication using an LDAP server. When certificate authentication is used and a security domain requestor attempts to connect to a metaspace, the user will be prompted to enter the following:
1. Path to a PKCS#12 (.p12) file to use for authentication.
2. Password for the private key inside of the PKCS#12 file.
The authentication information is passed to the security domain controller, which tries to authenticate the user against the LDAP server configured in the security policy file. To configure the security policy file to perform LDAP certificate authentication with an LDAP server, the authentication setting uses the following format:
authentication=userpwd;source=ldap;name=<LDAP object name>;
host=<LDAP server name>;securePort=<port number>;trustStore=<LDAP keystore>;
baseDN=<DN of parent>;hint=<message displayed to user>
where the secure LDAP connection parameters are:
name   Name of the object to query LDAP for (for example, cn for common name, uid for unique ID).
host   The fully qualified domain name of the LDAP server (for example, ldapsrvr.com).
securePort  The port on which LDAP clients should connect to the LDAP server using SSL/TLS (default: 636)
truststore  A file that contains the secure LDAP server's certificate chain
baseDN   The distinguished name of the parent of the LDAP subtree (for example: dc=users,dc=com).
hint   A message to be displayed to the user as a hint of what they should enter.
When LDAP certificate authentication is used, a secure LDAP server must always be used. The security domain controller uses the contents of the truststore to authenticate the LDAP server when establishing a connection to the LDAP server. The truststore format can be a p7b file containing only certificates and certificate chains. If the LDAP server certificate is self-signed, the truststore can be a .pem certificate file or a binary DER format file.
Authentication Callback
Sometimes you might not want to use ActiveSpaces’ default behavior for retrieving user authentication information. For example, if you want your users to use a smart card or USB drive to hold their authentication information and automatically authenticate security domain users without their being aware that the authentication has taken place, you can override the default behavior.
To override the default behavior of TIBCO ActiveSpaces for retrieving user authentication information, the ActiveSpaces API provides a callback mechanism. If a security domain requestor tries to connect to a metaspace using an authentication callback, the callback is used to retrieve the user's authentication information.
See ASUserAuthenticator for information on each supported programming language to see how the security API is used to implement an authentication callback.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved