Jasig CAS client and JIRA not working

warthog January 20, 2013

I was trying to get this setup iusing souldwing but then reading that its no longer being developed I moved to Jasig CAS client (https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1).

Problem is i cannot get it to work, i've followed instructions on the above but after starting service it will not connect to my JIRA instance. Just get page cannot be found. I remove the CAS stuff ad it works fine.

I'm of course doing something worng maybe i have this in the worng format or am following worng instructions, any help is appreciated

JIRA 5.2.5


9 answers

1 accepted

4 votes
Answer accepted
Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 31, 2013

We have fully working installation of JIRA 5.2 with CAS authentification. I have attached diff file containing configuration changes and requires jars - apply it to your jira installation directory - it is git based patch, so this answer should apply.

Of course don't forget to change https://sso.mycompany.com with URL of your CAS server.

Update: attachment went to the hell - so here it is as GIST

Long Nguyen October 23, 2013

Hi Jozef,

We're currently running JIRA 5.2.7 with CAS authentication and planing to upgrade to JIRA 6.1.1. Are there any issues if we use the CAS authentication for 5.2.7? THANKS!

0 votes
Paul Hirose May 7, 2014

In case anyone stumbles into this thread at this point...

This seems to work for Jira 6.2.4, as of 2014-05-08.

Following the basic instructions in https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1but changing, as per this thread the following

- Jira44CasAuthenticator

- jira.admin.gadget.task.list.enabled : set sysadmin-editable to true

The bit about WebworkPluginSecurityService renaming doesn't seem to be necessary, that's already that way in my file as distributed from Atlassian.

This is all in Jozef's patch, although the line numbers are a bit off, possibly because of the version of Jira of course. His patch references line 247 for jpm.xml, but that doesn't appear to be the actual line. His patch also shows the property after the patch as jira.disable.multipart.get.http.request, therefore I am assuming the property that should be changed is jira.admin.gadget.task.list.enabled (which is right above the jira.disable.multipart... property in this version of jpm.xml).

I did not use cas-client-core-3.3-SNAPSHOT.jar, and thus did not apply the binary patch Jozef provided. Instead I grabbed the 3.3.1 of both client-core and client-integration-atlassian, from http://maven-repository.com/artifact/org.jasig.cas.client. In my case, I pulled the built jar file dated 2014-03-20, presumably anyone who finds this thread in the future can grab a newer build (or maybe the officially released stable version by then.) I don't know what that binary patch to the JAR file does, so if Jozef is still here, and can chime in, that'd be appreciated. I've no idea if his alterations might have made it into the JASIG git or not.

PH


Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 9, 2014

Hi, thanks for update. I wasn't aware that 3.3 libraries are finally out.

The patch contains plain copies of CAS libraries (3.3-SNAPSHOT).

We are managing Atlassian applications in form of patches (Mercurial Queues). This method handles well changes in line numbers. I can upgrade automatically installation of JIRA with 30 patched files in 5 minutes.

Tie Li December 16, 2014

how to do this : ira.admin.gadget.task.list.enabled : set sysadmin-editable to true

Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 16, 2014

you have to edit atlassian-jira/WEB-INF/classes/jpm.xml

Tie Li December 17, 2014

jira 6.3.3 Following the basic instructions in https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1 now , it can farword me to the sso login page,. input my username and password, redirect to the jira loginpage "http://XX.XXX.XXX.XXX:8080/secure/Dashboard.jspa"; . i check the jiralog ,there is't any error log i download cas-client-core-3.3.jar and client-integration-atlassian-3.3.3.jar from maven repo. use - Jira44CasAuthenticator and set jira.admin.gadget.task.list.enabled follow @Jozef Kotlár who can tell me why ? and how to debug it?

0 votes
Alberto Larripa Azcona October 1, 2013

Hi all, just installed JIRA606 and I need integrate the authentication with CAS 3.5.1. I followed the official documentation but without disabled the default JIRA authentication (JiraSeraphAuthenticator), if disable it the startup process failed (cas_error.txt).

A result of this error, I tried to maintain the Seraph enabled with the atlassianCasClient and the CAS authentication WORKS!!!, but when I logon the JiraSeraphAuthenticator authentication reorders.

This is my JIRA6 (jira_cas_foro.txt) .

Thanks for all

CAS INTEGRATION:
https://wiki.jasig.org/display/CASC/Configuring+Jira+with+JASIG+CAS+Client+for+Java+3.1

cp -pr cas-client-integration-atlassian-3.2.1.jar /usr/local/etc2/jira606/atlassian-jira/WEB-INF/lib/
cp -pr cas-client-core-3.2.1.jar /usr/local/etc2/jira606/atlassian-jira/WEB-INF/lib/

Habilitamos la configuración por CAS, comentando la configuración activa por default

$JIRA_HOME/WEB-INF/classes/seraph-config.xml

    <!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration -->
    <authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/>
    <!-- CROWD:END -->

    <!-- CAS:START - Java Client Jira Authenticator -->
        <authenticator class="org.jasig.cas.client.integration.atlassian.JiraCasAuthenticator"/>
    <!-- CAS:END -->

Redirigimos el Sign Out de JIRA al Sign Out de CAS

$JIRA_HOME/WEB-INF/classes/seraph-config.xml

        <init-param>
            <!--
              The login URL to redirect to when the user tries to access a protected resource (rather than clicking on
              an explicit login link). Most of the time, this will be the same value as 'link.login.url'.
                - if the URL is absolute (contains '://'), then redirect that URL (for SSO applications)
                - else the context path will be prepended to this URL

                If '${originalurl}' is present in the URL, it will be replaced with the URL that the user requested.
                This gives SSO login pages the chance to redirect to the original page
            -->
            <param-name>login.url</param-name>
            <!--<param-value>/login.jsp?permissionViolation=true&os_destination=${originalurl}</param-value>-->
            <param-value>https://mycassrv.domain.es/cas/login?service=${originalurl}</param-value>
        </init-param>
        <init-param>
            <!--
              the URL to redirect to when the user explicitly clicks on a login link (rather than being redirected after
              trying to access a protected resource). Most of the time, this will be the same value as 'login.url'.
                - same properties as login.url above
            -->
            <param-name>link.login.url</param-name>
            <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
            <!--<param-value>/secure/Dashboard.jspa?os_destination=${originalurl}</param-value>-->
            <!--<param-value>http://sso.mycompany.com/login?redirectTo=${originalurl}</param-value>-->
            <param-value>https://mycassrv.domain.es/cas/login?service=${originalurl}</param-value>
        </init-param>
        <init-param>
            <!-- URL for logging out.
                 - If relative, Seraph just redirects to this URL, which is responsible for calling Authenticator.logout().
                 - If absolute (eg. SSO applications), Seraph calls Authenticator.logout() and redirects to the URL
                 -->
            <param-name>logout.url</param-name>
            <!--<param-value>/secure/Logout!default.jspa</param-value>-->
            <!--<param-value>http://sso.mycompany.com/logout</param-value>-->
            <param-value>https://mycassrv.domain.es/cas/logout</param-value>
        </init-param>

Add the Single Sign Out listener to the list of listener list too

$JIRA_HOME/WEB-INF/web.xml

    <!-- CAS:START - Java Client Single Sign Out Listener -->
    <listener>
        <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
    </listener>
    <!-- CAS:END -->

$JIRA_HOME/WEB-INF/web.xml

Add before the filter-mapping entries:

    <!-- CAS:START - Java Client Filter Mappings -->
    <filter-mapping>
        <filter-name>CasSingleSignOutFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <filter-mapping>
       <filter-name>CasAuthenticationFilter</filter-name>
       <url-pattern>/login.jsp</url-pattern>
    </filter-mapping>
    <filter-mapping>
       <filter-name>CasValidationFilter</filter-name>
       <url-pattern>/*</url-pattern>
    </filter-mapping>
    <!-- CAS:END -->

$JIRA_HOME/WEB-INF/web.xml

<!-- CAS:START - Java Client Filters -->
<filter>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter>
  <filter-name>CasAuthenticationFilter</filter-name>
  <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerLoginUrl</param-name>
    <param-value>https://mycassrv.domain.es/cas/login</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>https://mycassrv.domain.es/jira/</param-value>
  </init-param>
</filter>
<filter>
    <filter-name>CasValidationFilter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
        <param-name>casServerUrlPrefix</param-name>
        <param-value>https://mycassrv.domain.es/cas</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
        <param-value>https://mycassrv.domain.es/jira/</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<!--- CAS:END -->
    <!-- =====================================================
         FILTER MAPPINGS FOLLOW :
         ===================================================== -->

Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 3, 2013

Reread again the answers - at least the my answer above. IN short - CAS libraries are too old to support JIRA 6

Alberto Larripa Azcona October 3, 2013

Ok, thanks Jozef,

I tried to apply the path but failed with:

[root@jirasrv jira606]# git apply gistfile1.diff 
gistfile1.diff:55: trailing whitespace.
    <authenticator class="org.jasig.cas.client.integration.atlassian.Jira44CasAuthenticator"/> 
error: patch failed: atlassian-jira/WEB-INF/classes/jpm.xml:246
error: atlassian-jira/WEB-INF/classes/jpm.xml: patch does not apply
error: patch failed: atlassian-jira/WEB-INF/classes/seraph-config.xml:11
error: atlassian-jira/WEB-INF/classes/seraph-config.xml: patch does not apply
error: patch failed: atlassian-jira/WEB-INF/web.xml:351
error: atlassian-jira/WEB-INF/web.xml: patch does not apply

Alberto Larripa Azcona October 3, 2013

Thanks Jozef, the patch for the jar files works perfectly!!!

Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 3, 2013

There are some incompatibilities with whitespaces - you should tweak it a bit (as HML-Proactum above did). Not sure what I did wrong when exporting the patch.

Actually I am using Mercurial Queue for patches in JIRA installation - the patch originates from this tool.

0 votes
Max Spankie May 30, 2013

We got it working with Jira 6 as well using the lastest java cas jar files (3.3) from the github repository. We imported the lastest code into Eclipse and then used Maven to build the jars.

Plus be sure to use the following authenticator instead of the one in the guides:

<authenticator class="org.jasig.cas.client.integration.atlassian.Jira44CasAuthenticator"/>

0 votes
evaldas April 21, 2013

Hi all, just for the information, JIRA 6-ml10 works too.

0 votes
Hannu Lohtander February 4, 2013

Got it working with the patch, so thanks! You saved me, really, from going nuts. Had to tweak patch a bit, few white spaces are not same in the patch as they are in the standalone 5.2.0 or 5.2.5 that I tested. Used git apply ..., not patch -p1 < ....

Raised a bit more questions too. You must have different version or some build variables, because only thing different could have been cas- -jars. I also had some mystical problems which dissapeared with clean new test install.

So 5.2.5 works, with the patch.

0 votes
Hannu Lohtander January 31, 2013

I was a bit mislead by the instructions given by JASIG JIRA 3.1 installation. I had the wrong authenticator, one should use 44Cas version. I suppose. I mean this part:

&lt;authenticator class="org.jasig.cas.client.integration.atlassian.Jira44CasAuthenticator"/&gt;

I do not get it working though. I removed:

&lt;service class="com.atlassian.seraph.service.WebworkService"&gt;
            &lt;init-param&gt;
                &lt;param-name&gt;action.extension&lt;/param-name&gt;
                &lt;param-value&gt;jspa&lt;/param-value&gt;
            &lt;/init-param&gt;
        &lt;/service&gt;

        &lt;service class="com.atlassian.jira.plugin.webwork.WebworkPluginSecurityService"&gt;
            &lt;init-param&gt;
                &lt;param-name&gt;action.extension&lt;/param-name&gt;
                &lt;param-value&gt;jspa&lt;/param-value&gt;
            &lt;/init-param&gt;
        &lt;/service&gt;

from seraph-config.xml and the JIRA starts now.

But does not seem to do any queries to cas server. And I am using 3.3 from the trunk.

Too much confusion here - I just end up testing blindly everything. I have no idea what the actual problem is - is it changes within JIRA or something to do with CAS 3.3.

Daniele Gagliardi March 27, 2013

Hi, I've resolved this issue with Jira 5.2.8: you need to modify a class name, from com.atlassian.jira.plugin.webwork.WebworkPluginSecurityService to com.atlassian.jira.plugin.webwork.JiraSeraphSecurityService in your seraph-config.xml.

0 votes
warthog January 31, 2013

Unfortunately the JIRA support is limited with this as it is not their product,

This is what i got from support:

"Hello,

Thank you for contacting Atlassian support. I'm afraid that CAS integration falls out of the scope of this support channel as it is a third-party system. More information can be found in this article.

The only SSO solution supported by Atlassian is Crowd application. However, after a research at answers.atlassian.com (which is our community network) I found this question that contains some links and clarifications about CAS integration.

Additionally, we were informed by one of our customer that there is a bug in CAS 3.2.1 that can prevent JIRA to pick the <tt>netid</tt> information. This is suppose to be fixed in CAS 3.3. You may need to modify your CAS module to apply this update.

So i guess for now i'm stuck with no CAS integration until 3.3 is released.

0 votes
Hannu Lohtander January 31, 2013

I have the same problem.

if you look at the logs, catalina.out, you may see this item:

2013-02-01 09:47:45,532 Spring executor 4 ERROR [plugin.osgi.factory.OsgiPlugin] Unable to start the Spring context for plugin com.atlassian.sal.jira
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationController' defined in URL [bundle://84.0:0/META-INF/spring/atlassian-plugins-components.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.atlassian.sal.core.auth.SeraphAuthenticationController]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: com/opensymphony/user/EntityNotFoundException

That is all debug I get from this issue.

Well... I have tried to understand this for few days. No luck. I assume, that default 5.2.5 installation has something configured that tries to use default authenticator class. I am not sure. This also happens with 5.0.7.

I have used released cas libraries and the ones I build from the git trunk. No success.

This is sort of an dead end. I will probably end up creating a ticket for this.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 31, 2013

You definitely need to raise this with the authors.

One thing that sticks out to me in the logs - com/opensymphony/user. Jira has NOT used that since 4.2, so my instincts are screaming that you're using a plugin that is for 4.2 or lower.

It may be that the plugin does things with opensymphony internally, but I'm not familiar with it, so I'm guessing.

Suggest an answer

Log in or Sign up to answer