Redirection loop to login page using custom SSO

Confluence Development Confluence Server
, ,
1

Hey, I’ve got a problem with Confluence 8.x.x redirecting to login page on certain addresses on new session. On others authentication works fine. Confluence 7.x.x works fine with the same setup
In confluence 8.0 opensymphony xwork was changed to struts2 and should that be the problem?

We’re using Apereo CAS 3.6 as our SSO with client library in version 3.6.5 with atlassian support 3.6.4 (currently modified due to the problem). Seraph has login page setup for sso login page.
Sso client library adds authentication and ticket validation filters for use which are crucial for working process

SSO authentication works fine on /display, /rest, /status addresses while fails to authenticate new session on “/”, /admin, /auth
Websudo is off due to custom sso
Sso client library has filters defined by modified web.xml file. My thought is that filters set in web.xml are not the first one to run on failing addresses and as struts2 was introduced maybe this is the cause.

Authentication works fine after I enter /display address even in admin panel so it’s purely authentication problem.
Have anyone faced this? I see there are some recommendations that those authentication filters should be defined by spring configuration instead which I haven’t tried yet.

2

Hi @TomaszJekiel
Earlier, XWork rendering stack used to be a Servlet executing at the end in 7.x, but its now a ServletFilter in Strut2 and hence it gets executed earlier in the lifecycle.
I suspect this to be the reason, you can try looking for some answers under Struts2 PSA.

Regards,
Ganesh

3

Ok, so that may be the case. In this situation I’d need to configure my filters with higher priority than Struts2 or incorporate SSO filters into Struts2 defaultStack stack interceptors.
Both ways require coding and one of them should work.
Thanks for the lead.

1 Like
4

To sum up steps taken to solve problem:

  1. Struts2 was introduced in version 8.x as web filter as opposed to servlet in previous versions.
  2. This ^ made filters defined in web.xml added to the end of filters chain.
  3. Struts filter took control over every request that directly ended with .action, e.g. /dashboard.action and didn’t let SSO filters to run.
  4. Adding filters mapping programmatically using Spring’s WebApplicationInitialize API helped to reestablish SSO filters at the top of filter chain. Therefore, SSO is working works as it did in Confluence pre 8.x.
1 Like
5

@TomaszJekiel - I’m in the same boat with CAS on 8.x. Any chance you could share your code? I’m not a java dev so the solution has been quite elusive.

6

Sure, there’s no some secret codes there.GitHub - gulpo/atlassian-java-cas-client: Apereo java cas client fork of version 3.6.4 which still has atlassian integration in it
It’s a fork of apereo cas client ver. 3.6.4 (last version with Atlassian support)

7

Thank you very much! The piece I was missing was adding the class file to the classes folder. I’m off and running now though. Thanks again!