Common Security Infrastructure (CSI) is a security framework that enables Unwired Accelerator to work with an existing security system. A realm is Tomcat's abstraction to allow integration between the Web Container security model (authentication and role-based access control) to a back-end security store. The CSI realm is an implementation of the Tomcat realm that bridges Tomcat to the CSI security integration layer.
The CSI realm component plugs in to a Tomcat 5.5.x Web application container, and is an abstract interface to security information such as user names, passwords, and role membership.
Unwired Accelerator automatically takes advantage of the capabilities the configured security providers afford. If a provider supports self-registration, then Unwired Accelerator allows self-registration. If a provider allows password change, Unwired Accelerator allows password change. If a provider returns password expiration warnings, Unwired Accelerator displays them.
CSI also supports client certificate mutual authentication and radius 2-factor authentication by configuring other available authentication providers into csi.xml. See “Auditing”.
When a user logs in to Unwired Accelerator, the user’s name and password are verified against the data server. If the password is about to expire, the user is prompted to change the password. If the user’s name and password are valid, role information is retrieved to provide Tomcat with a list of the user’s roles. The authenticated CSI sessions are persistent while the user maintains a session with the Web container. If csi.xml has been configured properly, users can change their LDAP passwords using Portal Interface and Mobile Web Studio.
The CSI configuration file (SYBASE\tomcat\conf\csi.xml) as shipped uses the PortalDB security providers. These providers access a simple security store based on tables contained within the portal database (PortalDB) that Unwired Accelerator uses for all its persistent data. This configuration is suitable for demos and development, but most likely not suitable for a production environments.
The LDAP security provider is typically more appropriate for production systems. This LDAP provider works with a wide range of security stores including ActiveDirectory, iPlanet LDAP, Netscape LDAP, OpenLDAP, Novell eDirector, among others. When you want to provide a population of existing users access to Unwired Accelerator, this is usually the provider you want. You can enable the LDAP provider by un-commenting it in the csi.xml configuration file.
If you want to use LDAP for authentication data (user/password or certificate), but do not want to use LDAP for access control (mapping LDAP groups to J2EE roles), you can use both the PortalDB and LDAP providers at the same time. When an LDAP user authenticates to Unwired Accelerator for the first time, a “shadow-copy” of the user is created in the PortalDB. No sensitive data from LDAP is stored with this shadow user. An administrator can then use the Mobile Web Studio GUI to grant roles to this shadow user. The next time this user logs in, they will still be authenticated against the LDAP security store, but their roles will be the union of roles derived from LDAP and roles granted them in the PortalDB.If you have an existing security system that is not LDAP compliant, it is possible to write your own custom CSI security provider to access that data. Talk to your Sybase Professional Services contact for help in this area.
Most messages are logged through the Jakarta-common logging framework and available through log files. Some messages, such as password expiration and similar warnings, are passed through to CSI. In a troubleshooting scenario, you can change the logging level to obtain additional messages, as described in “CSI logging level”.
