Principal authentication

Principal authentication
Prev	Chapter 5. Security	Next

TIBCO ActiveSpaces® Transactions authentication is based on principals, or users of the system. A principal is uniquely identified by a user name, and has a set of attributes. These attributes include:

User Name - Unique identifier for a principal.
Password - Credential for this principal.
Roles - One or more roles granting access to administrative commands.
Password Expiration - The duration in days that the password is valid.
Remote Access - Allow access only from trusted hosts, or from any host.
Password Required - Define whether a password is always required, or only from untrusted hosts.

These attributes are defined using administrative commands, or loading and activating a configuration file.


	It is strongly recommended that administrative commands are used to define principals to avoid storing a clear text password, which is required when using configuration files. The remainder of this section only uses the administrative commands to manage user definitions.

the section called “Add principal” shows how to add a user to a node.

Authentication verifies that a given principal is valid and that the presented credentials match the credentials defined for the principal. Once authentication succeeds, all work done in the context of the current administration command will be done in an authenticated session for that principal. Any access to secured resources during that session will require that the principal was granted a role which has access privileges for the resource. Principal definitions may be updated, for example to change the credential, or the set of granted roles. See the section called “Update principal” for details on how to update an existing user definition.

Authentication Sources

Authentication is performed using one or more authentication sources. An authentication source provides a mechanism to authenticate a principal. There is always at least one authentication source configured for a node. It is named Local. The Local authentication source uses the principal definitions on the local node to perform authentication.

It is also possible to configure multiple external LDAP authentication sources. An external LDAP authentication source contains both principal and role definitions for authorized users.


	The `Local` authentication source is always used to authenticate the user that installed the node. This ensures that the node can be administered even if all external authentication sources are unavailable.

When multiple authentication sources are configured, a priority is defined which controls the order the authentication sources are used to attempt to authorize a principal. During an authentication attempt, an authentication source returns one of the following:

Authentication succeeded - the authentication succeeded.
Authentication failed - the authentication failed because the provided credential was invalid, or the principal was unknown.
Authentication source not available - a failure prevented access to the authentication source.

A successful authentication returned by an authentication source allows a principal access to a node.

An authentication failure returned by an authentication source prevents a principal from accessing a node.

An authentication source not available error, causes the authentication request to be sent to the next highest priority configured authentication source, if one. If there are no more configured authentication sources, the authentication attempt fails and the principal is denied access to the node.

An example authentication source configuration is shown in Example 5.1, “Authentication source configuration example”.

Example 5.1. Authentication source configuration example

//
//   Authentication source configuration
//    
configuration "authentication sources" version "1.0" type "security" 
{ 
    configure security 
    { 
        configure Authentication
        {
            AuthenticationSources
            {
                //
                //    Prioritized list of authentication sources.
                //
                sourceList =
                {
                    {
                        name = "ldap-west";
                    },
                    {
                        name = "ldap-east";
                    },
                    {
                        // The internal authentication source
                        name = "Local";
                    }
                };
            };
        };
    }; 
};

This configuration will cause the authentication sources to be attempted in this order:

ldap-west
ldap-east
Local

Trusted Hosts

The default Local authentication source in a node supports the configuration of trusted hosts, which allows for expedited authentication of principals when the authentication request originates from a network connection from a configured trusted host. Authentication from a trusted host passes without consideration for credentials. That is, if the authentication request originates from a trusted host, TIBCO ActiveSpaces® Transactions trusts the host-based authentication mechanism (e.g. UNIX login) to have verified the identity of the principal.


	Trusted hosts are not supported for external authentication sources.

A user must have the Password Required attribute set to Untrusted Host Only to take advantage of the trusted host facility. See the section called “Add principal”.

An example of using trusted hosts is shown below:

//
//  Command executed on host1
//
administrator hostname=host2 adminport=1234 display node

When the display node command is executed on host1, the name of the user that executed the command is determined from the operating system. The user name is sent to the node on which the command is being executed (host2 in the example) and if the command came from a trusted host (host1 in the example), authentication succeeds.

Trusted hosts are defined using configuration, as illustrated in the following example:

//
//  Define trusted  hosts
//
configuration "trusted-hosts" version "1.0" type "security"
{
    configure security
    {   
        configure Hosts
        {       
            Host        
            {           
                name = "host1"; 
            };          
            Host        
            {           
                name = "host2"; 
            };          
            Host        
            {
                name = "host3.some.domain.org";
            };         
            Host       
            {           
                name = "host4.tibco.com";
            };          
        };      
    };  
};

The above example configuration defines these trusted hosts:

host1 - a simple host name.
host2 - another simple host name.
host3.some.domain.org - a fully qualified host name.
host4.tibco.com - another fully qualified host name.

Trusted hosts can also be specified at node installation. See the section called “Installation”.

Secure Shell (SSH)

The administrator command-line tool provides administrative access to TIBCO ActiveSpaces® Transactions nodes running on both local and remote hosts. Some commands sent to nodes running on remote hosts are executed via Secure Shell (SSH) connections. SSH is a tool which provides authentication and confidentiality for network connections to remote hosts.

SSH requires configuration of authentication keys for the user who executes the remote request. Authentication keys for SSH are generated using the ssh-keygen command-line tool. See the ssh-keygen manual page (run man ssh-keygen on a Unix host) for further information on how to generate authentication keys, and where the keys must be stored for SSH to make use of them.

Prev	Up	Next
Domain security model	Home	Access control