Credentials Authentication

Once a logon scheme has obtained the credentials from the user, they need to be verified and the authority level of the user needs to be ascertained and reported back to the system for use where needed.

Credentials authentication requires a means of comparing the provided password with that stored for the user. That mechanism is called a realm. In iSMO, a realm is equated with the name assigned to the credentials authentication provider. Initially, we supply four kinds of realm.

  1. Properties Realm:

    This realm is configured with the path to a properties file that contains properties like "username=password" and "username.role=rolename". For example, the file might look like this:

    steve=password
    steve.role0=user
    judy=secret
    judy.role0=admin
    judy.role1=bigdocs

    Judy has two access tokens, while Steve has one. Unlike Steve, Judy can work with "bigdocs". The meaning of bigdocs is subject to tests in the process flow, and is not defined by iWay.

    Obviously, this provides minimal security and is intended for use in testing and debugging only.

  2. Console Realm:

    This realm wraps the iSM console security systems, authenticating users that have been defined on the Managed Servers page of the console (which is accessed using a cunningly hidden link on the words Managed Servers at the top of the console screen). If the user has been granted power user rights, the Principal returned will include the admin role.

  3. JDBC Realm:

    This realm authenticates users using a JNDI DataSource, which could be an iWay JDBC Provider. Parameters for this realm provider are listed and described in the following table:

    Parameter

    Description

    JNDI Factory Name

    Initial Context Factory class to access the datasource via JNDI. To use an iWay JDBC provider, enter com.ibi.jndi.XDInitialContextFactory.

    JNDI Name

    Name for the datasource in the JNDI directory. For iWay JDBC providers, use the following format:

    jdbc/[provider_name]

    Users Table

    Table with at least one row for each valid user in this realm. The table must include at least two columns, containing username and password. The names of these columns are specified by the Username and User Credential Column parms. The table may include other columns if the application requires them.

    User Roles Table

    Table with at least one row for each security role assigned to a user. The table must contain at least two columns, for username and role. The names of these columns are specified by the Username and Role Column parms. The table may include other columns if required by the application.

    Username Column

    Name of the column that contains the username in the Users and User Roles tables.

    User Credential Column

    Name of the column that contains the password in the Users table.

    Role Column

    Name of the column that contains the name of the user security role in the User Roles table.

    The simplest tables that could be used with this realm might look like this:

    CREATE TABLE users
    (
    username varchar(25),
    password varchar(25)
    )
    CREATE TABLE user_roles
    (
    username varchar(25),
    role varchar(25)
    )

    To look up the password for a user, the realm constructs an SQL statement like this:

    SELECT password FROM users WHERE username = ?

    And it finds roles with a statement like this:

    SELECT role FROM user_roles WHERE username = ?
  4. JAAS Realm:

    This realm wraps a JAAS login context that must be configured externally in the JAAS login config file. The JAAS realm does not support digest authentication. The realm parameters are listed and described in the following table:

    Parameter

    Description

    JAAS Config File

    Path to the standard JAAS config file. If the system variable java.security.auth.login.config is not set when the realm is initialized, the realm will set it to this value. Consult JAAS documentation for the structure of this file.

    Application Entry

    The entry in the JAAS config to which this realm will delegate authentication requests.

    User Principal

    A successful JAAS login results in a Subject that can contain one or more Principal objects. Specify the class name of the Principal object that should be understood as representing the authenticated user.

    Role Principal

    Specify the class name (or a comma delimited list of class names) for Principal objects created by the JAAS login that should be understood as representing security roles for the authenticated user. The value returned by the Principal's getName() method will be the name of the role assigned to the user in iSM.

    For testing, we have included a simple JAAS login module that wraps the iSM console user database. To try it, you first need to create the JAAS config file with an application entry pointing to the console module. It might look like this:

    test
    {
    com.ibi.providers.auth.jaas.ConsoleLoginModule REQUIRED;
    };

    Configure the JAAS realm as follows:

    Parameter

    Value

    JAAS Config File

    The file containing the application entry above.

    Application Entry

    For the above example, "test".

    User Principal

    The login module creates a principal for the user of type:

    com.ibi.providers.auth.jaas.ConsoleUserPrincipal

    Role Principal

    The login module creates a principal for the role of type:

    com.ibi.providers.auth.jaas.ConsoleRolePrincipal

    It should be possible to configure the JAAS Realm to work with most Login Modules. Some other examples can be found at: http://free.tagish.net/jaas/.

  5. LDAP Realm:

    This realm accesses an LDAP directory for resolution. It needs to be configured with the name of a pre-configured LDAP provider, along with details on the context and filter information needed to resolve queries for password and roles.


iWay Software