While using Siteminder for providing Single Sign On capabilities,few databases need to be configured for its proper functioning.Few of these are mandatory and others are optional depending upon the Siteminder features that we need utilize.Lets have a look on the various databases that we need to configure during our Siteminder installation.
A SiteMinder environment utilizes the following databases
Policy Store: It is a mandatory database.
- It stores policy objects. It resides in an LDAP Directory server or ODBC database.
- This is used to store all policy-related objects, including the resources being protected by SiteMinder, the methods being used to protect those resources, Users or groups that can or cannot access those resources and actions that must take place when users are granted or denied access to protected resources. Policy information can be stored in LDAP or ODBC data stores but not in both simultaneously.
- For UNIX platform, the policy store and the key store can either be on Oracle Database or LDAP server. However for Windows NT, additionally we can use the SQL Server Databases.
Key Store: It is a mandatory database.
- It stores the encryption keys used to implement single sign-on.
- It stores the encryption keys the keys used by Agents to encrypt SiteMinder cookies, the keys Policy Servers use to encrypt sensitive policy store information, such as administrator passwords and the keys Policy Servers use to encrypt SiteMinder session tickets that contain credentials and other information related to user sessions.
- Policy store can also be used as the key store. By default the key store is a part of the policy store database else it can also be stored in a separate database.
User Store: It is a mandatory database.
- An existing user directory or database in the enterprise network should be used as SiteMinder user store. We are not required to use a proprietary SiteMinder user store.
- The purpose of the user store is to store user data for the Policy Server, which includes the ‘Organizational information’, ‘User and group attributes’, ‘User credentials’, such as passwords and ‘User attributes’, such as first and last name.
- If you have an existing User Base for authentication, it may be easier to maintain the existing directories, instead of migrating data to a different type of directory. However, authorization information for all users may be in a different directory from authentication and SiteMinder can use 2 different directories for authentication and authorization because of the availability of its directory mapping feature.
- For UNIX the user store can either be on Oracle Database or LDAP.
- However for WindowsNT, additionally we can use the SQL Server Database or the WindowsNT domain.
- If Registration features of SiteMinder need to be used then we need to store user information in LDAP.
Audit Log Store: It is a optional database.
- The Policy Store can also act as a Audit Database.
- Siteminder Audit logs can be stored either in text files or ODBC databases.Storing audit logs to a database is more secure than logging the information to a text file.
- The audit logs record information about all successful & failed authentication and authorization events and all other administrative events.
- As per the default settings, the logs are written in a text file known as Policy Server logs. In case there is a requirement to configure a standalone database for logging, we can configure ODBC databases for the same.
- SiteMinder Reporting Services can be used if the audit logs are stored in ODBC database.
Session Store: It is a optional database.
- By default, SiteMinder implements session management through non–persistent sessions. But some SiteMinder features require persistent sessions.
- If persistent sessions are enabled, an Agent must write the session ticket to a stand–alone database.
- We deploy a SiteMinder session store (session store) for the following primary reasons:
- If a SiteMinder log off URI is implemented, a session store prevents a SiteMinder session from being used again after a user logs off.
- To provide support for features that require persistent user sessions.Agents use this information to identify users and provide session information to the Policy Server.
Token Store: It is a optional database.
- The token store is required if an authentication schemes which use third–party hardware-based security cards or tokens is used.
- All tokens use data files provided by their respective vendors. Some vendors store their tokens remotely on a server they provide. Other vendors allow their tokens to be stored locally in the Siteminder token store (token store). The purpose of this component is to store these tokens.
- Consider the following if a token store is a required component in your implementation:
- We can configure a token store to a stand–alone database.
- The policy store can also be configured to be used as a token store.