IBM Cognos Proven Practices: Adding Single Sign-On to your IBM Cognos 8 Custom Java AuthenticationProviderPage 2 of 16
The code examples in this document were developed and tested using IBM Cognos8.4.1. While the author cannot guarantee that the code examples will work withoutadjustment he's not aware of any other technical prerequisites than recompile the(adjusted) source code of the JDBCSample with a proper JRE version to make thecode work in other versions of the product.
Exclusions and Exceptions
The document will not cover designing and coding Custom Java AuthenticationProviders (CJAP) in general. The only aspect covered herein will be adding supportfor Single Sign-on (SSO) to a full authentication provider.The use of the example code (JDBCSample) requires that the IBM Cognos 8 SDK isinstalled and licensed.It is expected that the reader is familiar with the CJAP SDK and Java programming.
Authentication in IBM Cognos 8
This chapter is going to provide a comprehensive description of the concepts andcomponents involved with the authentication process in IBM Cognos 8.
Requests and Sessions
Users (browsers) or code (an SDK application) send requests to IBM Cognos 8 byestablishing a HTTP session with a Cognos entry point (EP). Valid entry points areeither an IBM Cognos 8 Dispatcher accessed directly or, adhering to best practices,an IBM Cognos 8 Gateway deployed to a web server.Since IBM Cognos 8 is based on a
service oriented architecture
(SOA) the overallfunctionality provided by the Cognos system is implemented by a set of independentservices communicating externally and amongst each others using the SOAPprotocol. For this reason each request sent to an IBM Cognos 8 entry point will haveto be routed to some target service which can handle it. Each of the services makingup IBM Cognos 8 handles different types of requests and routing is one of the mainconcepts of the IBM Cognos 8 architecture.Routing is handled by the IBM Cognos 8 Dispatcher Service. Regardless whether arequest was sent to a Dispatcher directly or via a Gateway (each Gateway will relayit's request to a single Dispatcher denoted in it's configuration), it will be handledby an instance of Dispatcher Service on the accessed Dispatcher. The DispatcherService will create a new
if this is the first request received in that veryHTTP session. Next a
will be assigned to the request and both
are added to the request. All subsequent requests in the same HTTPsession can be identified now because they share the same
.As services are logically independent from each other practically all of them willrequire authentication before they will handle a request to prevent unintended