Configuring JIRA and Confluence SSO with CAS server

Other Questions Jira
1

I’m experiencing some difficulties in setting up Single Sign-On (SSO) between my JIRA and Confluence applications using a CAS server. I have three Tomcat instances running on my local machine: one for the CAS server on port 8050, one for JIRA 4.3 on port 8080, and the last one for Confluence 3.5 on port 8070.

I’ve integrated the CAS client into both JIRA and Confluence as described in the documentation, and so far, both applications redirect me to the CAS login page and authenticate through an LDAP server. However, the SSO functionality is not working correctly. If I log into JIRA, I still need to enter my credentials again when I try to access Confluence, and vice versa.

I believe this issue might be caused by the different Tomcat instances, as each application receives a separate service ticket from the CAS server. Here are the relevant configurations I’m using for both applications:

JIRA Setup (seraph-config.xml):

<init-param>
    <param-name>login.url</param-name>
    <param-value>http://localhost:8050/cas-server-webapp-3.4.8/login?service=${originalurl}</param-value>
</init-param>
<init-param>
    <param-name>link.login.url</param-name>
    <param-value>http://localhost:8050/cas-server-webapp-3.4.8/login?service=${originalurl}</param-value>
</init-param>
<init-param>
    <param-name>logout.url</param-name>
    <param-value>http://localhost:8050/cas-server-webapp-3.4.8/logout</param-value>
</init-param>

JIRA web.xml 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>http://localhost:8050/cas-server-webapp-3.4.8/login</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
        <param-value>http://localhost:8080</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>http://localhost:8050/cas-server-webapp-3.4.8/</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
        <param-value>http://localhost:8080</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

Confluence Configurations (seraph-config.xml):

<init-param>
    <param-name>login.url</param-name>
    <param-value>http://localhost:8050/cas-server-webapp-3.4.8/login?service=${originalurl}</param-value>
</init-param>
<init-param>
    <param-name>link.login.url</param-name>
    <param-value>http://localhost:8050/cas-server-webapp-3.4.8/login?service=${originalurl}</param-value>
</init-param>

Confluence web.xml 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>http://localhost:8050/cas-server-webapp-3.4.8/login</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
        <param-value>http://localhost:8070</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>http://localhost:8050/cas-server-webapp-3.4.8/</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
        <param-value>http://localhost:8070</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

Can someone help me identify what might be causing this issue with SSO? I would greatly appreciate any insights.

2

I hit this exact issue before - it’s usually cookie domain problems. Your browser sees port 8080 and 8070 as separate domains, so the TGT cookie from CAS can’t be shared between them. Try adding gateway=true to your authentication filters. This makes CAS check for existing auth without forcing a new login. Also check that your CAS server uses the same cookie domain for all services. I had to tweak the CAS server’s cookie config to get authentication state shared properly between apps on different ports. Since authentication works but SSO doesn’t, your ticket validation is fine - it’s just the session sharing that’s broken.

3

you might wanna check that your CAS server’s settings are allowing for cross-service SSO. sometimes it’s all about the TGT cookie and makin sure it’s set properly for both domains. I’ve been there, and it was a matter of the ticket grantin thing not bein shared across the apps.

4

Your config looks mostly right, but here’s the problem: JIRA and Confluence are running on different ports, so they’re creating separate session contexts. CAS handles the central auth fine, but each app manages its own sessions independently. I hit this exact issue setting up SSO for multiple Atlassian products. You need to make sure your CAS server can handle multiple service URLs and both apps accept the same user attributes from CAS. Check your CAS service registry - both localhost:8080 and localhost:8070 need to be registered as valid services. Also double-check your LDAP attribute mapping is identical in both apps. I’ve seen username formatting differences break SSO even when authentication works perfectly.