Cognos 10 Security.pdf

© Copyright IBM Corporation 2011 TrademarksIBM Cognos Proven Practices: Securing the IBM Cognos 10 BIEnvironment

Page 1 of 21

IBM Cognos Proven Practices: Securing the IBMCognos 10 BI EnvironmentNature of Document: Proven Practice; Product(s): IBM Cognos 10 BI;Area of Interest: Security; Version: 1.1

Business Analytics Proven Practices TeamBusiness Analytics Proven Practices TeamIBM

16 December 2011

A set of proven practices and guidelines to be taken into consideration when securing the IBMCognos 10 BI environment.

View more content in this series

IntroductionPurposeThis document provides a set of proven practices and guidelines, to be taken into considerationwhen securing the IBM Cognos 10 BI environment.

The intended audience for this paper are IBM Cognos 10 BI application administrators, who willbe responsible for designing the IBM Cognos 10 architecture and/or developing the project. Thecontents are not end user relevant as most of the recommendations need to be implemented byIBM Cognos administrators prior to end user roll out.

ApplicabilityThe recommendations and practices described in this document are not specific to any platformor deployment architecture. Examples are provided based off a Windows install though and allstatements apply to the products listed on the cover page (including Fix Pack (FP) and RefreshPack (RP) releases) unless explicitly stated otherwise.

Exclusions and ExceptionsWhile designed to be as generic as possible to be applicable to the majority of installations, somestatements might not apply to specific environments. Special consideration must be taken toensure that the recommendations given here meet the requirements set out for your deploymentand adhere to any security policies applicable to your environment.

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html

developerWorks® ibm.com/developerWorks/

IBM Cognos Proven Practices: Securing the IBM Cognos 10 BIEnvironment

Page 2 of 21

Guidelines on Securing IBM Cognos 10 BI EnvironmentsIBM Cognos 10 products offer flexible and versatile security features which facilitate integrationin most, if not all, existing security environments. The challenge is to start off from a solid baseconfiguration which is sufficient for testing and/or development environments and then move on tothorough security implementations and integrations. IBM Cognos 10 offers all that out of the box.

The following chapters will describe some guidelines and recommendations broken out by the toolused to configure them. We'll cover authentication and authorization topics and provide some BestPractices to follow.

Before starting, the first step is to clearly define the requirements, below is a list of questions thatshould be answered regarding IBM Cognos 10 BI security prior to starting the implementation.

• What authentication source(s) are being used? The most common authentication sourcesare LDAP and Active Directory but there are others. Ensure that you have a contact availableto help you understand the authentication source contents and structures as well as thenecessary technical information such as server, port and required credentials. Specific piecesof information may be required to follow some Best Practice recommendations.

• Are you using a single security namespace or multiple security namespaces? Dependingon the requirement one may face the challenge of “automatically” authenticating a user tomultiple namespaces upon login. While this is not supported by IBM Cognos 10 BI, it can besolved with .NET or JavaScript scripting techniques.

• Will users be authenticated to IBM Cognos BI explicitly or shall there be some sort of SingleSign-On (SSO) based on authentication from some other security layer? If SSO from anothersource to IBM Cognos 10 is required, make sure you evaluate whether this is a nice-to-haveor a must-have feature. If it is required, then solve the SSO challenge technically first beforedefining authorization since SSO may have implications on the required namespaces or theirconfiguration. In particular SSO can impact scheduling, because many SSO credentials maynot be appropriate for being stored with schedules as they may expire. This leads to usersbeing prompted for user name and password which they might not know since they are usedto SSO.

• Should the same credentials used to authenticate to IBM Cognos BI 10 also be usedto authenticate to a query database (user pass-through)? This can be a complex andchallenging setup and not supported in all combinations of authentication source anddatabases. Evaluate if alternatives using stored database signons are feasible but note thatthis may have implications on authorization because the signons must be maintained andproperly secured in IBM Cognos 10 BI.

• What level of security is required? Is this system accessible externally or only internally? Itis a recommended Best Practice to implement the Secure Socket Layer (SSL) protocol onthe web server hosting the IBM Cognos 10 BI Gateway if the system is accessible externally.Most likely your company's security policies will demand this and potentially other additionalsecurity measures. This will have implications on the configuration of SSL in IBM Cognos 10BI.

• How sensitive is the data for internal/external users? Depending on the security requirementyou will want to look at encrypting temporary files and encrypting all traffic over the network

ibm.com/developerWorks/ developerWorks®


Page 3 of 21

even internally. Again, these considerations have implications on the configuration of the IBMCognos 10 BI install.

• Will IBM Cognos 10 BI be integrated with other IBM products such as Lotus Connections,IBM Cognos TM1 or IBM Cognos Planning? Integration may imply changes to the securityafter the fact if not planned carefully. Discuss integration scenarios with your IBM Cognosrepresentative ahead of performing any security implementation.

Those are just some examples but what this demonstrates is how many aspects of security maybecome relevant to IBM Cognos 10 BI. There are obviously many security aspects to considerbut the good news is that all of those can be handled in IBM Cognos 10 BI. The Best Practicerecommendations listed in this document refer to general applicability. For more specific topics,try researching for documents on IBM's developerWorks web site located at http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html.

IBM Cognos Configuration

This section will discuss the settings and configuration items related to security that are specifiedin IBM Cognos Configuration. These are usually implemented right after installation and providethe basis for the subsequent tasks that are covered later.

Secure Installation

Service Account

The first decision affecting security may have already been made. It is possible that IBM Cognos10 was installed onto your platform using a particular account and this account may have sufficientfile system privileges to run the application. However it is possible that policies or the environmentwill demand that specific accounts be used for running an application. We refer to that account asthe Service Account.

IBM Cognos 10 BI is for the most part a Java web application which is deployed to a Javaapplication server such as IBM WebSphere. Out of the box though, IBM Cognos 10 is deliveredpre-deployed to Apache Tomcat, which is not a full Java application server but a subset of one. Forthe sake of this explanation though, we simply refer to Apache Tomcat as an application server.

If IBM Cognos 10 is run using the out of the box Apache Tomcat, there is a service namedcognosbootstrapservice.exe which will start Apache Tomcat and can be configured in IBMCognos 10 BI Cognos Configuration. On Windows platforms this service is registered as aWindows Service, run by the Local System account by default. On UNIX/LINUX platforms theservice is run by the account calling the cogconfig.sh start script. Thus the Service Account is theaccount running the application server.

If IBM Cognos 10 BI is deployed to a different application server, usually that server will determinethe account used to run IBM Cognos 10 BI and is therefore the Service Account.

It's important to choose a proper Service Account because:





Page 4 of 21

• This account will instantiate the Java Runtime Environment (JRE) hosting IBM Cognos 10 andall other processes spawned by IBM Cognos 10 such as BiBusTKServerMain, CAM_LPSvr,BmtMDProviderMain and others. All IBM Cognos 10 processes, being either Java or nativeprocesses, require file system privileges of different levels to the IBM Cognos 10 installationdirectory and it's sub-directories.

• This account is used for printer access.• If running on Windows platforms, this account will be used for Microsoft Kerberos interaction

required for SSO to IBM Cognos 10 and possibly for authentication to Microsoft databaseslike SQL Server or Analysis Services.

• This account will be used to create temporary files and transient files.• This account will be used to interact with the platform logging facilities when IBM Cognos 10

is being configured for directing Auditing output to the operating system logging facilities.

A Best Practice is to use a named account specifically assigned to IBM Cognos 10 to perform theinstallation (provides file system ownership) and the running of IBM Cognos 10. The installationaccount and the Service Account can be different but additional care must be applied regarding filesystem permissions.

On Windows platforms where using a named domain account as the Service Account ratherthan Local System or Network Service, the account must be allowed to authenticate on themachine and should have sufficient file system privileges as well as being properly configured inUser Account Control. Depending on the use of sophisticated features like Kerberos SSO, userpassthrough to Microsoft data bases and logging to operating system loggers, additional Windowsprivileges might be required.

On Linux/UNIX platforms the Service Account should share a primary group with the installationaccount to simplify the question of file system access. The Service Account and it's primary groupshould be given full access to the installation directory including sub-directories, and all file systempermissions for “other” should be revoked. It is recommended that ownership of the installationdirectory and sub-directories should be granted to the installation owner and the shared primarygroup only.

Information about the Service Account can be found at the following link from the IBM Cognos 10Information Center.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.inst_cr_winux.10.1.0.doc/inst_cr_winux_id3223ConfigureAUserAccountForCognos8.html#ConfigureAUserAccountForCognos8

Temporary Files

Like most products, IBM Cognos 10 BI utilizes temporary files during the course of ordinaryreporting functions. By default, temporary files are written to a temporary folder on the disk. Thedefault location for this is <COG_ROOT>/temp, where <COG_ROOT> denotes the IBM Cognos10 BI installation directory. The directory is configurable in IBM Cognos Configuration though.The property is named Temporary files location and it resides under the Environment section.






Page 5 of 21

To restrict access to the temporary files found in this directory, it is suggested that file systempermissions be set to only allow the Service Account full control to the directory, all other accountsshould be denied access. If the temporary file location is moved to a directory outside of the IBMCognos 10 BI installation directory, it is possible that the file system permissions may need to beadjusted.

IBM Cognos 10 BI can also save user session files to the local file system to help reduce theload on Content Manager. If this feature is configured, the location specified for the user sessionfiles should be accessible by the Service Account only. Keep in mind that this feature only affectsinstalled instances of Application Tier components. For more information on saving user sessionfiles to the local file system refer to the following link from the IBM Cognos 10 Information Center.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id281asg_content_manager.html#asg_content_manager

Encrypting Temporary Files

If models or recently viewed reports contain sensitive data, then extra precaution should betaken when dealing with these temporary files that are generated. IBM Cognos 10 BI offers theability to encrypt these temporary files, so that they are unable to be viewed by unauthorizedconsumers. This does not apply to the user session files though. The property to enable temporaryfile encryption can be modified using IBM Cognos Configuration. The property is named Encrypttemporary files? and it resides under the under the Environment section. The value should beset to True to enable this feature. The encryption applied is based on a session-based key that isfed to the configured confidentiality cipher.

Dispatcher Passwords

Starting with IBM Cognos BI 8.4, there is a Dispatcher password property which must matchbetween all installed instances of Dispatchers, including installs of just the Application Tier andContent Manager components. The password acts similar to a shared secret in that it preventsDispatchers which don't know the secret from joining the IBM Cognos 10 BI system. As a BestPractice this password should be changed from the default on all Application Tier and ContentManager installs. The property to set the Dispatcher password can be modified using IBM CognosConfiguration. The property is named Dispatcher password and it resides under the under theEnvironment section.

Content Store Database

The Content Store database is the central repository for the IBM Cognos 10 BI system. It shouldbe obvious that maximum precaution should be taken to make sure that the database is availableand properly secured. The IBM Cognos 10 BI Content Manager component handles access tothe Content Store database through a single database signon. The signon is specified in IBMCognos Configuration and will be saved in an encrypted format to the main IBM Cognos 10 BIconfiguration file <COG_ROOT>\configuration\cogstartup.xml. However, if the database is






Page 6 of 21

accessible from outside of IBM Cognos 10 BI, this will compromise the IBM Cognos 10 BI systemstability and security. Though sensitive data will be saved in encrypted form inside the ContentStore, saved report outputs or other information which is not necessarily sensitive by default isnot encrypted, thus it is important to ensure that no other accounts have read/write access to theContent Store database at the database level. This must be implemented at the database level.For details consult your database administrator.

Authentication concepts

IBM Cognos 10 BI authentication works by deferring the authentication to an externalauthentication source through a piece of software called an authentication provider. Eachauthentication provider attaches to a specific type of authentication source such as LDAP,Microsoft Active Directory or SAP BW and implements logic to read security objects and handlethe authentication process with it. On top of that, many authentication providers provide support forSSO. Except for a special type of provider, each authentication provider exposes the objects readfrom the external authentication source in the form of a namespace to IBM Cognos 10 BI. For asingle IBM Cognos 10 BI system multiple namespaces can be configured at the same time andthus users from multiple authentication sources can access IBM Cognos 10 BI.

There is a special namespace in IBM Cognos 10 BI called the Cognos namespace. It's notattached to any authentication source and cannot contain users but only groups and roles. TheCognos namespace is not available for authentication but rather it is used to provide a logicalmapping layer for security objects from namespaces attached to external authentication sourcesand application defined authorization objects. An administrator would create groups and roles inthe Cognos namespace and assign external security objects, such as users, groups and roles tothose objects created in the Cognos namespace. Authorization concepts will be discussed later inthe document.

Both the external namespaces and the Cognos namespace are configured in IBM CognosConfiguration. There are also some general settings which influence the authentication whichapply regardless of namespace type. We'll start off with some Best Practices for specifying thegeneral settings.

Inactivity timeout

The inactivity timeout setting specifies how many seconds it will take before an authenticatedsession from a client to IBM Cognos 10 BI is considered expired. A shorter expiry setting may leadto more frequent authentication prompts, a longer expiry setting increases the risk of someoneaccessing a browser on an unattended workstation if no screen lock protection is in place. If SSOis set up though, this will re-authenticate the user silently in the background without any negativeimpact. It is recommended to have SSO configured whenever possible. The inactivity timeout isset in IBM Cognos Configuration by setting the Inactivity timeout in seconds property locatedin the Security > Authentication section. As a Best Practice this should be set according to yoursecurity policy. A good starting point is 900 seconds or 15 minutes. That's a quarter of the defaultvalue of 3600 seconds but it represents a good trade-off between resource consumption for everyactive session and user convenience.



Page 7 of 21

Passport encryption

A successful authentication will lead to session objects being created in memory on the ContentManager component. These session objects will contain sensitive user data. If required, it ispossible to encrypt these in-memory objects to prevent access to the information by malware orother memory readers. To enable the encryption, use IBM Cognos Configuration to set the Enablethe encryption of passport credentials? property located in the Security > Authenticationsection to True. Keep in mind that this will have a slight impact on performance of authenticationand other operations requiring access to the user credentials. As a Best Practice, leave thisdisabled unless explicitly required by your security policy.

Session sharing

When multiple clients (Framework Manager, Transformer, Planning, etc.) on a single workstationaccess the same IBM Cognos 10 BI system, it is possible for them to share an authenticatedsession. While this helps reducing the number of concurrent active sessions that exist in IBMCognos 10, it's potentially less secure than having separately managed sessions for each client.On the other hand this is required to achieve SSO between multiple clients on a single workstation.The property to set in IBM Cognos Configuration is Allow session information to be sharedbetween client applications? under the Security > Authentication section. The default value forthis property is False and the Best Practice is to leave it as False unless there are multiple clientapplications on a single workstation for which SSO is desired.

Restricting access to IBM Cognos Connection

When a namespace has been configured for authentication it is implied that all users from theunderlying authentication source shall be able to authenticate to IBM Cognos BI and access IBMCognos Connection. This however might not always be the case, as there might be a requirementto limit the access to a subset of all the users contained in the configured authentication source. InIBM Cognos 10 BI this can be achieved by leveraging the configuration property Restrict accessto members of the built-in namespace under the section Security > Authentication in IBMCognos Configuration. If this property is set to True, access will be denied to any user who is nota member of the Cognos namespace either directly or indirectly. The Cognos namespace is thebuilt-in namespace used to map users, groups and roles from external authentication sourcesto a defined application specific security model. For more information regarding the Cognosnamespace, refer to section titled “Authorization Concepts and Best Practice”. By assigning a useror a group/role from an external namespace that the user is a member of to a group or role in theCognos namespace, the user becomes a member of the Cognos namespace implicitly.

Example: The users Robert Smith and Marla Spears are defined in an LDAP source which isconfigured as an LDAP namespace for IBM Cognos 10. Robert is assigned to the Consumersrole in the Cognos namespace while Marla is not assigned to any group or role in the Cognosnamespace. If the Restrict access to members of the built-in namespace? property is set to True,Robert will be able to authenticate to IBM Cognos 10 and have access to Cognos Connection butMarla won't because she's not a member of any group or role in the Cognos namespace.



Page 8 of 21

Auto-renew trusted credentials

As of IBM Cognos 10 there is a new feature which allows IBM Cognos 10 BI to “automatically”update stored credentials for schedules. This feature can be set in IBM Cognos Configurationthrough the Automatically renew trusted credential property under the Security >Authentication section. To understand the impact of this setting we need to look at some details.

When a user creates a trusted credential to be saved with a schedule or to provide them to adifferent user for them to use for running reports instead of the user saving the credentials, thereis an object created which contains credentials for all namespaces that the user is currentlyauthenticated to. As a result because a single user can authenticate to multiple namespacesin a single session, trusted credentials can potentially contain multiple sets of credentials, onefor each namespace. The first namespace the session is authenticated to is called the primarynamespace.

A trusted credential is special because the namespace credentials it stores must be usable at anytime, not depending on any timestamp. This rules out SSO tickets like Kerberos tokens or SAPtokens as they will expire after a short time and will become unusable. A suitable trusted credentialtherefore usually is a pair consisting of a user name and a password. However, for SSO basedauthentication to IBM Cognos 10 BI, there is no password available to the namespace that canbe stored into the trusted credential. Therefore, this feature will only work for basic authentication,when the user provides a user name and password to the login screen. In this case, the systemwill look at all trusted credentials for that user and update them with the credentials they justentered.

When the property is set to Primary namespace only (the default value) this means that trustedcredentials will be updated with a single credential only while the value of All namespaces impliesthat credentials for all namespaces currently authenticated to will be updated. The Best Practiceis to set this to a value of Primary namespace only if authentication to the namespace is not bySSO, otherwise it should be set to a value of Off.

Namespaces

There are some guidelines specific to the type of namespace:

LDAP unique identifier

Once a user has been authenticated to gain access to the IBM Cognos Connection portal, a useraccount reference known as a CAMID is stored in the Content Store database. This CAMID ispartly made up of the value returned from the attribute mapped to the Unique identifier propertyfor the definition of the namespace under the Security > Authentication section in IBM CognosConfiguration. By default, this property is mapped to dn (Distinguished Name). All LDAP serverswill have this dn attribute populated for each single entry so this ensures that regardless of thetype of LDAP server there's always an attribute on which to base the unique identifier. Thispractice however does not ensure that user accounts are truly unique. Consider the followingscenario,



Page 9 of 21

Company ABC purchased IBM Cognos 10 BI and has successfully rolled out the product totheir user base. An LDAP namespace was used to connect to the corporate directory server.The default IBM Cognos 10 BI LDAP namespace configuration is historically based on Sun OneDirectory Server so their value for the Unique identifier property was set to dn. The Vice Presidentof North American Sales, John Q. Smith, is a frequent user of IBM Cognos 10 BI and has beenstoring sensitive sales and forecasting reports in his “My Folders” portion of the IBM CognosConnection portal. Using the corporate naming convention of “last name, first initial”, his networkuser account is SMITHJ and was created in the North America user folder. This gives John Q.Smith a dn of:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

So far, business as usual. However, John Q. Smith decides to take a position with anothercompany, so his user account is removed from the corporate LDAP hierarchy. A few months lateran entry level manager, John X. Smith, is hired. Once again, using the naming conventions atCompany ABC, John X. Smith receives a network account of SMITHJ, because it is available. Thisgives John X. Smith a dn of:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

When John X. Smith logs into IBM Cognos Connection and goes to save a report to his “MyFolders” for the first time, he notices that his folder is filled with reports containing sensitive data.The reason that this happened, is because the unique identifier was based on an attribute thatMAY not be unique over time, as demonstrated in the previous example. The only way to ensurethat this type of scenario does not occur is to use an attribute for unique identifier which providesglobally unique values for every entry read from the LDAP server.

Most LDAP servers provide such an attribute, often as part of the operational attributes.Operational attributes are read only and maintained by the LDAP server only. Some LDAPbrowsers won't show them by default and require explicit action to read/display them. Consult yourLDAP server documentation to learn which attribute is used as a globally unique identifier of anentry. Some examples are ibm-entryuuid used by IBM Tivoli LDAP, objectGUID used by ActiveDirectory when accessed as an LDAP source or nsuniqueid which is used by Sun One Directoryserver.

The Best Practice for LDAP namespaces is to use this globally unique attribute for the Uniqueidentifier property.

Of course, a solid security infrastructure built within Company ABC would have not allowed for twoSMITHJ accounts to have been created (at least not with the same internal unique identifier) butmaking this simple configuration change will add an extra level of security for your deployment.

NOTE: The attribute mapping must be changed before applying authorization in the IBM CognosConnection portal and/or allowing users to access IBM Cognos 10 BI. If the attribute mapping is anafterthought and is changed later on, all object security will be nullified and the users will not seetheir personal content. This is because after a change to this setting, a new CAMID will be created



Page 10 of 21

for each user logging in based on the new attribute for unique identifier thus creating, in essence, anew user account in the Content Store. It is also important to note that the attribute used must bean attribute available for all objects such as groups, folders and users. If the selected attributeonly exists for users, some objects will not appear in IBM Cognos Connection when administeringthe namespace.

LDAP connections

The IBM Cognos 10 BI LDAP authentication provider can be configured in many ways regardingconnection handling and the credentials used to bind to the LDAP server. At this time many ofthese methods are still being investigated for how best to implement.

Essentially the provider uses two types of connections, one for look-up searches and one forsearches related to user session actions.

The look-up connections will be established using the provided binding credentials and get pooledand therefore reused. The default pool size is 20 and connections are not closed until the productis stopped. To configure the pool size and influence whether connections are dropped for aprovider of that type one can specify the minimumLDAPPoolSize and maximumLDAPPoolSizein Advanced properties for the definition of the namespace under the Security > Authenticationsection in IBM Cognos Configuration. If both properties are set to 0, connections won't get pooledand will be closed immediately after use.

For user session connections, the user credentials provided when logging in are used to bindto the provider unless the Use bind credentials for search property is set to true. This wouldtrigger the use of the values specified in the Bind user DN and password property instead.Those connections would remain connected until the user session ends. If one wants to minimizeconnection use, one can specify the property unbindLDAPHandleAfterUse in Advancedproperties and set it to a value of true. Using these advanced properties together one canachieve minimal open connections to the LDAP server.

The Best Practice for larger user bases (in excess of 50 concurrently logged in users) is to usethe unbindLDAPHandleAfterUse property and leave the pool unchanged as 20 connections won'tcause noticeable impact on the LDAP server. If your policies demand keeping open connections toa minimum, disable the look-up connection pool.

Microsoft Active Directory

When configuring a Microsoft Active Directory (AD) namespace, it's possible to leverage theMicrosoft DNS based locator service which allows finding an available domain controller in fail-over scenarios. This allows the ability to not specify a specific domain controller's name or IPaddress for the host in the Host and port property of an AD namespace but rather the domain'sDNS alias like domain.company.com. This will allow the DNS service to return an available domaincontroller in all situations as and a result, is considered to be a Best Practice that has beenadopted by many clients.



Page 11 of 21

Cryptography

IBM Cognos 10 BI leverages Public Key Infrastructure (PKI) concepts to implement encryptionand the basis for supporting the Secure Socket Layer (SSL) protocol for encrypted HTTPcommunication. The specifics are beyond the scope of this document but some settings should bechanged from the defaults to implement basic security requirements and adhere to Best Practices.

Identity

Each installed instance, referring to an installation of one or multiple installed components toa single directory on a supported platform, has an identity to IBM Cognos 10 BI. So even twoinstalled instances on two separate directories on the same box are considered different entities.This is relevant when cryptography, which is used to encrypt saved, temporary or transient datain IBM Cognos 10 BI, comes into play. The identity, whose concept originates from the X.509standard, is defined by a Distinguished Name comprised of the fields Server common name,Organization name and Country or region code in the Security > Cryptography > Cognos >Identity name section of IBM Cognos Configuration. These fields should be changed from theirdefault so as to guarantee that each install has a different identity. This is most important when theinternal communication for IBM Cognos 10 BI will be switched to SSL but in general it is a BestPractice to define those properties.

Best Practice is to specify a unique Server common name property. The value should be theserver's fully qualified Domain Name System (DNS) name. In the case of multiple installedinstances on a single host which share a DNS name, adjust the Organization name property ineach configuration to distinguish the instances.

CA Service password

One of the central elements of a PKI is the Certifying Authority (CA) which represents the rootof trust and issues and signs certificates thus approving the identity of other entities. IBM Cognos10 BI contains it's own CA service located within the Content Manager component and, by default,will be used to sign the certificates used by IBM Cognos 10 BI. This is meant for installationswhere the client does not run corporate CA services or the security requirements allow using anapplication specific CA to be feasible.

When saving configuration on any installed instance for the first time, the CA service will be askedto sign some certificates for that particular installed instance, approving the instance's identity.It is therefore crucial for the integrity and security of the IBM Cognos 10 BI deployment that onlytrusted instances have access to the CA service. This is why the built-in CA service is protected bya password. This password is specified in IBM Cognos Configuration in the Password property ofthe Certificate Authority settings section under Security > Cryptography > Cognos.

The Best Practice is to change this password from the default. To do that, specify a new passwordin the configuration of the Content Manager install component before saving the configurationfor the first time. Subsequently adjust the password for all other instances before initial save ofconfiguration on each install.



Page 12 of 21

Keystore Passwords

Certificates are stored in special files called key stores. The files are in a binary format and theyare encrypted based on a password required to access them. IBM Cognos 10 BI uses threedifferent key-pairs and correlating certificates on each instance, one for encryption, one for signingand one for the Certifying Authority. Each key-pair and the certificate issued for it are held in aseparate key store, which is protected by a password.

Each certificate has it's own settings in a separate section in IBM Cognos Configuration underSecurity > Cryptography > Cognos. The key store passwords are specified in the <keypurpose> password property where <key purpose> is one of Signing key store, Encryption keystore or Certificate Authority key store.

It is considered a Best Practice to change the key store passwords from their defaults before firstsaving configuration for the instance.

Cognos Application Firewall

The Cognos Application Firewall (CAF) is a tool designed to supplement the existing IBM Cognos10 BI security infrastructure. This application firewall acts as a smart proxy for the IBM Cognos 10BI Dispatcher and ensures that incoming HTTP and XML requests sent to it are safe to be handledand that outgoing responses to external clients or services are properly encoded and safe.

Safe in this context refers to parameter data, HTTP POST data and malicious requests being sentto the product aiming to compromise the system's security. The most common forms of maliciousdata are buffer overflows, cross-site scripting attacks (XSS links), either through script injection invalid pages, redirection to other web sites or SQL injections, and session identifier or cookie basedattacks. The Cognos Application Firewall will reliably secure IBM Cognos 10 BI against those andensure only validated parameters and data in general is processed.

The Cognos Application Firewall is controlled by settings made in IBM Cognos Configuration underSecurity > IBM Cognos Application Firewall. The Enable CAF validation? property must beset to True for CAF to be enabled.

Due to it's critical contribution to overall system security and stability, the Best Practice is to neverdisable CAF in a production environment.

Valid Domains or Hosts

The most important property of CAF configuration is the list of valid domains or hosts to allow re-direction to or to allow pulling data from. This refers to functionality such as displaying a feed on adashboard from an external URL, including pictures from external servers, integrating IBM CognosTM1 Contributor or redirecting to a Lotus Connection host to create an Activity.

Each of the scenarios mentioned above requires an entry to be added to the list of valid domainsor hosts for the CAF. The CAF will compare the URL used to access an external (to IBM Cognos10 BI) resource with the list of valid domains or hosts and only if a match is found, the request will



Page 13 of 21

be sent to the external resource. This list of explicitly allowed host names or domain suffixes towhich access is allowed is often referred to as a white-list. Any URL that is not on the white-listwould be blocked by CAF. One can specify a host name in NetBIOS notation (e.g. “MyServer”)or specify domain suffixes using wild cards (e.g. *.domain.com) to allow all hosts from a specificdomain.

The comma separated list is specified in IBM Cognos Configuration under the Security > IBMCognos Application Firewall > Valid domains or hosts property.

The Best Practice is to explicitly name the hosts if possible and use more general domain suffixspecifiers in trusted networks only.

IBM Cognos ConnectionIn IBM Cognos 10 BI the IBM Cognos Connection portal is where almost all security relatedsettings regarding authorization must be specified and managed. This starts with defining whichexternal security objects such as users, groups and roles that are brought in from an externalauthentication source will be assigned to secured features and functions as well as defining objectsecurity for application content such as packages, reports and dashboards.

The IBM Cognos 10 Information Center has a considerable amount of information about detailsand specifics in this area, which is why we will refer to there for the basics and only describeadditional recommendations which add value over what's already documented.

Authorization Concepts and Best PracticeThe first step in understanding authorization for IBM Cognos 10 BI is to understand the objectsinvolved. In simple words, authorization works by defining permissions for securable objects andfunctions organized in a hierarchy kept in Content Store. This hierarchy of objects is initializedupon the first start of IBM Cognos 10 BI when the Content Store tables are created and pre-populated with the default objects and permissions to them. Among those objects is the Cognosnamespace to which predefined roles and built-in objects such as the Everyone group and theAnonymous user are added.

Refer to the following IBM Cognos 10 Information Center links below for more information on theinitial built-in objects and predefined roles.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16486asg_builtin_entries.html#asg_builtin_entries

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16550PredefinedEntries.html#PredefinedEntries

The default permissions, like any other set of permissions, define what type of access users,groups or roles from any namespace, including the Cognos namespace, has to the securedobject or function. Upon initialization, there are no assignments for external security objects to any









Page 14 of 21

permissions in the Cognos namespace. The authorization is defined based only on objects fromthe Cognos namespace. This is actually a good starting point for implementing the Best Practiceabout authorization since this the most flexible and manageable approach to use and therefore theBest Practice to strive for.

The initial access permissions can be found at the following IBM Cognos 10 Information Centerlinks,

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id49368asg_contentmamager_hierarchy.html#asg_contentmamager_hierarchy

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id53448asg_bux_access_permissions.html#asg_bux_access_permissions

To elaborate, one defines authorization by assigning users, groups and roles to permissions whichin turn are defined for a securable object such as a report, a schedule, a secured function or acapability. Since users can only originate from external namespaces, the Cognos namespacedoesn't support users (with the exception of the built-in Anonymous user), an administrator wouldhave to assign users to the securable Cognos objects explicitly or implicitly. Implicitly refers toassigning groups or roles the user is a member of.

If in a permission a user is referenced explicitly, this permission is dependant on the namespacethe user originates from. If the namespace becomes unavailable or the user's unique identifierchanges, this reference will be broken. This is one of the reasons why the unique identifier of auser should be based on some globally unique attribute from the authentication source and noton structurally dependant information. For LDAP servers, the DN is actually a path to the entry.If the user is moved around in the LDAP object hierarchy, that path changes and if the user wasidentified in Cognos by the DN (which is the default), the user's unique identifier to Cognos wouldbe changed and permissions will be broken. By following the Best Practice for unique identifiersthat mentioned above, in particular for LDAP namespaces, you will be shielded from this. ActiveDirectory is safe since the objectGUID is not dependant on structural information. The scenarioapplies to implicit references as well, since the same statement holds true for external group orrole references, they are identified by their unique identifier to IBM Cognos 10 BI.

Another challenge is that it is possible that the underlying authentication source might needto change. Where today an LDAP might be used for the test environment, in production anActive Directory instance may be used. This means that in this case objects from the externalnamespaces have been assigned to permissions and functions directly, and the references tothe those namespaces will be broken as well because a different namespace will assign differentunique identifiers to the objects.

To alleviate these challenges there is a simple Best Practice for authorization - All references inpermissions, capabilities and secured functions should only be made to groups and roles from theCognos namespace. This means only groups and roles created in the Cognos namespace should









Page 15 of 21

be used to define permissions. For example, to allow a certain set of users to use an IBM Cognos10 Studio, one would either use one of the predefined roles from the Cognos namespace or createa new role explicitly for this purpose and assign this role to the corresponding capability. Whilethis might appear cumbersome to create multiple new groups or roles in the Cognos namespace itactually adds great value. The reasons for this are,

• All references to objects used in permissions will remain intact even if the members of therole/group referred to will change.

• The contents of the Cognos namespace can be migrated via deployments to other IBMCognos 10 Systems.

• The creation or assignment of external objects to Cognos namespace entries can beautomated through the IBM Cognos 10 SDK.

Consider a simple example,

A project is developed in a test environment using a simple LDAP provider with some test users.The project team sets up authorization so that several project-specific group and role objects getadded to the Cognos namespace, ignoring or deleting the default Cognos namespace entries. Inthe next step they assign users and groups from the LDAP provider to the new project-specificCognos namespace objects entries and subsequently define permissions for studio capabilities,package access and even IBM Cognos Framework Manager security filters (filters which are builtinto the model for querying the data), based on the new Cognos namespace objects.

When the development has been completed in the test environment, the IBM Cognos 10application consisting of packages, reports, etc., is deployed to the pre-production environmentwhich uses Active Directory with many thousands of users. This implies that different users willneed to be added and existing references to external namespace objects will be broken.

However, since the project followed the Best Practice by having all references in permissions,capabilities and secured functions made only to groups and roles from the Cognos namespace,they can export the IBM Cognos 10 application into a deployment that includes the Cognosnamespace. This will preserve all permissions and in the target environment the only thing left todo is adjust the assignments of users and groups from the Active Directory to the roles and groupsdefined in the Cognos namespace. All the rest remain intact with no need to re-define or adjusta single permission. This is a great time-saver and keeps the project flexible. In addition, if theydefine groups in their Active Directory to hold the users and only assign those AD groups to theCognos namespace groups and roles, they can even manage part of the authorization in AD ratherthan in Cognos. For some clients this is important since identity management integration or accessmanagement processes might be in place already.

Users, Groups and Roles

User Maintenance

IBM Cognos 10 BI stores its user profiles, and their associated content, in the Content Storedatabase. In an environment where there are many users, this could potentially consume quite a



Page 16 of 21

bit of space. Users being removed from authentication sources, is an everyday occurrence at mostcompanies, so why keep outdated user profiles and content in the Content Store?

The following Best Practice assumes that the user's profile is deleted in IBM Cognos 10 BI prior toremoving the user account from the authentication source.

• Login to IBM Cognos Connection with a userid that is a member of the Directory Administratorrole.

• Click Launch > IBM Cognos Administration.• In IBM Cognos Administration select the Security tab.• Click on the namespace containing the user account to be deleted.• Locate the user whose profile needs to be deleted. Use the Search feature if the namespace

hierarchy is deep and/or the location of the user account is unknown. The search icon is amagnifying glass and is in the upper right.

• In the Actions column, click the More... link.• Click on the Delete this user's profile link to delete the profile.• Click OK to confirm the deletion of the user profile.

In most environments, the ability to pro-actively delete a user account may not be a reality.Fortunately, IBM Cognos 10 BI provides a mechanism to synchronize the set of profiles held inContent Store with the underlying external namespaces regarding user accounts.

• As a user with administrative access to IBM Cognos 10, log in to all namespaces which shallbe verified/checked.

• From IBM Cognos Connection, select Launch > IBM Cognos Administration.• Select the Configuration tab and click on Content Administration in the left menu.• Click on the down arrow on the New Content Maintenance button and select the New

Consistency Check link.• Enter a name and optional description and/or screen tip then click Next.• Select the external namespace(s) to be verified by the consistency check and click Next.

The user must be authenticated to all selected namespaces, for the task to work effectively.Missing authentication to a namespace at this point will exclude the namespace from the task.

• Choose Save and run once to execute the task only one time, Save and schedule toschedule the execution of the task for later and possibly in reoccurring intervals or Save onlyto not run the task and click Finish.

• If chosen to run once, specify a time to execute the maintenance task and then chooseto either Find only or Find and fix any inconsistencies for the selected namespaces. Asmentioned earlier, this requires that the user running the task right now is authenticated to allthe selected namespaces. Click Run to start the task, then in the upcoming dialogue don'tforget to check the View the details of the content maintenance task after closing thedialog option. This will forward to a page which can be refreshed by clicking Refresh in theupper right until the status changes to succeeded or failed. Any messages regarding specificusers will be displayed in the list on this page.

• If chosen to schedule the task, a new schedule will be saved along with trusted credentialsbased on the current authentication. The trusted credentials will include all of the namespaces



Page 17 of 21

currently authenticated to. Specify the interval and time of execution and select either Findonly or Find and fix as the mode to use.

The task will run a consistency check to verify that the user profiles stored in Content Storedatabase are in sync with the users in the external namespace(s). If any users cannot be locatedin the external authentication source and they have an existing profile in Content Store, a messagewill be logged stating that the account no longer exists in the external authentication source. If theFind and Fix mode has been selected, the user profile will be deleted from the Content Store.

It is considered a Best Practice to schedule a Content Store maintenance task performing thisaction at least one a month to avoid wasting space in the Content Store.

More information on this topic can be found in the IBM Cognos 10 BI Administration and SecurityGuide located in the IBM Cognos 10 Information Center at,

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id8165content_store_maint.html#content_store_maint

Role/Group Naming

To help organize roles in the Cognos namespace, which can become very abundant in a largedeployment, it is recommended to create folders to allow for a logical separation of the roles.These folder names then assume part of the search path of the role. The search path refers tothe path describing the location of the object in the Content Store object hierarchy. For example,two folders could be created and within each of these folders, a role could be created and thename of the role can be the same. To illustrate, two folders were created within the Cognosnamespace, one called Roles East and the other Roles West. In each folder, a role called DataAdministrators was created.

Directory > Cognos > Roles East > Data AdministratorsDirectory > Cognos > Roles West > Data Administrators

Two roles with the same name were permitted because the name of the parent folder becomespart of the search path for each object. At the same time, for objects in the Cognos namespace theinternal ID of those objects, referred to as the CAMID, contains part of the search path as well.

CAMID(":Roles East:Data Administrators")CAMID(":Roles West:Data Administrators")

Although this type of naming convention works and is supported within IBM Cognos 10 BI, it is nota recommended approach. This technique can easily lead to mistakes when defining permissionsor object security as the objects appear to be the same when displayed in the list of members. Ifthe person applying security was not aware of the two distinct groups, incorrect access could begranted or denied to an object. The following illustration shows an example of this, since there isno additional context provided by IBM Cognos Connection to properly identify, at a glance, whichrole object belongs to which folder.






Page 18 of 21

Illustration 1: A member list of a role in IBM Cognos Connection showing twomembers with the same name which are not distinguishable at first glance

If the deployment absolutely requires roles of the same name to be created, using a tool tip canhelp identify which role is which. Then by simply hovering the mouse over the ellipsis (…) the tooltip will display the full path to the object as can be seen in the following illustration.

Illustration 2: A member list of a role in IBM Cognos Connection showingagain two identically named members but the tooltip provides context byshowing the search path

A naming convention should be established to avoid duplicate naming for roles and/or groups. Acommon practice is to prefix the entries with something like “R_” for role, “G_” for group and addadditional prefixes to indicate where they come from if required. For example, “R_HR_Approver”and “R_Marketing_Approver” could be two roles from different search path or even the same path.In the example above the prefix enables to distinguish them.

PermissionsThe IBM Cognos 10 Information Center provides sufficient detail about permissions and their use.It is important to understand the concepts described there to avoid traps.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15131AccessPermissions.html#AccessPermissions

Deny takes precedence

You can grant access or deny access to entries. Denied access has precedence over grantedaccess. Therefore when you deny specific users, groups or roles access to an entry but youreplace other security policies that grant access to the entry, the grant and deny permissions are inconflict and access to the entry is always denied. For example, a user belongs to two groups. Onegroup has access granted to a report and the other group has access denied to the same report.Access to this report is denied for the user.

As a Best Practice, deny access only when it is really required. Typically, it is a betteradministrative practice to explicitly grant permissions than to deny them.

Breaking inheritance by explicit override only






Page 19 of 21

Access permissions are acquired from parent entries. If access permissions are not definedexplicitly, the entry acquires permissions from its parent entry. You can replace/override thisfunctionality and thus break the inheritance of parent permissions by explicitly defining permissionsfor the child entry.

Objects that exist only as children of other objects always acquire permissions from their parents.Examples of such objects are report specifications and report outputs. These objects can bemanipulated using the IBM Cognos 10 SDK but you cannot set permissions for those objects usingIBM Cognos Connection.

Deleting predefined groups and roles

When you delete a predefined group or role from the Cognos namespace, access permissionsbased on it are also deleted. In IBM Cognos 10 you can restore them by creating a new group orrole in the Cognos namespace with the exact same name which will lead to the same internal ID(CAMID). For external groups or roles (those read from an external authentication source throughthe authentication provider) check how your authentication provider deals with such situations.Typically, you cannot recreate access permissions if they are based on IDs but you can if theyare based on names. An example for this would be an LDAP namespace using the DN attributefor unique identifier which is only a string. However, as pointed out before, this bears the riskof unwanted access to user profiles as well and is not a Best Practice so the statement aboutdeleting groups and roles should be considered generally applicable. Don't remove groups or rolesunless you're absolutely sure you don't need them any longer. All permissions assigned to thegroup or role will be lost.

Capabilities

In IBM Cognos 10 BI there are many secured functions and features which are controlled byassigning permissions to corresponding capabilities. The following link in the IBM Cognos 10Information Center contains more information on secured functions and features. It is important toread the descriptions provided and fully understand the impact of allowing access to a feature orcapability for your security design. There's probably more to it than simply removing the Everyonegroup from various roles and capabilities.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15670ReportNetSecuredFunctionsandFeatures.html#ReportNetSecuredFunctionsandFeatures

After the initialization of the Content Store database default permissions are set which allow for abasic out of the box configuration to start. The initial Content Store objects and permissions aredocumented in the IBM Cognos 10 information Center at,










Page 20 of 21

However, the initial permissions don't always reflect the optimal setup for your design nor dothey implement any licensing model or compliance to such. They are simply an example of aconfiguration that could be used. To effectively apply a security policy, one must revisit variouscapabilities and modify the default permissions. Refer to the following link in the IBM Cognos 10Information Center for more information on specifying security settings,

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16676SpecifySecuritySettingsAfterInstallation.html#SpecifySecuritySettingsAfterInstallation

Capabilities not only exist at general level but at package level as well. Use this feature to controlaccess by the IBM Cognos 10 studios to packages and consequently data sources.

As a Best Practice, start with defining your objects in the Cognos namespace and only then assignCognos namespace roles/groups to capabilities.

Data Source Credentials

As of IBM Cognos 10 BI, there is a new feature whereby users can manage their own databasecredentials if granted access to the Manage own data source signons capability. This can removethe onus of maintaining or managing a large number of stored signons from the IBM Cognos 10administrator and empower users to maintain their own credentials.

As a Best Practice, decide on whether you want to empower your users to do this beforeimplementing data sources. The reason is that if users were allowed to manage their signonsand at a later point an administrator defines a static signon, this will overwrite any user savedcredentials thus potentially breaking reports and/or schedules. This can be tricky to find andcan take a significant effort to remedy. As a result this is a decision best made before startingimplementation.






Page 21 of 21

About the author

Business Analytics Proven Practices Team

Business Analytics Proven Practices Team

© Copyright IBM Corporation 2011(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ibm/trademarks/

Documents

Cognos 10 Security.pdf