IBM Cognos 8 does not authenticate users itself but rather relies on third-party authentication providers such as LDAP or Microsoft Active Directory to do so. This concept means that IBM
Cognos 8 presents logon data (essentially credentials) entered by the user or obtained through single sign-on (SSO) mechanisms to the third-party authentication providers on behalf of the user. Then, when authenticated, IBM Cognos 8 must read the user's groups and roles from the authentication provider as well and make them available to the authorization functionality. This task is implemented by authentication providers.
After the users, groups, and roles are visible in the Cognos Connection, authorization policies can be created wherein a user can be assigned to a group or role depending on the business requirements.
The flow of an authentication request in Cognos 8
When a user requests authenticated access to IBM Cognos 8, the flow is as follows:
1. The user clicks a report or analysis to view it, and the request goes through the gateway and the dispatcher to the presentation service.
2. The gateway accepts the request and sends it to a dispatcher.
3. The dispatcher notes that no passport is attached to the request, and sends the request to Content Manager.
4. Content Manager sends the request to Access Manager.
5. Anonymous access is disabled in this IBM Cognos 8 system, so Access Manager sends the request back to Content Manager with a fault attached. The fault contains information about what is needed to log on. For example, if multiple namespaces exist, the user will be required to select a namespace. If only one namespace exists, the user might be required to provide a user ID and password.
6. Content Manager returns the request with the attached fault to the dispatcher.
7. The dispatcher sends the request to the presentation service.
8. The presentation service creates the appropriate logon page for the user, and returns the page through the dispatcher and the gateway to the user.
9. The user enters the required information, such as a user ID and password. The information is attached to the original request and sent through the gateway to the dispatcher.
10.The dispatcher sends the request to Content Manager.
11.Content Manager sends the request to Access Manager.
12.Access Manager talks to the authentication provider through the Authentication Service to verify the supplied credentials. If all the required information is correct, Access Manager issues a Passport ID, attaches it in the HTTP header to the original request, and sends the request back to Content Manager. If the required information is incorrect or incomplete, the request faults back to step 9.
13.Content Manager sends the request to a dispatcher.
14.The dispatcher processes the request and sends it to the presentation service.
15.The presentation service sends the Welcome page back through the dispatcher and the gateway to the user.
Authorization and the CAMID
When a user is authenticated, the passport that is issued is the object that holds the visas. For each namespace, a visa is issued by the authentication provider after successful authentication has been established. In this case, the passport will hold a one-to-many numbers of visas. The Passport ID is the reference to the passport object, which is maintained, in memory, by the Content Manager component. The Passport ID is inserted in the cam_passport cookie, which is used to confirm that the user has successfully been authenticated in his or her current session before. Here, a user’s identity is established,
confirming access to the Cognos Portal content.
IBM Cognos 8 indicates which groups and roles the user is a member of, directly or indirectly, through inheritance (nested group memberships). This is true for groups and roles from the namespace for which the particular Passport ID has been issued, plus groups and roles from the Cognos namespace.
Authorization in IBM Cognos 8 applies to basically all objects that make up an IBM Cognos 8 application. All content (reports, analysis, folders, packages, and so on) and a wide range of functions and capabilities of systems can have permissions attached to them (for example, access to Studios). Permission defines who, a user, group or role, has what privileges on an object/capability/function.
The five privilege levels within IBM Cognos are:
_ READ
_ WRITE
_ EXECUTE
_ TRAVERSE
_ SET POLICY
Internally, those privilege levels do not contain the names of users, groups, or roles, but instead contain an internal ID named CAMID3. The CAMID is constructed by the authentication provider for each object read in from an external authentication provider. This also applies to the internal authentication provider, so all the objects of the Cognos namespace have a CAMID assigned to them. By the user of this CAMID, IBM Cognos stores and verifies access to objects, when authorization is necessary. The CAMID of objects in the user’s identity is compared to the permissions assigned to an object, and if they match, the
privileges are granted or denied. Although the CAMID is built differently among authentication providers, they all use a common layout. The CAMID layout is a string, consisting of two fields that are concatenated:
CAMID:="CAMID(<NamespaceID>:<AuthProviderSpecificID>)"
The NamespaceID is the ID that is specified in Cognos configuration for the namespace. The AuthProviderSpecificID is an ID that is constructed internally by the authentication provider.
Two examples are as follows:
_ Example 1, User:
CAMID("LDAP:u:uid=admin,cn=admin,ou=support")
Where:
– LDAP is the NamespaceID
– uid=admin, is the user Relative Distinguished Name (RDN®)
– cn=admin, ou=support, is the Distinguished Name (DN)
_ Example 2, Group:
CAMID("LDAP:g:cn=admin,ou=support")
Where:
– LDAP is the NamespaceID
– cn=admin, ou=support, is the Distinguished Name (DN)
Leveraging Tivoli Identity Manager with Cognos 8
Cognos 8 supports various authentication providers, such as Microsoft Active Directory Server, LDAP, SAP, NT LAN Manager (NTLM), Cognos Series 7, and so on. These authentication providers store users, roles, and groups that can be used inside the Cognos environment while enabling the authentication mechanism. On the other side, the Tivoli Identity Manager supports most of such authentication providers as managed resources that it can manage. Tivoli Identity Manager provides capabilities of provisioning users and groups on most of the managed resources that Cognos uses as authentication providers. The
Microsoft Active Directory server, IBM Tivoli Directory Server, or Sun ONE Directory Server are examples of such authentication providers.
Leveraging Tivoli Identity Manager for managing users and groups on the authentication provider can deliver an ideal combination with the Cognos 8 security model. Further sections provide details about how Tivoli Identity Manager can be integrated with an authentication provider and leveraged with Cognos deployments.
Several key advantages for Cognos 8 when Tivoli Identity Manager is used with the Cognos authentication provider (or providers) are:
_ Tivoli Identity Manager provides a centralized, policy-driven and automated end to end provisioning solution. Administrators can use the Tivoli Identity Manager Web-interface to manage users and groups on multiple authentication providers and performing administrative tasks on it rather than directly operating on the authentication providers' individual user interfaces.
_ Tivoli Identity Manager allows provisioning policies that can be defined and customized as per the need. A provisioning policy can help to ensure an appropriate user getting provisioned with appropriate access rights.
_ Approval workflows and e-mail notifications can be configured with all user provisioning activities, such as creating a user account on the authentication provider, user requesting an access to certain groups, and so on.
_ Tivoli Identity Manager provides a self-care user interface that allows users to perform basic operations on their own without an administrator's involvement, such as resetting password, requesting access to groups, viewing and updating of personal information, and so on.
_ Tivoli Identity Manager provides the ability to certify and validate a user's access to IT resources on a regular interval. An administrator can define a recertification policy that recertifies user accounts as well as access rights defined on the authentication provider.
_ Auditing and reporting users and their access rights is one of the critical needs of most organizations. Tivoli Identity Manager's User and Access Reports can be leveraged to extend the existing Cognos auditing capabilities by providing auditing and reporting (traceability) of identity information of the authentication provider that accesses Cognos contents.
_ Provisioning users on the authentication provider, based on the organizational roles that are defined in Tivoli Identity Manager (advanced scenario), can provide a role-based access control mechanism and the following benefits:
– Role hierarchy helps to simplify and reduce the cost of user administration by enabling the use of an organizational role structure.
– Separation of duties can strengthen security and compliance by creating, modifying, or deleting policies that exclude users from membership to multiple roles that may present a business conflict.
