User Pass-Through Authentication in IBM Cognos 8 (SSO to data sources)

Transcription

1 User Pass-Through Authentication in IBM Cognos 8 (SSO to data sources) Nature of Document: Guideline Product(s): IBM Cognos 8 BI Area of Interest: Security Version: 1.2

2 2 Copyright and Trademarks Licensed Materials - Property of IBM. Copyright IBM Corp IBM, the IBM logo, and Cognos are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at 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. IBM does not accept responsibility for any kind of loss resulting from the use of information contained in this document. The information contained in this document is subject to change without notice. This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

3 3 Table of Contents 1 Introduction Purpose Applicability Exclusions and Exceptions Database access concepts in IBM Cognos Data Sources in IBM Cognos Accessing a database Automatic authentication during data access User pass-through authentication to a database SSO to various data sources Microsoft SQL Server (MSSQL) Microsoft Analysis Services (MSAS/SSAS) IBM DB Informix ORACLE SAP BW TM Appendix A Credentials supported by authentication providers...17 Appendix B User Pass-Through authentication set-ups Appendix C References...20

4 4 1 Introduction 1.1 Purpose This document provides backgrounds and concepts required to understand the user pass-through possibilities of IBM Cognos 8. Its purpose is to supplement product documentation and explain the possibilities and limitations. 1.2 Applicability The technical concepts described herein apply to IBM Cognos 8 version 8.4 GA, RP1 and their respective Fixpacks. 1.3 Exclusions and Exceptions This document will not cover implementing the described user pass-through scenarios. Please refer to documents specific to the database you are looking to use. Refer to Appendix C for some pointers. 2 Database access concepts in IBM Cognos 8 This section briefly describes how IBM Cognos 8 BI authenticates with data sources in general. This includes user pass-through authentication, typically referred to as Single Sign-On to a data source. 2.1 Data Sources in IBM Cognos 8 In IBM Cognos 8 BI Server, a data source is represented by a 3-level metadata concept consisting of Data Source -> Connection -> Signon. The top level element of Data Source specifies the name by which the system identifies this data source; Packages and links will refer to this name. In general, there is one Data Source per physical database to which IBM Cognos 8 BI attaches. The Data Source object must have at least one child object of type Connection; it can have many though. A Connection defines parameters for attaching to the database when creating a session. This includes locales, collation sequences, cursor modes, etc.; basically everything which will make up the connection string. In addition, the Connection defines the type of authentication to the database used to establish a session. No Authentication at all: The connection will be established without presenting authentication information Authenticate based on Signon: A database connection will be established based on a credential taken from a Signon object defined for this Connection object. Authenticate based on information from an external Namespace: A database connection will be established leveraging information obtained from a call-back to the authentication provider attached to a namespace defined for IBM Cognos 8 security.

5 5 Authenticate based on IBM Cognos 8 Service Credentials: A database connection will be established using the security context of the process running the ReportServer and MetaDataServer components. Depending on the type of IBM Cognos 8 Data Source, all or only some of the above authentication types will be supported and hence be available in the UI. Each Connection object is a unique object and is hence applicable to individual object security. That implies that a single IBM Cognos 8 user may only have access to one or some of the defined Connections of a Data Source. Finally Signon objects contain a static credential composed from a user name and a password. They get saved as child objects of a Connection. A single Connection can have many Sigons defined for it. Like with Connections the Signons are independent objects with individual object permissions assigned to them. When creating a data source, the Data Source, a single Connection, and typically a Signon, which is accessible by the Cognos namespace group everyone, will be created. An Administrator can change all aspects of a Data Source and its child objects later on in Cognos Administration. 2.2 Accessing a database IBM Cognos 8 BI Server attaches to databases through it s Data Access and Modelling (DA&M) software stack. This collection of software component stacks distinguishes between relational data access, OLAP data access and metadata data access. Each type of data access is implemented following a general concept whereby database or context specific code is packaged in providers which plug-in to some overall logic based framework. This implies that the database specific code is separated from the more general logic code. Requests for data get routed by the framework components to the more specific providers which usually interface with some 3 rd party libraries/apis to facilitate the technical level of data access. Every request passed down to the specific provider will contain all required metadata to establish a connection/session with the database. This involves the connection string information as well as authentication information. Depending on the provider, the authentication information is expected to be passed down directly as part of the request (authentication based on Signons) or the provider will expect some indication of what it shall do in regards to authentication (ignore, use Service Credentials, or acquire from namespace). In the case of no static Signon being passed down, we refer to this as user pass-through authentication or SSO to the data source since the connection/session will have to use an existing, pre-established security context. Either way, the provider will gather the authentication information and eventually call database vendor defined APIs to establish a connection. Usually a single database connection can handle several database sessions. That way multiple requests using individual sessions may (re-)use the same connection.

6 6 IBM Cognos 8 supports command blocks, which contain statements sent to the database triggered by establishing/closing a new database session or database connection. This feature allows calling stored procedures or functions and helps creating integrated solutions. In addition these command blocks can be leveraged to implement user pass-through authentication as well if the database supports switching the session s security context dynamically. This supplements cases where IBM Cognos 8 does not support the authentication type of an external namespace for a specific type of database, for example ORACLE. Refer to Appendix C for more information. Once a database connection and session is established, the provider will read the requested data and return it to the framework layer where further actions may or may not be triggered. Eventually a result based on the retrieved data is returned to the requesting component. 2.3 Automatic authentication during data access In the previous section the process of accessing a database was described, in particular the different types of authentication for a Connection as a child object of a Data Source. For the case of authentication based on an external namespace, there are certain considerations. When configured for authentication based on an external namespace, the actual credentials to pass on to the database will be retrieved from that configured namespace. However, since there can be more than one namespace configured in IBM Cognos 8, the user must authenticate to the appropriate namespace to achieve data access. IBM Cognos 8 allows for configuring multiple namespaces a user can authenticate to. To establish a session in IBM Cognos 8 the user is required to authenticate to at least one namespace (given anonymous access is disabled). He may choose to subsequently authenticate to other namespaces as well because some objects may have been secured against a different namespace than the one he authenticated to initially. This will add visas, one per namespace, to their passport. The passport is the means to store all authentication information for a user s session. Whenever an object in Cognos 8 is accessed, authorization will take place based on the permissions defined referring to users, groups, and roles defined in namespaces. A user s passport is investigated to find out to which namespaces he is authenticated in the current session. Now when a Data Source is configured for external namespace authentication there has to be a visa for that particular namespace in the user s passport. If not, the user has not authenticated to that namespace and consequently no credentials have been provided which could be passed on to the database. In earlier versions of IBM Cognos 8, this lead to an error message upon accessing the Data Source, which did not indicate the required action clear enough. As of IBM Cognos 8 BI version 8.3, this has been fixed by triggering the authentication process upon accessing the Data Source.This is called auto log-on.

7 7 The effect is that if a user accesses a Data Source configured for external namespace authentication referring to a namespace for which no visa has been obtained yet, the namespaces underlying authentication provider is called to start the authentication process. If that authentication provider is configured for SSO, this can happen in the background and be completely transparent to the user. If not, the login screen will pop up, requesting credentials valid for this namespace. Auto Log-in improves the user experience and only prompts the user when needed. The feature may be leveraged for user pass-through under some very specific conditions. Refer to the subsequent sections for details. 2.4 User pass-through authentication to a database As explained in section the Connection object defines the type of authentication performed when accessing a database. If that type is Service credentials or external namespace, the data access layer is instructed to take on a pre-existing security context and pass it to the database. For those two types of authentication, it is implied that a user authenticated to some external security system like the Operating System, a web server or a portal before accessing IBM Cognos 8. In the next step some trusted authentication to IBM Cognos 8 was performed, that is IBM Cognos 8 trusted the authentication it was passed and did not re-authenticate the user. IBM Cognos 8 will take the authentication information and use it when accessing the database; it passes through the obtained security context. This is what is referred to as user pass-through authentication or SSO to a data source. The case of leveraging some common environmental security context for all database access (the authentication based on Service credentials) is very specific and only applies to Windows based installs when attaching to a Microsoft SQL Server database. It is a form of user pass-through authentication by definition since the security context of the executing process is passed to the database. However, when referring to user pass-through authentication, it is common to imply passing the credentials of the user currently logged on to IBM Cognos 8 which translates to acquiring the authentication information from a namespace only. One would want to use user pass-through authentication to the database whenever the data security is implemented in the database and hence each user must authenticate to the database individually. As this is considered the best practice it is advisable to strive for user pass-through authentication whenever possible.

8 8 The advantage over using an individual Signon per user is that individual Signons would have to be managed inside Cognos and depending on the number of users this poses a maintenance challenge, in particular if the database passwords expire. IBM Cognos 8 offers no built-in functionality for bulk management of Signons, so one would have to code SDK based solutions or educate users to maintain their Signon information themselves. However that requires certain Cognos privileges and users may not be eligible for those permissions. Using individual Signons is an approach which will work in all scenarios though. The following sections will describe some aspects of user pass-through authentication in detail Authenticate based on Service Credentials In the case of Service Credentials, it is implied that the connection to the database will be established using the credentials used to run the ReportServer component (BiBusTKServerMain executable) or, in case of testing a data source or metadata access, the Metadata Server (BmtMDProvider executable). Both the ReportServer and the Metadata Server are run in the security context of the account executing the Servlet Container hosting IBM Cognos 8 s servlets. This sometimes is referred to as the user running IBM Cognos 8. On Windows a default install will use Tomcat which is started by a service registered when starting the product for the first time. The default user will be Local System, but of course that can be changed. The same applies to Linux/ UNIX environments; whichever account started the servlet container will be the Service Credentials. So if Bob started WAS, the BiBusTKServerMain executable (or the BmtMDProvider executable) will be started using Bob s security context, hence the connection to the database will be created using Bob s credentials. As this authentication type is supported for Microsoft MSAS/SSAS and Microsoft SQL Server Data Sources only, which are supported on Microsoft Windows based installations of IBM Cognos 8 only, this translates to spawning a thread using the service credentials. From this thread the connection to the database is established.

9 Authentication based on an external Namespace For the authentication type external Namespace the explanation is a bit more complex. When the configuration indicates that the connection to the database should authenticate based on information obtained from a specific external namespace, the data access components will call a special function of the authentication provider 1 associated with that namespace. The authentication provider function GenerateCredential() will return a credential which will be passed to the data source. This credential does not necessarily need to be username and password. It can be any binary data; as long as the data source accepts it for authentication, it is valid. For example, Microsoft SQL Server allows authentication based on Kerberos. Given proper configuration, the function will return a Kerberos token which will be passed to MSSQL. The important thing to know about GenerateCredential(), which every authentication provider implements, is that it can only return information the authentication provider has been provided at logon time when the IBM Cognos 8 session has been authenticated. This means that if a user, Bob, authenticated to a namespace by providing username and password, that information is available to the authentication provider and hence can be returned by GenerateCredential().But if the user "Bob" authenticated to the namespace by SSO such as authenticating to the web server, which populates REMOTE_USER, which in turn is used by the authentication provider to facilitate SSO to IBM Cognos 8 (a trusted authentication whereby the namespace did trust the value in REMOTE_USER), then the authentication provider does not know a password for that user because he never provided one to IBM Cognos 8. Consequently GenerateCredential()cannot return a credential consisting of username and password but only a username. Depending on the database to attach to, this might or might not be sufficient to authenticate the user. A user pass-through authentication in this scenario may not be feasible Authentication when executing in batch-mode Regardless of whether the data access is part of an interactive request (i.e. a user working in an authenticated session interactively requesting a report) or of a task being run in batch (background processing of schedules/triggers) the same process is followed. The important difference is that for batch processing, a Cognos session must be established first by authenticating to a namespace. Once the authenticated session is established, data access works the same as if the user would be logged in interactively. Since there is no user available to provide authentication information in batch processing, the login information for IBM Cognos 8 must come from somewhere else. 1 The term "authentication provider" in this context refers to a piece of software which is part of the Cognos Access Manager component of IBM Cognos 8 BI Server. The authentication provider is the code which is responsible for dealing with authentication to an authentication source like LDAP, AD, Series 7 etc.

10 10 For batch processing, the function GenerateTrustedCredential() will have been called when the schedule was created. This will have generated a credential which got saved along with the schedule. The important difference over the credential returned from GenerateCredential()is that a trusted credential is used to authenticate to IBM Cognos 8 only; it may and will be different from the credential returned for data access. Since the trusted credential (TC) is used for batch processing, it must contain sufficient information to authenticate the user to a Cognos namespace. Whether or not the TC is sufficient depends on the namespace configuration. If a namespace is configured such that authentication is based on a username only, for example, whenever SSO based on REMOTE_USER is configured, then the trusted credential may only contain a username. That trusted credential, once again, is what is provided to the authentication provider at login time and hence determines the credential which can be subsequently returned by GenerateCredential() Set-up Dependencies (i.e. Portal integration) To sum up successful user pass-through authentication depends on a) what information has been provided at logon time (user/tc) and b) what type of credential does the database support for authentication and c) what type of namespace is used Only if sufficient information which adheres to a) and b) is provided can this work. To emphasize, those scenarios involve two SSO hops, one from whatever source to IBM Cognos 8 and another one from Cognos 8 to the database. This is of particular importance when IBM Cognos 8 is not the initial authenticator of a user. This applies to all SSO environments and in particular whenever IBM Cognos 8 BI is integrated in 3 rd party portals. In this case users come in to IBM Cognos by SSO and hence user pass-through can only leverage whatever information has been passed for SSO; typically some user name only though the syntax may vary. If the underlying database allows authentication based on that, all is well, but most often databases require a user name and password and in those cases, user pass-through authentication is impossible. Refer to Appendix B for some combinations and their feasibility. Its important to understand as well, that GenerateCredential() can only return what has been provided by either a batch execution (which would have presented credentials as received by GenerateTrustedCredential() when the schedule was saved) or some interactive user. Even more important is that each function returns a different type of credential. It is wrong to assume they are identical in every case. Credentials are for data source access, trusted credentials are for authentication to an IBM Cognos 8 namespace.

11 11 Not all Data Source types in IBM Cognos 8 support the external namespace feature, however all IBM Cognos 8 BI authentication providers do implement GenerateCredential() and GenerateTrustedCredential(). However, each authentication provider implements them differently, which may impact the type of credential supported and/or additional functionality. Refer to Appendix A for details. 3 SSO to various data sources With the background provided in section 2, it is understood that authentication to any data source is determined by the type of credentials supported by it for the most part. Secondly, the information provided at logon time and the configuration of the IBM Cognos 8 namespace influence the authentication possibilities, in particular for user pass-through authentication. The following sub sections will give a brief overview of what is possible and what is not possible for some but not all specific data source types. If the data source you are looking for is not listed here, contact Customer Support to learn about the details. 3.1 Microsoft SQL Server (MSSQL) The Microsoft SQL Server database is supported as a query database and as Content Manager database. However, user pass-through authentication only applies when SQL Server is used as a query database. If SQL Server is used as a Content Manager database, all access will be run in the context of a single user which is configurable. It is possible to achieve SSO for this account so that the Content Manager connection will accept a Windows logon. Refer to the product documentation for details. The Data Source for SQL Server supports the following authentication types: Signon Service credentials 3 rd party namespace SQL Server supports authentication based on SQL Server logins (some user name and password stored and managed inside SQL Server) or Windows security. Windows security implies either Windows Credentials or trusted Windows Kerberos/NTLM tickets. User pass-through authentication hence is possible in three scenarios: 1. based on SQL Server logins For authentication to SQL Server, the user has to provide a username and password both of which are managed by SQL Server. Any IBM Cognos namespace which can supply a credential consisting of username and password can potentially be used to achieve this. This applies to Active Directory, LDAP, Series7, SAP and NTLM. Of course the username and password used to authenticate to the namespace MUST BE IDENTICAL to the SQL Server login credentials for this to work.

12 12 The requirement for a password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, then IBM Cognos 8 has no password to pass on to the database. 2. based on Windows Credentials For authentication to SQL Server, the user has to provide Windows credentials; a Windows user name of the form DOMAIN\user and a password. The only IBM Cognos 8 namespace that supports Windows user names is the Active Directory namespace. If the user authenticated to the Active Directory Namespace, which is referenced for Data Source authentication using their Windows credentials, they can be passed-through. The same can work under special circumstances (all servers in a single Windows domain only) with an LDAP Namespace attaching to Active Directory as a standard LDAP. In this case user name and password will be valid Windows credentials and hence, user pass-through can work. The Connection will have to be configured for external namespace authentication referring to an Active Directory or LDAP namespace. Again, the requirement for a password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO since IBM Cognos 8 will have no password to pass on to the database. 3. Based on trusted Windows tickets For authentication to SQL server, the user would have to be authenticated by Windows prior to accessing SQL Server. This implies Windows Kerberos tickets with the only exception of local access, which may fall back to other Windows security protocols; usually NTLM. However, it is safe to perceive the fall back as a special simplified case of Kerberos as the details are transparent to IBM Cognos 8. In any case, a security context will exist, which can be passed on in the form of a token. If using an Active Directory Namespace for Data Source authentication to which the user authenticated by means of Kerberos SSO (NOT identity mapping mode), then Cognos will have obtained a token for that user. This token can be passed on to SQL Server. When using Kerberos, this setup is an exception in that it supports user pass-though when authentication to IBM Cognos 8 is through SSO. It is important to understand, that this explicitly does NOT involve setups which contain Microsoft Sharepoint portal services. The required SSO from Sharepoint to IBM Cognos 8 does not use Kerberos and therefore users will not authenticate to IBM Cognos 8 using the Kerberos protocol. Hence, user pass-through is NOT possible if IBM Cognos 8 is integrated into Sharepoint using deployable web parts.

13 13 Finally, if using the Service Credentials authentication type, the connection to SQL Server will be established using the security context of the process running the ReportServer/Metadata Server. As the Service account is already authenticated by Windows, it is a Windows security token that will be used to establish the connection to SQL Server by the data access component stack. Of course, this implies all IBM Cognos 8 users will access SQL Server using the same windows credentials which is only applicable in special setups. 3.2 Microsoft Analysis Services (MSAS/SSAS) Microsoft Analysis Services is an additional service on top of Microsoft SQL Server. The authentication and user pass-through possibilities are very similar to those of SQL Server. The Data Source for Microsoft Analysis Services supports the following authentication types: Signon Service credentials 3 rd party namespace Microsoft Analysis Services allows authentication based on Windows security only. Windows security implies either Windows Credentials or trusted Windows Kerberos/NTLM tickets. User pass-through authentication hence is possible in two scenarios: 1. based on Windows Credentials For authentication to Analysis Services, the user has to provide Windows credentials; a Windows user name of the form DOMAIN\user and a password. The only IBM Cognos 8 namespace supporting Windows usernames is the Active Directory namespace. If the user authenticated to the Active Directory Namespace, which is referenced for Data Source authentication using their windows credentials, they can be passed-through. The same can work under special circumstances (all servers in a single Windows domain only) with an LDAP Namespace attaching to Active Directory as a standard LDAP. In this case username and password will be valid Windows credentials and hence user pass-through will work. The Connection will have to be configured for external namespace authentication referring to an Active Directory or LDAP namespace. The requirement for a password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, then IBM Cognos 8 has no password to pass on to the database. 2. Based on trusted Windows tickets For authentication to Microsoft Analysis Services, the user would have to be authenticated by Windows prior to accessing Analysis Services. This implies Windows Kerberos tickets with the only exception of local access which may fall back to other Windows security protocols; usually NTLM. However, it is safe to perceive the fall back as a special simplified case of

14 IBM DB2 Kerberos as the details are transparent to IBM Cognos 8. In any case a security context will exist which can be passed on in the form of a token. If using an Active Directory Namespace for Data Source authentication to which the user authenticated by means of Kerberos SSO (NOT identity mapping mode), then Cognos will have obtained a token for that user. This token can be passed on to SQL Server. When using Kerberos, this setup is an exception in that it supports user pass-though when authentication to IBM Cognos 8 is through SSO. It is important to understand, that this explicitly does NOT involve setups which contain Microsoft Sharepoint portal services. The required SSO from Sharepoint to IBM Cognos 8 does not use Kerberos and therefore users will not authenticate to IBM Cognos 8 using the Kerberos protocol. Hence, user pass-through is NOT possible if IBM Cognos 8 is integrated into Sharepoint using deployable web parts. The IBM DB2 database is supported as a query database and as Content Manager database. User pass-through authentication only applies when IBM DB2 is used as a query database. The Data Source for IBM DB2 supports the following authentication types: No authentication Signon 3 rd party namespace IBM DB2 supports authentication based on logins (some user name and password) or Kerberos. The latter is not supported by IBM Cognos 8. User pass-through authentication is therefore only possible for logins. For authentication to IBM DB2, the user has to provide a user name and password. Any IBM Cognos 8 namespace which can supply a credential consisting of user name and password can potentially be used to achieve this. This applies to Active Directory, LDAP, Series7, SAP and NTLM. The user name and password used to authenticate to the namespace MUST BE IDENTICAL to the DB2 login credentials for this to work. The requirement for a password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, then IBM Cognos 8 has no password to pass on to the database. Recently a new concept has been introduced to DB2 called trusted Context. This concept works similar to the security context switching in ORACLE and allows to establish a connection using a well known set of credentials (a Signon) and switch the security context only when opening a session based on passing a variable with only a user name in it. This allows for user pass-through authentication with IBM Cognos 8. Note: A document is currently being created to address this technique. Please contact the Proven Practice team for details in the interim.

15 Informix The Data Source for Informix supports the use of signons only. Currently there is no way to achieve user pass-through authentication with Informix datebases. 3.5 ORACLE The Data Source for Oracle supports the following authentication types: No authentication Signon 3 rd party namespace ORACLE supports authentication based on logins (some user name and password) and many other types of credentials. So far, user pass-through authentication however is only possible for either logins or using Security Contexts which works by employing session command blocks. Refer to Appendix C for document references. ORACLE logins usually require user name and password. For user pass-through based on logins consequently any IBM Cognos 8 namespace which can supply a credential consisting of user name and password can potentially be used to achieve it. This applies to Active Directory, LDAP, Series7, SAP and NTLM. The user name and password used to authenticate to the namespace MUST BE IDENTICAL to the ORACLE login credentials for this to work. ORACLE can be configured to allow authentication based on a user name only, however this is not a recommended set-up option and remains a niche solution. The requirement to provide user name and password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, there is no password to be passed on to the database and user pass-through won't work. 3.6 SAP BW SAP BW only supports authenticating users based on SAP credentials (SAP username + password) or some SAP SSOv2 ticket. The SAP credentials are simple strings, so any credential consisting of user name and password which matches the SAP credential will be accepted. The SAP SSOv2 ticket can only be issued from SAP itself from inside a pre-authenticated SAP session. So far this implies using SAP Portal and setting up SSO between SAP Portal and IBM Cognos 8. This is true because there is no other supported way to obtain that token for use with IBM Cognos 8 as of IBM Cognos 8 BI v8.4. The Data Source for SAP BW supports the following authentication types: Signon 3 rd party namespace User pass-through authentication is possible in two scenarios:

16 16 1. based on SAP credentials For authentication to SAP BW, the user has to provide a user name and password both of which are managed by SAP. Any IBM Cognos 8 namespace which can supply a credential consisting of a user name and password can potentially be used to achieve this. This applies to Active Directory, LDAP, Series7,SAP and NTLM. The user name and password used to authenticate to the namespace MUST BE IDENTICAL to the SAP login credentials for this to work. The ideal solution would be to use an SAP namespace which refers to the same SAP system. In that case the credentials used to authenticate to IBM Cognos 8 are the same one as for authenticating to SAP. The requirement for a password when using SAP credentials explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, then IBM Cognos 8 has no password to pass on to the database. 3.7 TM1 2. based on SAP SSOv2 tickets For authentication to SAP BW, the user would have to be authenticated by some trusted SAP system prior to accessing SAP BW. This could be any other SAP system which has a trust relationship with the targeted SAP BW system. In this case, the SAP system the user authenticated to first will have issued a session cookie containing the SAP SSOv2 ticket which, if passed on, will allow trusted authentication to SAP BW. Unfortunately only the SAP namespace does support the SAP SSOv2 ticket. The underlying authentication provider supports SSO to IBM Cognos 8 based on that ticket as well as passing it on as a credential. This implies that if a user authenticated to an SAP namespace by SSO based on SAP SSOv2 ticket, user pass-through authentication will work seamlessly. This again is an exception as it allows user pass-through even though the user authenticated to IBM Cognos 8 by SSO. The use of the SAP namespace is mandatory in that case for the reasons mentioned above. There is no way to achieve user pass-through authentication based on SAP SSOv2 tickets if not using the SAP namespace. SSO works by a CAM_passport cookie being passed to TM1 Server. The Data Source MUST NOT be configured to authenticate based on a 3 rd party namespace. Other 3 rd party namespace setups will require passing full credentials (username and password) valid in TM1. TM1 supports authenticating users based on TM1 credentials (username + password) or an existing cam_passport cookie (the cookie IBM Cognos 8 adds to the session once a user authenticated to at least one of the configured namespaces.) The Data Source for SAP BW supports the following authentication types:

17 17 Signon 3 rd party namespace User pass-through authentication is possible in two scenarios: 1. based on TM1 credentials For authentication to TM1 the user has to provide a username and password both of which are managed by TM1. Any IBM Cognos 8 namespace which can supply a credential consisting of username and password can potentially be used to achieve this. This applies to Active Directory, LDAP, Series7,SAP and NTLM. The username and password used to authenticate to the namespace MUST BE IDENTICAL to the TM1 login credentials for this to work. The requirement for a password explicitly rules out any user pass-through if the authentication to IBM Cognos 8 is based on SSO. For example, in cases where a users does not provide a password to IBM Cognos 8, then IBM Cognos 8 has no password to pass on to the database. 2. based on cam_passport For authentication to TM1 based on a previous authentication to IBM Cognos 8, special setup is required, which is quite different than for other databases. TM1 uses its own authentication and authorization. For integration, it is possible to import users from an IBM Cognos 8 namespace into TM1. When looking for user pass-through, the connection has to be set up WITHOUT AUTHENTICATION. In other words selecting NO authentication. This is contradicting the concept used for all other data source types but this is how it works for TM1. There are additional steps for the TM1 configuration. Refer to the product documentation for details. With this configuration the IBM Cognos 8 passport will be passed over to TM1 achieving user pass-through. Appendix A Credentials supported by authentication providers SAP: Will return SAP ticket or credentials (user/pass) for GenerateCredential(). Only supports full SAP credentials for GenerateTrustedCredential(). If initial authentication was by SSO, the user will get prompted upon the first call to GenerateTrustedCredential(). LDAP: Will return credentials (user/pass) for GenerateCredential()normally.

18 18 If the user came in by SSO, GenerateTrustedCredential() will return an SSO String. The SSO String is a string which is used to authenticate by SSO. Typically this is the content of the REMOTE_USER HTTP environment variable. This concept works as long as the undocumented advanced parameter allowtcsforremoteauth is set to True, which is the default. If set to false, the user will be prompted to provide a username and password upon the first call to GenerateTrustedCredential(). This will then replace the credential saved in the visa and will be used in subsequent calls. If TCs are stored and the setting is changed to False, an unrecoverable CAM exception will be thrown upon authentication. This implies that although the user came in by SSO, TCs can be generated. There is an undocumented advanced parameter dbcredentialmapping. If dbcredentialmapping is set to the name of an LDAP attribute of a user entry, the contents of this attribute will be returned by for GenerateCredential() instead of the credentials. This is a very powerful and flexible feature, however, it is undocumented and must be considered unsupported. AD: Out of the box will return credentials (user/pass) or a Kerberos token for GenerateCredential(). The Kerberos token (actually a crypto handle, which refers to the token) is only valid for user passthrough authentication to Microsoft Analysis Services. If the user came in by identity mapping SSO GenerateTrustedCredential(), an SSO String will be returned. The SSO String is a string which is used to authenticate by SSO. Typically this is the content of the REMOTE_USER HTTP environment variable. This concept works as long as the undocumented advanced parameter allowtcsforremoteauth is set to True, which is the default. If set to false, the user will be prompted to provide a username and password upon the first call to GenerateTrustedCredential(). This then replaces the credential saved in the visa and will be used in subsequent calls. If TCs are stored and the setting is changed to False an unrecoverable CAM exception will be thrown upon authentication. This implies that although the user came in by SSO, TCs can be generated.

19 19 Appendix B User Pass-Through authentication setups Microsoft Sharepoint -> IBM Cognos 8 -> MSSQL : NO Sharepoint uses IIS for authentication which implies integrated Windows authentication, also known as Kerberos. SSO from Sharepoint to C8 is only based on Shared Secret (proprietary IBM Cognos technique), which is essentially REMOTE_USER containing just a username. The only authentication provider that supports Kerberos is Active Directory. However this authentication provider does not support obtaining a Kerberos token for a user based on name only and the Sharepoint SSO mechanism does not pass the Kerberos token down. MSSQL requires either a username and password or a Kerberos token. Since neither one is available, user pass-through to MSSQL is not possible. Microsoft Sharepoint -> IBM Cognos 8 -> MSAS/SSAS : NO Sharepoint uses IIS for authentication which implies integrated Windows authentication, also known as Kerberos. SSO from Sharepoint to IBM Cognos 8 is only based on Shared Secret (proprietary IBM Cognos technique), which is essentially REMOTE_USER containing just a username. The only authentication provider supporting Kerberos is Active Directory. However, this authentication provider does not support obtaining a Kerberos token for a user based on name only and the Sarepoint SSO mechanism will not pass the Kerberos token down. SSAS requires a Kerberos token which is not available and hence user pass-through to SSAS is impossible. IBM WebSphere Portal (WPS) -> IBM Cognos 8 -> DB2 : YES, if SSO from WPS to IBM Cognos 8 is based on REMOTE_USER, which ultimately means a username only. The recent DB2 concept of Trusted Context allows for user pass-through based on a single username. If in this scenario the WPS username is a valid DB2 user name this can work. Until a specific document exists, please contact the Proven Practices team for details. SAP Portal -> IBM Cognos 8 -> SAP BW : YES, with SAP namespace SAP BW requires an SAP SSOv2 token or a username and password. SSO from SAP Portal to IBM Cognos 8 can be based on an SAP SSOv2 token only. If IBM Cognos 8 is secured with an SAP namespace, that authentication provider can take this token and pass it to the data access layer for authentication to SAP BW. It is not possible to use any other namespace. IBM Websphere Portal (WPS) -> IBM Cognos 8 -> SAP BW : NO SAP BW requires an SAP SSOv2 token or a username and password. SSO from WPS to IBM Cognos 8 is ultimately based on REMOTE_USER, which means a username only. This is insufficient for SAP BW access. IBM Websphere Portal -> IBM Cognos 8 -> Oracle : YES Oracle supports opening a connection with a technical user and then switching to the security context of a different user, which is determined only by a username after the fact. Therefore, all scenarios which are based on REMOTE_USER SSO can work.

20 20 Appendix C References Leveraging Oracle Security Features This document describes how to achieve user pass-through authentication based on command blocks for ORACLE databases. SSO to MSAS/SSAS Describes how to set up user pass-through authentication for Microsoft SQL Server and Microsoft Analysis Services. yet to be published, work is in progress SSO to SAP Describes how to set up user pass-through authentication to SAP BW.