Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies

Guideline Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies Product(s): IBM Cognos 8 BI Area of Interest: Security

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 2 Copyright Copyright 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com.

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 3 Contents 1 INTRODUCTION... 4 1.1 PURPOSE...4 1.2 APPLICABILITY...4 1.3 EXCLUSIONS AND EXCEPTIONS...4 2 IBM COGNOS 8 BI INTEGRATION WITH THIRD PARTY AUTHENTICATION PROXIES... 4 2.1 MOTIVATION...4 2.2 GENERAL APPROACH...4 2.3 INTEGRATION BY SINGLE SIGN-ON VS TRUSTED SIGN-ON...5 2.4 REALIZATION...6 2.4.1 Configure Proxy to populate header/clear text cookie...6 2.4.2 2.4.3 Add IBM Cognos 8 URL to realm...6 Configure IBM Cognos 8 to leverage Header/cookie out of the box...6 3 APPENDIX A - REFERENCES... 7

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 4 1 Introduction 1.1 Purpose This short guideline will describe the possibilities of integration with 3 rd party Authentication Proxy products like WebSeal, CAS or Siteminder from a general view. It s purpose is to educate about the possible integration points. 1.2 Applicability The Guideline applies to all versions of IBM Cognos 8 BI regardless of platform. 1.3 Exclusions and Exceptions The document will not describe how to set up integration in detail but rather describe the possibilities. For detailed descriptions consult product documentation and/or documents on TechTalkInsider. 2 IBM Cognos 8 BI integration with Third Party Authentication Proxies 2.1 Motivation IBM Cognos 8 BI does only support CA Siteminder out of the box. However many other Authentcation proxies exits in the wild and comprehendingly integration is desired. This little paper shall list the possible integration points. This should enable the reader to go forward with integration or at least be able to explain the possibilities to customers. 2.2 General Approach IBM WebSeal, CAS, Netegrity SiteMinder, OAM (Oblix Netpoint), RSA Clear Trust are all authentication proxies. Authentication Proxy server architectures typically consist of a central repository often called policy server which stores authorization and administrative information and some satellite pieces, sometimes called agents which get deployed to web or java application servers. The agents interface with the host of the resources to protect, for example with the web server for protecting some virtual directories or java application server to protect servlets. The authentication proxy governs authentication and authorization over the resources it protects. It accesses user repositories like LDAP or Microsoft ADS. establishes and maintains user sessions enforce session validation throughout the network protected by it In networks secured by 3 rd party authentication proxies, the proxies issue some token which is passed in the HTTP traffic ito implement SSO across all servers. This token usually is some (encrypted) cookie but HTTP header variables are feasible as well.

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 5 IBM Cognos 8 can potentially leverage 3 rd party authentication tokens to implement Single Sign-on (SSO) solutions. So far, direct support for proprietary tokens only exist for CA Siteminder. All other proxies need to interface with IBM Cognos 8 through some clear text headers or cookies depending on the desired namespace to use for IBM Cognos 8 authentication. 2.3 Integration by Single Sign-on vs Trusted Sign-on To achieve a seamless sign-on experience IBM Cognos 8 supports two concepts. Single Sign-On implies that IBM Cognos 8 will take on some UserID received from a previous authentication layer like for example an authentication proxy. The user will not get prompted for credentials by IBM Cognos 8 again. For Single Signon an IBM Cognos 8 authentication provider will investigate some (for some providers configurable) http variable (or cookie) to retrieve a user ID. Rather than accepting it s value directly which is passed as an http header in the request some challenge to the entry point, a typically the gateway or a dispatcher if gateway is omitted, is sent. The Entry point will read the value from the local HTTP environment and use it to lookup the user in the authentication source. If this lookup succeeds, the user is logged in to IBM Cognos 8. For trusted sign-on some special kind of IBM Cognos 8 authentication provider, a so called trusted signon provider can be coded 1. This provider will consume some token and deduct from it some userid. In the next step this user ID is again passed to some full blown IBM Cognos 8 authentication provider using REMOTE_USER standard header variable. Opposed to Single Sign-on though, the provider will not challenge the entry point, but rather accept the passed in value as trusted and simply look up the user in an authentication source. For both cases, as always, IBM Cognos 8 will not authenticate the user itself but rely on 3 rd party authentication sources for this. In single sign-on or trusted sign-on though, IBM Cognos 8 never obtains credentials for a user but simply relies on a lookup and assumes the user has been authenticated by proper credentials before. For the lookup however, IBM Cognos 8 must have access to an authentication source where exactly one user will be looked up based on the information passed in the header/cookie. However, it doesn t need to be exactly the same authentication source. For example, if the user has been authenticated by some authentication proxy based on LDAP, the proxy passing some value in REMOTE_USER, in IBM Cognos 8 there can be some authentication provider configured for Series7 leveraging OSSignon and hence allowing a user to be looked up based on the information passed. Ideally though, one would use an LDAP authentication provider pointing to the same LDAP in this case to ensure the correct user is looked up as any mapping incurs the potential for errors/fraud. Neither of both methods does involve authorization information, not even for CA Siteminder. Authorization for IBM Cognos 8 can only be managed in IBM Cognos 8 or automated through the SDK. There is currently no integration between IBM Cognos 8 1 For CA Siteminder such a provider is delivered out of the box, for other authentication proxies it could potentially be developed using the IBM Cognos 8 Authentication Provider SDK.

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 6 and any Identity Management or Authorization Proxy software. This being said, authentication is a different step than authorization for IBM Cognos 8 during the login process. 2.4 Realization Almost all of the authentication providers delivered out of the box support singlesign-on. Trusted Sign-on is supported through the CA Siteminder provider for Siteminder and by the Shared Secret provider for Portal integration with 3 rd party portals. For other authentication proxies both concepts can be leveraged. Single Sign-On is straight forward and easy to setup as most authentication proxies provide some header at the entry point level like REMOTE_USER or some clear text cookie. For trusted sign-on coding is required, Trusted Sign-On providers (TSP) are usually only around 100 lines of code though. 2.4.1 Configure Proxy to populate header/clear text cookie Besides their proprietary token almost all proxies allow for populating standard HTTP headers after successful authentication. Sometimes this has to be configured explicitly, sometimes it s by default. Please consult your Proxy documentation. One the most commonly used header variables is the REMOTE_USER header variable which is standard to contain the user authenticated by the http layer. Basically any clear text header, HTTP environment variable or clear text cookie is feasible. Encrypted cookies, like proprietary authentication proxy tokens, won t work out of the box as they cannot be read. For solutions leveraging those some TSP employing the authentication proxy SDK (if available) needs to be developed. 2.4.2 Add IBM Cognos 8 URL to realm For IBM Cognos 8 to be part of the protected realm, the IBM Cognos 8 web alias URL (typically the gateway or dispatcher URL) has to be added to the realm defined in the proxy. (i.e: http://hostname/cognos8). Only then accessing IBM Cognos 8 will invoke the Proxy authentication mechanism. 2.4.3 Configure IBM Cognos 8 to leverage Header/cookie out of the box Depending on the namespace used for authentication in IBM Cognos 8 different functionalities exist. Namespaces can be either of the following: LDAP, ADS or Series 7 namespaces 2. 2.4.3.1 LDAP The LDAP namespace configuration allows for using macros in the External Identity mapping property. One of those macros enables reading HTTP headers/environment variables. To achieve single sign-on, the Use external Identity mapping property must be set to True. In that case, the LDAP authentication provider will evaluate the string in External Identity mapping. If this string contains a valid LDAP filter which 2 If some custom coded authentication provider (CJAP) supports SSO it would be applicable as well.

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 7 uses the ${environment()} macro, it is possible to look up the user passed by some http header. Example: Name Value Notes Base Distinguished Name Dc=cognos,dc=com Enter the base distinguished name for your LDAP. Use external identity True mapping External identity mapping (uid=${environment("remote_user")}) Bind user DN and password Enter a user that has read and search access to your LDAP. If you ve got anonymous access enabled for your LDAP you can leave this blank. This will lead to an LDAP search, which looks for some entry with uid matching the value passed in REMOTE_USER, starting at the BaseDN, searching all subentries. The search is run using the specified Binding Credentials only. If the search returns a single result, the user is considered looked up. In the next step additional information form the user will be read, again using the BC, to complete the authentication. Any clear text header variable can work here. It is NOT possible to read the value of cookies though. 2.4.3.2 ADS Namespace For ADS namespace single sign-on is supported through Kerberos (does not apply here as it works through Kerberos tokens only) or REMOTE_USER header. To disable Kerberos SSO in the ADS namespace the advanced property singlesignonoption must be set to IdentityMapping. This will cause ADS authentication provider to pick up the REMOTE_USER variable for SSO. The value will be used to lookup a user in the domain the AD provider is configured to or, if prefixed with <domain>\, in the specified domain if within configured scope. 2.4.3.3 Series-7 namespace As of IBM Cognos Series 7 Version 3 there is a property available in Access Manager which allows to specify some external identity mapping string like in the LDAP namespace configuration. By default Series7 will look for REMOTE_USER and match it s value with strings entered as OS Signons for the Series7 users. By changing this string though, any header or clear text cookie can be read through the use of macros. The ${environment()},macro reads some HTTP header and ${cookie()} will read clear text cookies. Please consult the IBM Cognos Series 7 documentation for details. 3 Appendix A - References More information on the Authentication provider configuration settings can be found in the document Cognos 8 Business Intelligence Installation

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 8 and Configuration Guide (inst_cr_winux.pdf) Chapter 11: Configuring Cognos 8 Components to Use an Authentication Provider on page 255. KB 1014767 and 1004499 for configuring Siteminder namespaces