PingFederate SSO not working when accessing dynamic URL of any page in Jira

[Kirankumar Talapaneni]

1. We have integrated Jira with PingFederate SSO. When the user is trying to access a specific page (eg: Filter), the user is treated as anonymous user and asked to log in(Unless the user is already logged in to Jira with the original URL).
2. Is it possible to redirect a user to any page in Jira just by clicking on the url of that specific page? Please advise. 
   Thanks in advance

[Kirankumar Talapaneni]

Hi Chris,

Now its working for me. These are the changes that I have made :

1. Added this code under services tag of seraph-config.xml file

<service class="com.atlassian.seraph.service.PathService">
    <init-param>
        <param-name>config.file</param-name>
        <param-value>/seraph-paths.xml</param-value>
    </init-param>
</service>

     2. Then, I have created a file seraph-paths.xml and added this code in that

 <path name="user">
		 <url-pattern>/*</url-pattern>
		 <role-name>user</role-name>
 </path>

Thanks & Regards,

Kiran

[Chris Solgat]

Very good. I didn't think to look for the service class under the seraph-config. Just to let you know, because we have experienced it, setting your seraph-config file as you did, will cause it to check for the user's login credentials on every single page. If you have a busy installation of Jira, you may notice significant performance issues. Our Enterprise instance is very busy, with an average of over 800 user sessions during business hours. It also has over 400,000 issues, over 300 projects, and 1600 custom fields. We have tried configuring our seraph-paths.xml file two different ways - First, <security-paths> <path name="admin"> <url-pattern>/secure/admin/*</url-pattern> <role-name>admin</role-name> </path> </security-paths> This setting will only trigger the redirect on pages that require a login (no anonymous access). Second, <security-paths> <path name="admin"> <url-pattern>/secure/admin/*</url-pattern> <role-name>admin</role-name> </path> <path name="user"> <url-pattern>/secure/*</url-pattern> <role-name>user</role-name> </path> </security-paths> This is closer to the configuration that you have set. Since we are setup behind a proxy, using https and ssl, this triggers on almost every page. Just some information and different options to consider. I'm happy to hear that you were able to get it working.

[Chris Solgat]

Yes, there should be some changes made to the seraph-config.xml file that will control most of this.  You can also add an additional entry in the seraph-paths.xml, but I wouldn't recommend that until your seraph-config.xml file is setup correctly.  

Under the <param-name>login.url</param-name> and also under <param-name>link.login.url</param-name> you need to comment out the original <param-value> and add a new <param-value>{Put your PingFederateServerURL here}/pf/adapter2adapter.ping?IdpAdapterId=CompositeHTMLIWA&amp;SpSessionAuthnAdapterId={JIRA Ref ID}&amp;TargetResource=${originalurl}</param-value>

The adapter2adapter.ping value will be different depending on which type of connector you are using.  Also, you're SpSessionAuthnAdapterId will be needed.  This is the Reference ID that was put into the Ping Server Configuration for Jira.

[Kirankumar Talapaneni]

Hi Chris, First of all, I thank you for responding to my question. I don't see a file seraph-paths.xml under /atlassian-jira/Web-Inf/classes/ directory. We have made all the changes that you mentioned in seraph-config.xml file as shown below. I don't see any adapter2adapter.ping in the following : <param-value>https://xxxxxxx.com/sp/startSSO.ping?PartnerIdpId=JIRAtest:IdP&amp;SpSessionAuthnAdapterId=JIRASPAccess&amp;TARGET=${originalurl}</param-value>

[Chris Solgat]

A few questions; Which version of Jira are you using? Have you configured your PingFederateAuthenticator.xml file? If you have configured your PingFederateAuthenticator.xml, did you replace the authenticator class to use the PingFederateAuthenticator? Ours looks like this - <!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration --> <!--<authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/>--> <authenticator class="com.pingidentity.clientservices.sso.jira.PingFederateAuthenticator"/> <!-- CROWD:END --> This is farther down in the seraph-config.xml file. Also in the seraph-config.xml file, you need to beware of the interceptor class. At least for 6.1.X and 6.3.X, they are different. If you copied the interceptor class from somewhere else, that will cause problems as well. The fact that you say you don't see a seraph-paths.xml file makes me worry that you are on a much older version. I have configured Ping Federate to work with both Jira 6.1.6 and Jira 6.3.X. Seraph-paths.xml is present in both of those versions. Adapter2adapter.ping was a different type of connector that we needed to use because of some network configurations that we have at our company. You are probably not using adapter2adapter.

[Kirankumar Talapaneni]

We are using Jira 6.1.5. We have configured PingFederateAuthenticator.xml. We have added this authenticator class in seraph-config.xml <authenticator class="com.pingidentity.clientservices.sso.jira.PingFederateAuthenticator"/>

[Kirankumar Talapaneni]

This is the interceptor that I can see in seraph-config.xml file. Do I need to any ? <interceptors> <interceptor class="com.atlassian.jira.web.filters.JiraLoginInterceptor" /> </interceptors>

[Chris Solgat]

I don't know if this interceptor will cause you problems or not. This is the interceptor that is used in Jira 6.3.X. This is the interceptor that is present in my 6.1.6 - <interceptors> <interceptor class="com.atlassian.jira.user.preferences.UserPreferencesResetInterceptor"/> </interceptors> I do know that this interceptor will cause problems in a 6.3.X environment, but not sure if the 6.3 interceptor will cause problems in a 6.1 environment. Honestly, if it's working, don't change it. If it's not, you could try changing it.

[Elizabeth]

Right, AppFusions has seen this issue before in the field and fixed this in our Kerberos, SAML2, or Google SSO authenticators if you'd like to try some alternatives. In short, I believe it needs to be fixed at the application (plugin) side.. email info@appfusions.com if want to try out..