Complex SSO Requirement



Hi there,

We have configured SSO properly on Canvas, but Canvas would somehow trigger a redirect which has a conflict of the customer’s redirecting behaviour from their environment, as a result, we need to use the complicated method to do the SSO, that is using the below URL:

And users were expecting it would do SSO accordingly and then go to, however, it actually goes to instead, we have multiple pages created under this application, each made for different purpose and for different user groups, so we cannot squeeze everything into home.html and then use either the replacing home.html technique or the $state.go technique to redirect it back to the desired page.

What other options do we have?

Thanks in advance



Hi @twong,

I might have seen it before, but just to check, what happens if you go to the following URL:

Also, what is the clientCAMURI value on your instances.json? Do they have the same Cognos Server name (, and sso path used (cognosisapi.dll vs cognos.cgi)?

How about your ssoSlaves property in header.script.init.ftl file? They should all have the same port and machine name.



Hi Paul,

If I am doing it on a normal browser environment, the URL works, but as soon as I add in front, it does not work anymore, according to our last discussion, the SSO redirects back to the page that has triggered the unauthorised access, and therefore home.html, however, the URL we are passing in should be the dashboard, so far I don’t have any idea how to get around this.

the clientCAMURI are the same, all lower case, FQDN and using cognosisapi.dll.




Hi @twong,

If the URL ( works already (meaning SSO is working from the background, user gets authenticated and page redirects back to the same URL), why is there a need again to put in front?

As for the long URL that you have posted, that seems to be because Cognos is stripping all other parts of the URL as it only need and authenticates it against the base URLs as defined on the variables_TM1.xml. It was not because Canvas was redirecting to the home page, but rather it was because the redirect URL returned by Cognos BI is just and not



Hi @plim,

As that environment has a conflict of redirect and therefore authentication didn’t happen if using the normal Canvas URL, it would always stuck on the page for logging in but nothing happening (in the face of the user).

Using this long URL would trigger the authentication properly, at least for TM1Web, it works ok.

Can I assume if I update variables_TM1.xml it would work?




Hi @twong,

That will really depend on how Cognos BI works. The main thing to look for is how to make it return a URL like:

Instead of,

Tests from going through the URL in browser gave me this:

http://< canvas server > /< canvas app >/?cam_passport=XXXXX&CAMNamespace=CCCCCC

That is, after passing in a URL with c_cmd value as http://< canvas server > /< canvas app >/#/configuration. And as noted, it strips down the #/configuration part, and just replaces it with ?cam_passport and CAMNamespace parameter/value.

So if there is a simple setting or flag maybe in Cognos BI that allows redirect with the full URL passed, then that should help on this.

Then on using Canvas’ SSO mechanism, the returned response by Cognos BI should have in its HTML response / body, details about the CAMPassport. There should be visible information in there about:

  • cam_passport
  • CAMNamespace

You can check this out by opening the Developer Console of Chrome for example and clicking on the request to Cognos. It will look something like:

From there, it should be able to give you more information as to what the error is (if there is any, such as Forward URL is Invalid, etc.).