Single Sign-on (SSO) is a fairly broad catch-all term that encompasses a number of technologies. Many organizations use Windows Authentication via Active Directory (NTLM) to provide a seamless environment for Windows users. Some organizations use a third party authentication source such as CA Technologies' SiteMinder to ensure all their applications share common security. Other organizations have “rolled their own” authentication infrastructure and have implemented a Custom Authentication Provider in their Cognos environment.
Because of the complexity and variation in providers, there is no one-size-fits all solution for using SSO and CMS. So, what I'll talk about is the things you must consider and plan for when making CMS calls compatible with your SSO infrastructure.
I'm going to
digress from the REST side of things used in the previous blogs and
use a SOAP example, as SSO is generally most challenging on the SOAP
side of things. However, the general considerations for SSO are the
same for both REST and SOAP.
Ensure SSO is configured properly with your Cognos BI.
CMS can't be used to provide an SSO solution if none exists. You should already have SSO working with your Cognos BI server. Special attention should be noted when it comes to using Cognos Portlets in other portals. The Cognos Portlets use a proprietary handshake to provide an SSO experience between the portal provider and Cognos without having to share a common authentication provider, but this configuration cannot be used with CMS or the SDK.
Understand your Security Infrastructure
One thing you must know is how your authentication infrastructure passes tokens for HTTP traffic. In some cases, such as Windows Integrated Authentication, the REMOTE_USER header contains the token. In other cases, it might be passed as a cookie or as a parameter on a URL. To integrate SSO into any CMS applications simply means to ensure that any special HTTP headers or cookies that your provider requires are forwarded in all messages.
To illustrate let's look at Windows SSO using NTLM, which is a fairly common configuration. Here's an example of what a typical Windows SSO environment might look like
Windows SSO environments can be one of the easiest to work with if you are using .NET or REST. As long as your .NET application is set to send OS credentials via the webservice, no other steps are required for a CMS application developer. For the REST user in a browser based application, it's even simpler as the browser handles NTLM for you.
Working with Windows SSO and Java Axis is more complicated. One technique to support NTLM and Axis is to actually change the underlying transport mechanism that Axis uses, which is what I'll demonstrate here.
The Java 6 JVM has full support for NTLM with it's Authenticator API and Java.net.URL class. We'll create a new Authenticator class and use it to perform NTLM negotiation through the IIS web gateway. Note that a Windows credential simply requires a username (in the format DOMAIN\username) and password, which means we can use the default PasswordAuthentication class.
Now that we have an authenticator, we use it to send our SOAP message to the server. Axis uses a class called HTTPSender to send SOAP messages to the server. We'll create a new subclass that uses our own implementation so that we can apply our authenticator. Note that we only send userID and password to the server if they are not NULL. In the case of a Java client running on a Windows machine in the proper domain, the Java runtime will automatically handle the NTLM negotiation with the server without requiring the username and password to be provided. However, if the client is running outside of the domain, or on a UNIX platform it will be necessary to pass the username and password to the CMS application.
The next step, we need to tell Axis to use our implementation instead of the default. We do this by creating an Axis Engine configuration document which sets our class to be used for sending HTTP messages.
Finally, we need to make a minor change to the service initialization in our CMS application:
As you can see, the steps involved were non-trivial, however this turns out to be one of the most complicated scenarios commonly faced. Your SSO scenario will most likely fall between the two extremes of NTLM in a browser and NTLM and Axis.