CAS for Jira 7

[Andrew Morgan]

I'm trying to configure Jira v7.1.6 to use CAS. I followed the docs at:

https://github.com/apereo/java-cas-client#atlassian-integration

and I used the Jira44CasAuthenticator as documented on the old jasig wiki
page.

However, Jira doesn't seem to be using the CAS login. When I click on
Jira's Log In link in the upper-right corner, I'm successfully
authenticated with CAS (ticket is validated), but CAS never "sees" that
I'm logged in.

I assume this means that something in the way Jira hooks into CAS is
missing...

Does anyone know if the Java CAS Client works with Jira v7?

Thanks,
Andy

[Andrew Morgan]

Does anyone use CAS authentication for Jira? I'm guessing something has
changed between Jira versions. Does Atlassian provide documentation about
plugging in alternate authentication methods? I could provide more
information about our configuration attempt if it would help.

Thanks,
Andy

[Jason Hitt]

We use CAS authentication for JIRA.  Our only problem so far with JIRA 7 is the server-to-server communications.  We get the __MSG_gadget.favourite.filters.title__ gadget titles.  I believe it's because the server self-connections are supposed to bypass authentication and CAS isn't allowing it, but I haven't diagnosed it that far yet (we just started testing the upgrade this week).

If you still need any help getting CAS started on JIRA 7, let me know and i'll be happy to post our config changes.

[Andrew Morgan]

Yes please!

Thank you for responding even though my post is so old. :)

Andy

On Wed, 7 Dec 2016, Jason Hitt wrote:

> We use CAS authentication for JIRA. Our only problem so far with JIRA 7 is
> the server-to-server communications. We get the

> *__MSG_gadget.favourite.filters.title__* gadget titles. I believe it's

> --
> - CAS gitter chatroom: https://gitter.im/apereo/cas
> - CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
> - CAS documentation website: https://apereo.github.io/cas
> - CAS project website: https://github.com/apereo/cas
> ---
> You received this message because you are subscribed to the Google Groups "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/3a9b64f6-cab5-43d0-9f8d-4f735abe153a%40apereo.org.
>

[Jason Hitt]

In seraph-config.xml, the only difference from the Apereo documentation was using Jira44CasAuthenticator instead of JiraCasAuthenticator.

In web.xml, i used config that worked with the Soulwing CAS client in earlier JIRA versions.  We have to add a single sign-out filter, an authentication filter, and a ticket validation filter.  The filters are added just before the JiraLastFilter:

    <!-- CAS Configuration -->
    <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://auth.alterscrap.com/cas/login</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>https://jira-test.alterscrap.com/</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://auth.alterscrap.com/cas</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>https://jira-test.alterscrap.com/</param-value>
        </init-param>
        <init-param>
            <param-name>redirectAfterValidation</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>
    <!-- end CAS Configuration -->

We then have to apply the filters via filter-mappings.  These are inserted just before the login filter-mapping:

    <!-- CAS Configuration -->
    <filter-mapping>
       <filter-name>CasSingleSignOutFilter</filter-name>
       <url-pattern>/*</url-pattern>
    </filter-mapping>
    <filter-mapping>
        <filter-name>CasAuthenticationFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <filter-mapping>
        <filter-name>CasValidationFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <!-- end CAS Configuration -->

Lastly, we need the single sign-out listener.  This gets added at the end of the listener list:

    <!-- CAS Configuration -->
    <listener>
        <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
    </listener>
    <!-- end CAS Configuration -->

That should be it!  As i said, this is VERY preliminary, and we're having problems with the server callbacks failing (and have no errors in the logs), but this should get you started.  I'll post an update if i figure out our remaining issues.

[Jason Hitt]

I've created a pull request for a new Jira7CasAuthenticator at https://github.com/apereo/java-cas-client/pull/197

There is example seraph-config.xml code in the comment.  Using this authenticator, you do not need any servlet filter updates in web.xml to get SSO.

If you want single sign-out support you should still include those filters and handlers.
If you want transparent SSO at your default URL (instead of seeing the login page and having to click 'Login'), use the CasAuthenticationFilter i listed previously, but change the filter mapping from /* to /default.jsp.

This configuration is working 100% with JIRA 7 for us on our test server.

[Marco Osorio]

Hello,

I have a problem with jira + cas authentication. I've followed the setup instructions that come up with two things.

1. In the web.xml configuration, if I comment the CasValidationFilter filter, JIRA v7.3.1 starts correctly if errors. When authentic with CAS takes me to the DashBoard but the login widget keeps appearing without content and does not allow me to visualize anything else, as if I was waiting to validate the login.

2. If I activate the CasValidationFilter filter, when authenticating with CAS, it generates a double ticket validation error with this trace:

Org.jasig.cas.client.validation.TicketValidationException:

             Ticket 'ST-380-eMVDywffQFkJ0W6DYY5f-DVMAPL207' not recognized ....

The versions of cas-client-core-3.2.1.jar and cas-client-integration-atlassian-3.4.2.jar libraries

Is there any missing configuration changes to avoid this double ticket validation?

Thank you

[Michael Brown]

Hi Marco, We are experience the same issues with the CAS integration as well. 

We did put together some instructions on modifying / updating the seraph-config.xml and web.xml files, and you can download the .JAR files we used here: https://bitbucket.org/mbrown_ascend/jira-cas-integration/downloads/. Although I'm not sure how to fix those issues other than adding "/*" instead of default.jsp in the filter mapping for the CasSingleSignOutFilter, CasAuthenticationFilter, and CasValidationFilter. 

By adding /* though, it breaks the Dashboard all over again and the _MSG error appear. 

Hope this helps a little, but we are also experiencing the same issue.

Mike

[Michael Brown]

Also, I found a workaround for the Login gadget appearing at times. You can simply hide it: https://confluence.atlassian.com/jirakb/howto-hide-the-login-gadget-from-the-system-dashboard-in-jira-5-1-305037906.html

Mike

[Ashis]

Micheal can you please help..

I have integrated CAS with JIRA. But when I open jira, user redirected to /secure/Dashboard.jspa which has jira login page, On clicking login from top right corner, cas page is opening and after successful logged in user is redirected back to CAS but again i see JIRA login page and user not logged in?

Have you also faced this issue?

I have also checked http://www.ascendintegrated.com/integrating-jira-sso-using-cas/ but no success in integration

[Tobias]

Hey Ashis,

did you solve this issue? I'm facing the same problem right now. Could you may share the configs needed to fix this issue?

Thanks in advance!

[Mac Reid]

Tobias,

I recently configured CAS for Jira 7.7.1. It works pretty well (we still have the _MSG_gadget issue). 

Here are my notes on the setup. Sorry, they are quite rough.

---------

download the dependencies (could be done with mvn, ant, or one of the other million java tools)

curl -L -O 'http://search.maven.org/remotecontent?filepath=org/jasig/cas/client/cas-client-core/3.3.3/cas-client-core-3.3.3.jar'

curl -L -O 'http://search.maven.org/remotecontent?filepath=xml-security/xmlsec/1.3.0/xmlsec-1.3.0.jar'

the upstream cas-client-integration-atlassian jar does not contain the jira7 auth provider. that needs to be compiled in from this PR - https://github.com/apereo/java-cas-client/pull/197.

git clone https://github.com/apereo/java-cas-client.git

cd java-cas-client

# create cas-client-integration-atlassian/src/main/java/org/jasig/cas/client/integration/atlassian/Jira7CasAuthenticator.java

mvn clean package

# the output jar will be in cas-client-integration-atlassian/target/

copy files to the jira server under $INSTALLDIR/atlassian-jira/WEB-INF/lib/.

next, stop the jira instance.

configure $INSTALLDIR/WEB-INF/web.xml with the following options. note, the THIS MUST BE THE LAST FILTER section is already present in the config

```

<!-- 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://cas.example.com/cas/login</param-value>

  </init-param>

  <init-param>

    <param-name>serverName</param-name>

    <param-value>https://jira.example.com</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://cas.example.com/cas</param-value>

    </init-param>

    <init-param>

        <param-name>serverName</param-name>

    <param-value>https://jira.example.com</param-value>

    </init-param>

    <init-param>

        <param-name>redirectAfterValidation</param-name>

        <param-value>true</param-value>

    </init-param>

</filter>

<!--- CAS:END -->

 

<!-- =====================================================

     THIS MUST BE THE LAST FILTER IN THE DEFINED CHAIN

     ===================================================== -->

```

also in web.xml, look for the section (NOTE: for the CasAuthenticationFilter entry, setting /* makes forces logins on every page, but using /default.jsp fixes the dashboard _MSG_gadget issues but doesn't force auth on every page)

```

<filter-mapping>

    <filter-name>login</filter-name>

    <url-pattern>/*</url-pattern>

    <dispatcher>REQUEST</dispatcher>

    <dispatcher>FORWARD</dispatcher> <!-- we want security/login to be applied after urlrewrites, for example -->

</filter-mapping>

above that add this section

<!-- 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>/*</url-pattern>

</filter-mapping>

<filter-mapping>

    <filter-name>CasValidationFilter</filter-name>

    <url-pattern>/*</url-pattern>

</filter-mapping>

<!-- CAS:END -->

```

now edit $INSTALLDIR/WEB-INF/classes/seraph-config.xml - look for this section. comment out the current login.url, link.login.url, and logout.url. in their place, add the options as configured below (changing the URLs as necessary).

```

<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

        '${pageCaps}' should be supported accordingly to com.atlassian.sal.api.page.PageCapability

        '${userRole}' when specified, should cause logout after login to an user with privileges lesser than requested

    -->

    <param-name>login.url</param-name>

    <!-- <param-value>/login.jsp?permissionViolation=true&amp;os_destination=${originalurl}&amp;page_caps=${pageCaps}&amp;user_role=${userRole}</param-value> -->

    <param-value>https://cas.example.com/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>https://cas.example.com/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>https://cas.example.com/cas/logout</param-value>

</init-param>

```

next, find the following section

```

<!-- CROWD:START - If enabling Crowd SSO integration uncomment the following SSOSeraphAuthenticator and comment out the JiraSeraphAuthenticator below -->

<!--

<authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>

-->

<!-- CROWD:END -->

<!-- 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 -->

```

Comment out any uncommented authenticators above and create this authenticator below it

```

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

        <init-param>

            <param-name>casServerUrlPrefix</param-name>

            <param-value>https://cas.example.com/cas</param-value>

        </init-param>

        <init-param>

            <param-name>serverName</param-name>

            <param-value>https://cas.example.com</param-value>

        </init-param>

</authenticator>

```

to remove the login box from showing up, edit $INSTALLDIR/WEB-INF/classes/jpm.xml and look for the section below. change the default-value from false to true

```

<property>

    <key>jira.disable.login.gadget</key>

    <default-value>true</default-value>

    <type>boolean</type>

    <admin-editable>false</admin-editable>

    <sysadmin-editable>false</sysadmin-editable>

</property>

```

now start jira. upon loading the main page (without session cookies) you should be redirected to cas. congratulations

---------

- Mac

[Tobias]

Mac, thanks for sharing this!

My config looks the same, but guess I figured out what my problem was. I just inserted my jira-url as "localhost:8080". Thus, my cas server was not able to uniquely identify the service via the service-parameter in the url.