![]() |
|
Pramati Server security is based on Java Authentication and Authorization Service (JAAS) specification.
JAAS is the Java API for providing standard security features for applications and enables services to verify and enforce access controls on users. It extends an access control architecture to the J2EE platform by implementing Java version of the standard Pluggable Authentication Module (PAM) framework.
Server Security can be configured for:
In a standalone node, the realm is implemented as an XML-based realm. In a cluster node, the realm is implemented as a DB-based realm.
For further details on realms, read Defining Security Realms.
One of the above ways can be selected while adding a realm based on XML and DB.
XML-based realm is typically used when there are limited users in the realm. This can occur when the applications deployed on the server do not use any security features or when the application is expected to have limited users.
Table 1: Initial options for the XML-based realm
| Option | Value | Description |
|---|---|---|
| Path to XML | To be specified. Mandatory. | The path to the XML file that contains the user/group definitions. Path can be provided in the following ways: 1. Provide a relative path using the $NODE_DIR variable. Here, the $NODE_DIR variable refers to the <install_dir>\server\nodes\<node_name> directory. Say, if you want to provide a relative path for a file located at <install_dir>\server\nodes\<node_name>\config\app directory, you can specify the path as $NODE_DIR\config\app\<file_name>.2. Provide a relative path to the Server config directory. 3. Absolute Path with relative to the Server Installation Directory |
If the provided path does not have the valid XML file, it will be created. If the file exists, the user/group information is picked up from the file.
This implementation uses a database with the following tables for storing user names, passwords and groups:
The default implementation assumes that all the columns are of the SQL VARCHAR type.
The most common and popular repository is LDAP Server. LDAP Servers provide a common repository and can be used for authentication and authorization services.
Pramati Server can use any LDAP v2 or v3 compliant Server for authentication and authorization. The following LDAP directory servers have been tested on Pramati Server:
To enable Pramati Server to use LDAP Server for authentication and authorization, an LDAP based realm must be configured.
To authenticate a user, Pramati Server uses the user name and password, and tries to connect to the LDAP Server. If the connection succeeds, the user is assumed to be authenticated.
User-Group Mapping is maintained by LDAP Servers in three ways.
Group has ‘user’ as attribute
This is the most common way to store the user-group mapping in the LDAP Server where group node in the LDAP server has users as attributes.
User has ‘group’ as attribute
In this case, user has group as attribute specifying the groups the user belongs to.
User DN contains the group mapping
In this case, the DN for the user has the group information. For example if the DN for a user is 'uid=Tom, ou=admin, ou=Employees, dc=xyz,dc=com', and if ‘ou’ is taken as the group key, this DN implies that user ‘Tom’ belongs to two groups, ‘admin’ and ‘Employee’.
Pramati Server supports all the three types of user-group mapping.
For authentication in this realm, the user presents the certificate to the server. For the server to trust and authenticate this certificate, the server certificate of the signing authority or the certificate itself should be in the trusted CA Certificate store. This store is located at <install_dir>\server\nodes\<node_name>\trustedcacert.
The Certificate-based realm uses the KeyLoginModule.
The following table lists the classes that implement the Certificate-based realm:
Table 2: Classes that implement the Certificate-based realm
| Function | Class Name | Implements the interface |
|---|---|---|
| LoginModule | com.pramati.security.loginmodules.certificate.KeyloginModule | javax.security.auth.spi.LoginModule |
| UserManager | com.pramati.security.loginmodules.certificate.KeyUserManager | com.pramati.services.security.spi.Usermanager |
com.pramati.security.loginmodules.certificate.KeyLoginModule implements the Certificate-based user authentication.
com.pramati.security.spi.UserManager interface. User and group management functions are performed through this class. It checks if a user has the relevant UserManagerPermission before an action is initiated.
The initial option for the KeyLoginModule and the KeyUserManager are the same. The only difference is that the realm option is not available to the KeyUserManager class.
You can add the following for this realm:
Table 3: Step 2 of adding a DB-based realm
| Fields | Options | Description |
|---|---|---|
| Driver | - | Name of the Driver for connecting to the database. This is a mandatory field. |
| URL | - | URL to the database location. This is a mandatory field. |
| Username | - | The user name used to login to the database. |
| Password | - | The password used to login to the database. |
| DB Operations | - | - |
| - | Create Tables | Selecting this option creates user and group tables according to the information provided. |
| - | Create Root User | Selecting this option creates a user root with password pramati and adds an administrator group. User root is associated with this group. |
| User Information | - | - |
| - | Table Name | The table name where the details of the user name are stored. This is a mandatory field. |
| - | User Column | The user name column in the table where the user name is stored. This is a mandatory field. |
| - | Password Column | The column name in the table where the password is stored. This is a mandatory field. |
| Group Information | - | - |
| - | Table Name | The table name where the details of the group name are stored. This is a mandatory field. |
| - | Group Column | The column name in the table where the group name is stored. This is a mandatory field. |
| User-Group Mapping | - | - |
| - | Table Name | The table name where the details of the user and group name mapping are stored. This is a mandatory field. |
| - | User Column | The column name in the table where the user name is stored. This is a mandatory field. |
| - | Group Column | The column name in the table where the group name is stored. This is a mandatory field. |
| DB Cache | - | - |
| - | Caching | This will enable caching by instantiating the Cached PM. |
| - | Max Entries | Size of the cache, if the caching option is set to true. The default value is 40. |
| - | Expiry | This is the duration for which the user details will be cached in the memory. The default value is 60 seconds. |
| Password | - | Select the algorithm type as either Hash or Encrypted. |
| - | Hash | Hash of the password is stored. Recommended. The password can only be compared and cannot be retrieved. Hence should not be used for applications involving Digest Authentication. |
| - | - | Name: Select the name from the drop-down list as MD5 or SHA1. |
| - | Encrypted | Encrypted form of the password is stored. |
| - | - | Name: Select the name from the drop-down list as BlowFish or DES. |
| - | - | Salt Start Index: Specify the salt start index here. |
| - | - | Salt Length: Specify the salt length here. |
| - | - | Padding: This is set to true by default. |
| Password Details | - | Specify the following details regarding password: |
| - | Expiry | Whether the password will expire or is it set as permanent and the expiry is disabled. If this is enabled, the user must change the password after the time specified in the ‘Expiry Time’ field. |
| - | Expiry Time | The number of days till which the password is valid. The default value is 180 days. This is applicable only if the ‘Expiry’ field is set as ‘Enabled’. |
| - | Password Expiry Column | The column name in the table where details related to password expiry are stored. |
| Weak Password Detection | - | - |
| - | Dictionary File | The dictionary filename used by cracklib to detect weak password. Read ‘Using Cracklib to detect weak passwords’ for more details. |
| - | Validation Class | Other password verifier class can also be provided apart from the internal crack lib. |
To encrypt passwords for a DB-based realm, provide the algorithm type for the password field. The various algorithm types are described in the previous section. After providing the necessary details for the DB-based realm, click Save.
You can add Groups to the realm by clicking the settings link. Provide here the names of the Groups you would like to add to the realm. The new DB-based realm is created. If the DB tables do not exist, they are created.
com.pramati.security.base.CheckPasswordSecurity interface. This provides a single method isPasswordSecure(...) that checks if anyone can crack the password. Once an implementation class for this interface is created, the server administrator can provide its name in the UserManager option - checkPasswordClass. The class must be added to the Server’s classpath.
Following is a sample implementation which throws an exception if the password length is < 6 characters:
import com.pramati.services.security.BadPasswordException;
import com.pramati.security.base.CheckPasswordSecurity;
import java.util.Properties;
public class SampleCheckPasswordSecurity implements CheckPasswordSecurity
{public void isPasswordSecure(Properties options, String password)
throws BadPasswordException
{if (password.length()<6)
throw new BadPasswordException("Password is too short");
}
}
To enable this facility:
<install_dir>\cracklib.<install_dir>\cracklib.java org.solinger.cracklib.Packer make <install_dir>\config\cracklib.dict words. This creates a compressed dictionary file needed by cracklib under the <install_dir>\config directory.<install_dir>\cracklib\classes to your server's CLASSPATH. If the server is already running, restart the server after changing the CLASSPATH.checkPasswordClass as com.pramati.security.loginmodules.db.CracklibCheckPasswordSecurity and dictionaryWordsFileName in the LoginModules option while adding the realm.Note: Setup your realm to use Cracklib when you are creating it. If you want to set it up later, you need to make modifications to the security-config.xml located at <install_dir>\server\nodes\<node_name>\config.
Table 4: Step 2 of adding an LDAP-based realm
| Fields | Options | Description |
|---|---|---|
| Context Factory | - | This is the ContextFactory to be used for LDAP Connection. If not specified the default value taken for this is com.sun.jndi.ldap.LdapCtxFactory. This is a mandatory field. |
| Server IP, Port | - | IP and Port for the LDAP Server. |
| UseSSL | - | SSL option is enabled for the realm |
| Authentication Type | - | Authentication type to be used for connection to LDAP Server. This is same as Context.SECURITY_AUTHENTICATION. Select the type as "none", "simple" or "strong" using the drop down list. The default value is set at "simple". |
| Super User DN | - | The super user's DN or super user's name to be used to connect to the server. |
| Super User Password | - | Password of the super user. |
| User Search Criteria | - | - |
| - | Base DN | Base DN where the search will start from. This is a mandatory field. |
| - | Search Filter | Search Filter to be used for searching a user. An example for this filter is (CN=%U). Here '%U' will be replaced by the user name being searched at the runtime. User can define any complex filter like (&(cn=%U)(objectClass=account)). This is a mandatory field. |
| - | Search Scope | Scope for searching the user. Possible values for this is "SubTree" and "OneLevel". As the name suggests, if the user is to be searched immediately under the BaseDN, the search scope can be given as "OneLevel". If it should be searched in the subtree as well, the value should be "SubTree". |
| Group Configuration | - | - |
| XML-based | - | If this is selected, the XML file provided will be used for fetching user-group mapping and thereby for authorization. This is not selected by default. |
| - | File | Path of the file that contains the Group information and User-group mapping. |
| LDAP-based | - | Group Search |
| - | - | Base DN: Base DN where the search for the group will start from. This is a mandatory field. |
| - | - | Search Filter: Search filter to be used for searching a group. An example for this filter is (OU=%G). Here '%G' will be replaced by the group name being searched at the runtime. This is a mandatory field. |
| - | - | Search Scope: Search Scope for searching the group. Specifies whether to search only under GroupBaseDN or go into the subtree. Possible values for this is "SubTree" and "OneLevel". |
| - | User-Group Mapping | - |
| - | - | Group has User/Subgroup has its attributes: Provide the values for User and Subgroup attribute keys. The attribute keys refer to the keys with which Users and Subgroups are associated with the Group. |
| - | - | User/Subgroup has Group as its attribute: Provide the value for the Group attribute key with which the parent group is associated with this user/subgroup. |
| - | - | User DN has Group: Provide the Key name for the group in the user DN. |
In case the LDAP Server does not have the User group Mapping and LDAP is used only for authentication and not for authorization, the mapping can be defined in an XML file.
In case the user-group Mapping is not there in LDAP Server and XML is used for this purpose, the user and group can be added to the XML from the Console. However, the user must be present in the LDAP Server for authentication to succeed.
If the realm is an LDAP realm, and the User-Group mapping is in LDAP, the Group cannot be added to that realm.
In case of a DB-based realm, if an existing table is being used for a User, Group, and User-Group, and its structure is different from the default structure used by the Server, it may not be possible to add a group or a User to the DB-based realm.
On the next screen, add Permissions for the new Group, and click Save. This adds the group to the realm. The details are provided on the main page.
Note: When you delete a sub-group from a parent group, you only remove the parent-child association. The sub-group and the other associations of the group (if any) are retained in the realm.
Table 5: Adding a User
| Fields | Description |
|---|---|
| Name | Name of the new User |
| Password | To authenticate the new user name |
| Retype Password | Confirm your password here |
| Groups | Select the available Groups to which the new User is to be added using the ‘>>’ option |
If no Group has been selected while adding the User, the user is added to the ‘Everybody’ group, and can be later on assigned to any group.
To make changes to the password and the group fields, click Edit against the selected user.
To delete a user from a specific group:
To remove a user from the server:
Changing Password for Users in Groups
Under Groups, click All Users. This takes you to the Security > Realm > Users screen. Click Settings for the user for which the password is to be changed. This takes you to a screen for editing the following details:
Table 6: Changing Password for the selected Group
| Fields | Description |
|---|---|
| Old Password | The existing password for the user |
| New Password | The new password for the user |
| Retype New Password | Retype the new password for the user |
| Group List | The groups to which the user belongs |
The name of the user is displayed by default. Click Save to go back to the Security > Realm page.
Select Enable Access Control. Now click Allow IPs and provide the list of IPs that can access the specified application. The request will be honoured only when the request comes from the specific IP for the requested application.
When an authentication needs to be done using the Web client, the Web client passes all the necessary values to the security framework for the same. If the authentication is username/password based, then basic authentication or form authentication is used. But if the authentication is Certificate-based using HTTPS, the SSL layer takes care of authenticating the client.
ClientLoginModule for Java clients to login to the server.
In case the authentication needs to be done on username/password based realm, the com.pramati.security.client.ClientLoginModule, should be used.
In case the authentication needs to be done on a Certificate-based realm, the com.pramati.security.client.ClientCertificateLoginModule should be used. Once the client gets authorized, the subject is populated along with the principals and sent back to the client.
This ClientLoginModule abstracts the complexity of authentication process from the client and returns a handle to LoginContext which could then be used to log on.
To perform server authentication:
login() method. Read Sample CertificateClientLoginModule for Server authentication.Example of a configuration file:
Login {com.pramati.security.client.ClientLoginModule required com.pramati.realm="realm://127.0.0.1:9191/system"; };
The module option com.pramati.realm specifies the server location, port number (//127.0.0.1/9191) and realm (system) to which the user wishes to log in.
java -Djava.security.auth.login.config=<pathtologin.cfg> <client’s class name>
In both Web and Java client authentication, the login information is stored in a log file by the security auditor.
| © Pramati Technologies 2007 | Runs on Pramati Server | Feedback | Legal |