Security architecture
The i2 Analyze security architecture supports the behavior that the i2 Analyze security model requires. Any part of the i2 Analyze application can interact with the security architecture to determine what rights the current user has for the operation that they want to perform.
i2 Analyze authenticates users through a choice of technologies, and determines their access level for every record that it manages. The i2 Analyze security model bases its behavior on the interaction between the security dimension values that records have, and the security permissions that user groups convey.
- Records in i2 Analyze are categorized by receiving values from security dimensions. The values that a record has from different security dimensions affect whether users can view or edit that record.
- Security permissions apply to groups of users. On a per-group basis, they associate security access levels with particular dimension values. User group membership is often decided by the team membership or the security clearance of the users that they contain.
The components of an i2 Analyze deployment interact with the security architecture in the following ways:
- At login, WebSphere Liberty requires clients to authenticate before they can interact with i2 Analyze. On successful authentication, the client receives a Lightweight Third-Party Authentication (LTPA) token in a cookie.
- During normal operation, the client passes the cookie back to the i2 Analyze application, which enforces data access rights.
The following diagram shows how security works in a typical i2 Analyze deployment:
In a standard i2 Analyze deployment, authentication and authorization take place as follows:
- Authentication between a client and Liberty uses standard HTTP authentication methods such as basic authentication or form-based authentication.
- Liberty uses its user registry to verify the credentials that the user supplies through the client. The user registry is a service that provides access to user and group information. It can be held in an XML file, one or more LDAP registries, or in any similar store that Liberty can use.
- To authorize users of a client to access records, the i2 Analyze application communicates with the Liberty user registry to retrieve information about the current user's membership of groups. A principal provider then maps the retrieved information to group permissions that are defined in the security permissions section of the i2 Analyze security schema. This mapping is deployment-specific because the security schema is deployment-specific.
- Code in the i2 Analyze application compares the permissions of the current user with the security dimension values of records, to determine what access levels the user receives for each record.
The technologies in the diagram are not fixed. For example, it is possible to use any supported store for the user registry. The requirements are as follows:
- The i2 Analyze application must be able to derive information about a user from the credentials they present.
- A (potentially) deployment-specific module must map user information onto membership of the groups that are named in the security permissions section of the i2 Analyze security schema.