Single Sign On in Complex Network Environments

From a network configuration perspective SharePoint and Cognos solutions can be complex as both each of SharePoint and Cognos can consist of multiple servers, a mix of http and https, firewalls, load-banacing (software and hardware).
QueryVision provides the following advanced techniques for these environments:

Managing URL re-writes in the Single Sign On workflow
Multiple SharePoint Apps sharing a Cognos Server – each with different URL re-writes

For an understanding of the SSO workflow and it’s components, it is suggested to visit Single Sign On In Depth/Single Sign On Workflow

Contents

1 Managing the receiving URL for SSO credentials
2 Multiple SharePoint Apps sharing a Cognos Server
- 2.1 For SSO DYNAMIC
- 2.2 For other SSO Modes

Managing the receiving URL for SSO credentials

Problem: QueryVision SSO workflow is not redirecting back to the expected SharePoint web page URL on completion. The base URL visible to the user in their browser is an internal URL not the user/public URL.

The SSO workflow between SharePoint and Cognos consists of a number of redirects from the user’s browser from the SharePoint (web) page that contains the QueryVision SSO Authentication Web Part to Cognos for authentication and then returning to the SharePoint page to allow the SSO web part to accept the Cognos authentication token (in IBM Cognos terms, a “passport”).

The SSO web part initiates the redirection workflow by first obtaining the SharePoint web page URL (the “endpoint URL”). This is then passed through the “redirection chain” (along with other paramters) which will, as a final step, redirect back to the originating Sharepoint page (the “endpoint URL”).

The source of the problem is as follows:

The “public” URL (the one the user uses to access the SharePoint site and sees as they navigate pages on the SharePoint site), is not necessarily the one used internally by SharePoint itself. In addition, load balancers, the use of SharePoint Alternate Access Maps (AAM), DNS and IIS settings can all be used to “re-write” URLs as a user request flows through to the SharePoint web site and back to the user.
When the SSO Web Part requests the URL from the SharePoint web page (via the SharePoint APIs), it is returning the “internal” URL for the page, and without mapping the internal URL to the public URL, the SSO workflow will return to the “internal” URL for the SharePoint Web Page that contains SSO Web Part.

This can be resolved by leveraging the URL substitution/mapping feature within the QueryVision SSO component ssondrd.jsp.

To use the substitution/mapping feature requires editing the ssonrd.jsp file. As shipped, this feature is disabled through comments:

The code specifies a simple 2 dimension array consisting of pairs of strings. The format is that of a Java array:

in_to_out_URI = new String[][]{
{“<string to replace>”, “<replacement string>”},
{“<string to replace>”, “<replacement string>”},
{“<string to replace>”, “<replacement string>”}
};

Note that each pair is separated by a comma.

Some examples:

{“http:”, “https:”}

This will re-write URLs from http:// to https://

{“https://pos.validation.spfarm.intra.com:9653”, “https://pos.validation.spfarm.intra.com”}

This will re-write from the internal base url “https://…com:9653” to the public base url “https://…com”

The substitution will take place only if there is a match on the first string of a pair. Otherwise the URL will not be modified.

The following shows what the “Active” code should look like (which lines to uncomment):

Save the updated ssonrd.jsp file and copy this file to the following location on your Cognos Server:
<Cognos Install Directory\…\webapps\p2pd>

Multiple SharePoint Apps sharing a Cognos Server

Where different SharePoint/Cognos configurations require different URL re-writes for each SharePoint application – in the ssonrd.jsp/.htm file (see above) – then for QueryVision SSO to work from Sharepoint to Cognos, a separate set of files must be installed on the IBM Cognos server for each SharePoint.

Problem:

QueryVision web parts are deployed to multiple SharePoint sites accessing a common IBM Cognos. Each QueryVision deployment may have different ssonrd.jsp configuration requirements due to different URL mapping or versions of SharePoint and/or QueryVision.

The solution is to create independent sets of the QueryVision SSO files, including ssonrd.jsp, on the Cognos server.

There are two scenarios:

For SSO Dynamic mode
For all other SSO modes, except SSO Dynamic

For SSO DYNAMIC

There are 4 files involved for each SharePoint site configured to use the QueryVision Web Part Solution

QvtConfig.xml
qvtSSODynamic.html
QvtSsoParams.xml
ssonrd.jsp

For each “set” copy and rename the files qvtSSODynamic.html, QvtSsoParams.xml and ssonrd.jsp. For example:

qvtSSoDynamic_2.html
QvtSsoParams_2.xml
ssonrd_2.jsp

Now make the following changes in each of the files to update the file name references (e.g. qvtSSODynamic.html -> qvtSSODynamic_1.html)

QvtConfig.xml

For the Cognos Server you are accessing in its <CrnServer> section locate the following:

Rename qvtSSODynamic.html to qvtSSODynamic_2.html

qvtSSODynamic_2.html

Locate the following code:

Rename QvtSsoParams.xml to QvtSsoParams_2.xml

QvtSsoParams_2.xml

Rename ssonrd.jsp to ssonrd_2.jsp

And finally, place the updated qvtSSODynamic_2.html, QvtSsoParams_2.xml and ssonrd_2.jsp in the same folders as the originals on the Cognos server (see Single Signon Setup Instructions).

Repeat these steps (with suitably renamed file names and references) for each additional set of IBM Cognos server files required.

You will need to restart your QueryVision web part solution (e.g. iisreset for the IIS server or restart the QueryVision Web Part solution IIS application pool).

For other SSO Modes

The steps are similar to SSO Dynamic mode, but the change to QvtConfig.xml is different and the need to copy and modify the qvtSSODynamic.html file is not required (it is not used for non-SSO Dynamic modes)

QvtConfig.xml

For the Cognos Server you are accessing in its <CrnServer> section locate the following:

Rename QvtSsoParams.xml to QvtSsoParams_2.xml

QvtSsoParams_2.xml

Same steps as for SSO Dynamic, above

ssonrd_2.jsp

Same steps as for SSO Dynamic, above

And finally, place the updated QvtSsoParams_2.xml and ssonrd_2.jsp in the same folders as the originals (see earlier in this guide for those locations).