Clarity

[color=#2c7031]

[color][center][size=7]Upgrading to Clarity 13 from 12.x or earlier with SSO (Single Sign On)[size] [center]



[size=5]In Clarity V13+ development enhanced the product by changing the functionality so that when you make changes on a page only part of the page needs to be refreshed instead of the whole page like previous versions of Clarity. You will notice that there is now a # sign in the url. This is what allows Clarity to redraw/reload part of the page instead of the whole page unlike earlier versions of Clarity. This change will affect SSO users unless a change is made to their Clarity configuration so that Clarity can send a string that the SSO server can parse.

NOTE: SiteMinder is still the only SSO software integration with Clarity that is supported per the Compatibilities section in the Clarity release notes.

When you are using SSO with email notifications or Export to Exel (when it creates Clarity links), Clarity must pass a string to the SSO server that tells that SSO server where to redirect the user. However, when the SiteMinder server sees the Clarity URL with the # sign in it, it correctly ignores any information after the # sign. Our development team has added configuration options to Clarity V13 that will help you get around this problem. They have added an external entry url option that can be used to replace the portion of the URL that SiteMinder (as well as other SSO programs) can’t read with something that it will be able to read. It changes the url that will be used for email and Export to Excel to the old style of Url that was used pre-V13 which Clarity can still parse correctly.

If you were able to use the standard entry url in the NSA in V12.x or earlier and your email and excel links worked correctly this configuration change should work for you. (In other words, you did not have to write a script or use an external entryurl to make your email and Excel links work.)

Here are the instructions for how to make this configuration change after your upgrade to V13

Add the following parameter to your properties.xml in the ApplicationServer section:

[color=#2c7031]externalUrl="replace(/niku/nu#action:,/niku/app?action=,${entryurl})"[color]

So if your application server section looks like this:

[color=#2c7031]<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.25" adminPassword="admin">[color]

or like this:

[color=#2c7031]<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.25" adminPassword="admin" externalUrl="">[color]

you would change it to something like this:

[color=#2c7031]<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.25" adminPassword="admin" externalUrl="replace(/niku/nu#action:,/niku/app?action=,${entryurl})">[color]

If you have multiple servers in a cluster, you will need to modify the properties.xml on each server.

Once you have completed these changes, run the following command from the command prompt on any one of your Clarity servers to upload the changes you made to the Clarity database:

[color=#2c7031]admin general upload-config -info[color]

Once you have done this, you will need to restart your app and bg services in order for the change to take effect.

For further information, see the section on External Entryurls in the Installation guide for your version of Clarity (V13 or above)[size]

Thanks for sharing this, Jeanne !!! :happy

NJ

Thanks for the tip Jeanne! :grin:

Thanks Jeanne. Really usefull tips!!

Hi Jeanne !
Is there any information on ahieving SSO in Clarity v13 using apache server (httpd)?

I mean there is no site-minder at the site.

Thanks and regards,

 

Mayank

Hi Mayank,

The only SSO software that is certified to work with Clarity is SiteMinder.  That being said, we do have a number of customers who have been able to make Clarity work with other SSO software including home-grown SSO software.  It looks like SSO with Apache Tomcat may not be the most configurable SSO software you can find.  You will have to make sure it has all of the capabilities needed to make SSO work with Clarity.  If you want to go this route, look at the CA Clarity PPM r13 Integrating with CA SiteMinder green book:

https://catechnologies.webex.com/sc0801l/supportcenter/scapi.do?needFilter=false&siteurl=catechnologies&RID=0&CONFERENCEID=1488713829&AT=JS&I=748082473

You will need to set up the equivalent of everything that is described here in your SSO software and then configure Clarity accordingly.  Because you are setting up something that is not certified to work with Clarity, support will not be able to assist you with this.  However, you can engage services to help you, if needed.

Finally, make sure you set up a non-sso instance of Clarity so that you can verify whether or not a problem occurs without your SSO software or not.  (FYI, I also suggest that customers who use SiteMinder do this as will since the non-SSO instance can be very useful for trouble-shooting purposes.)  Clarity support will provide best effort support for any problems that you may have that we think involve SSO.  If we can reproduce the problem under SiteMinder/Clarity or if you can reproduce the problem on your non-sso system, we will be able to help you.  However, if the problem is only reproducible with your SSO software in place, we will have to point you to your SSO software developers or technical support team for assistance with resolving your problem.

I hope this helps point you in the right direction.

 

Sincerely yours,

Jeanne Gaskill
Senior Support Engineer - Clarity
CA Technologies Inc.

 

 

Hi Jeanne,

We are willing to use Ping Federate with V13.3 for SSO.

Do you have any best practices for this?, in terms of infrastructure setup and other components.

 

Thanks,

Manish

Hello Jeanne,

We have implemented SSO using Apache in our environment. Everything works fine except for the following scenario:

We have set the session timeout to 60 minutes and ideally when this limit is reached, user should be logged out of Clarity and redirected to sso-logout.jsp. After this limit is reached if the user doesn't close the browser and clicks on any of the link in Clarity, instead of logging out the user, it goes to an infinite loop; meaning sso.jsp gets called in a loop and this causes infinite sessions getting created in Clarity. The impact is that Clarity's performance decreases everytime this happens.

Do you know what might be causing that?