-
Bug
-
Resolution: Fixed
-
Low
-
3.2.0
-
None
-
Severity 2 - Major
-
Summary
After upgrading Crowd to version 3.2.x, users can't log into Crowd console. The following error can be found in the atlassian-crowd.log:
2020-02-30 00:00:00,000 http-nio-8095-exec-7 ERROR [crowd.integration.springsecurity.AbstractCrowdSSOAuthenticationProcessingFilter] Unable to set Crowd SSO token java.lang.IllegalArgumentException: An invalid domain [.example.com] was specified for this cookie at org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateDomain(Rfc6265CookieProcessor.java:203) at org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265CookieProcessor.java:145) at org.apache.catalina.connector.Response.generateCookieString(Response.java:1019) ... ...
Cause
Crowd has recently upgraded it's bundled Tomcat to version 8.5 and it's now strictly compliant with RFC6265, although according to RFC's Server Requirement Documentation (4.1.2.3. The Domain Attribute), leading dot such as in .example.com is ignored though not permitted:
Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted
Workaround
Remove trailing dot from the SSO domain.
- You will need to access your database and get the current value of the sso domain by running following SQL:
select property_value from cwd_property where property_key = 'crowd' and property_name = 'domain'
This will return a current value of SSO domain set in Crowd, for example .mydomain.com
- Assuming that the current value of the SSO domain is .mydomain.com (with a leading dot), update the value with the domain name and omit the leading dot as follows:
update cwd_property set property_value = 'mydomain.com' where property_key = 'crowd' and property_name = 'domain'
The same RFC 6265 states that the user agent should ignore leading dot in the domain attribute for the Set-Cookie header and tread the value just as it would not have this leading dot:
If the first character of the attribute-value string is %x2E ("."): Let cookie-domain be the attribute-value without the leading %x2E (".") character. Otherwise: Let cookie-domain be the entire attribute-value.
so removing the leading dot will not break current SSO integration
[CWD-5141] Error logging into Crowd, when the SSO domain starts with a dot ('.')
Thanks Lukasz. We have actually faced that issue on several Jira/Confluence instances but you're right, this is our add-on's code that sets the Crowd cookie, not Atlassian's Crowd client integration libraries. Anyway, removing the leading dot has always fixed the problem.
bruno.vincent@atlantis.fr as far as we are aware, this currently only affects Crowd, as other products use the previous way of setting the cookie for now.
This issue is not limited to Crowd itself. Any Tomcat-based application (e.g. Jira, Confluence) using Crowd for SSO may be impacted if the cookie.domain property in the application's crowd.properties file has a leading "." character: https://confluence.atlassian.com/crowd/the-crowd-properties-file-98665664.html
@Marcin Kempa I used the first work-around (no longer in the issue) to set the cookie without the (leading/trailing) dot (as per 2nd work-around that was previously in the issue). The situation is now similar to the situation that comes from the current work-around (I think)
It lead to authorization errors due to the browser cache but once that was resolved it works fine.
I suggest as a fix to remove the "wrong dot" in the crowd upgrade scripts for the next version(s)
I think this happened to one of my users. Using Chrome on a Mac, he was logged in to Confluence at the time I removed the cookie domain. When he went to log back in after his session timed out, he was unable to until he restarted Chrome. Same scenario again when I added the domain back without the dot as per your suggestion – he had to restart Chrome to be able to log in. In my testing, if you explicitly click the logout menu item, it allows you to login again no problem even with the cookie domain change.
Once the SSO domain is change, Crowd will start to set the SSO cookie for this domain, however browser may still have the old one for the domain with the dot at the beginning and may choose this one to be send back to server (for browsers according to RFC 6265 it does not matter if the domain starts with a dot or not).
If the old cookie is sent then Crowd may reject such session and users would have problems with authentication. Even if they login again Crowd will send a cookie with a domain without the dot and the old one will still be there and the user would arrive at the same situation back again.
The solution might be to either remove Crowd SSO cookies from the browser or change the name of the SSO cookie in Crowd config and all other applications that are connected to Crowd so the SSO still works.
The former solution has this problem that you would have to tell that to all of your users if they experience this kind of problem. The latter may require some more work from you and potentially a restart of applications connected to Crowd.
I have not test this scenario yet, but this is what I believe may happen. We are exploring different solutions for this problem and will post and update on the ticket
khera indeed it looks like the problem is only related with the Crowd 3.2.0
For me, it was not a problem until I upgraded to 3.2. The 3.1.3 release worked fine.
r.erica just to let you know, I've removed the workaround that was listed as a first one and suggested to replace CookieProcessor in Tomcat. In general I believe it will be better just to have domain defined as per RFC6265 rather than customize Tomcat itself.
Let me know if that workaround also works for you.
Best Regards,
Marcin Kempa
This issue was resolved in Crowd 3.2.1. The leading dot in the SSO cookie domain will be automatically removed from the configuration during upgrade process.
Crowd Team