Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Strange one. It seems if I login to jira, confluence, crowd or fisheye and then go to drupal I am automatically logged in. Which is great!
However when I login through drupal I am not auto logged into any atlassian service. Something about cookies I am assuming?
Comments
Comment #1
rjacobs CreditAttribution: rjacobs commentedHummm, this is not an issue that we have been seeing, at least not since the following issue was addressed (which was targeted toward this exact problem):
#1943110: Need to address interoperability for SSO with other atlassian tools (Crowd Console, Confluence, etc).
That said I've only really tested a Drupal-initiated SSO session against the Crowd Console, and have not tested it against any other Atlassian applications (JIRA, Confluence, etc.). Does your Drupal-generated session also fail when accessing the Crowd Console?
Also, which version of Crowd are you using?
The other variable that might be at play are the crowd validation factors. Whenever a session is initiated (via crowd_rest_client::authorize) it not only opens an SSO session in Crowd, but it also sets a validation factor of the user's IP address. My understanding is that other systems must also validate this factor in order for their local logins to be triggered (i.e. their IP address must match the one used when the session was created). In the case of the Crowd Console, validating the IP address (along with the actual session token) seems to be all that's needed, but I'm wondering if other Atalassian tools are more strict?
On the Drupal side (e.g. logging-in to Drupal based on an SSO session started elsewhere) things are not nearly as strict. In fact, this module is currently only validating that the user's session is active (based on the session token) in order to allow a local login. No other validation factors are checked.
Comment #2
tm1000 CreditAttribution: tm1000 commentedThis is basically what I wind up with in the crowd log (when logging is set to debug): Existing token 'wwq5QzZQFgOiwOEoksLcEw00' for user 'tm1000' does not match new token 'ZDk8VfrX2XL1WF7W7TRSag00'
Crowd Version: 2.6.1
Does your Drupal-generated session also fail when accessing the Crowd Console? Yes
When logging out:
Comment #3
tm1000 CreditAttribution: tm1000 commentedOk. I figured out the issue. We are running our setup behind apache proxy pass. See: https://confluence.atlassian.com/display/DOC/Using+Apache+with+mod_proxy
I assume you are running yours all straight off the ports (domain:8095, domain:8080, domain:8090). Which is fine. But we have all of the apps remapped to sub-domains. EG: issues.domain, wiki.domain, code.domain
This breaks how you initially setup the function authorize. Only because the remote_address tag becomes "0:0:0:0:0:0:0:1" or "127.0.0.1" (a limitation of mod_proxy) which wont match the remote_ip of the client that you've set. So what we have to do is set the X-Forwarded-For tag to the remote ip.
Basically this:
Changes to this:
It's a semi-strange but documented setup. Basically all users who login to wiki.domain, issues.domain and code.domain are using ip address of 127.0.0.1 or 0:0:0:0:0:0:0:1 because of apache's mod_proxy_pass, however, all atlassian products automatically append X-Forwarded-For into the standard login requests when they detect they are running in proxy mode. This is why when I logged in through the atlassian apps it worked, but in the drupal module it didn't.
I believe, many people will run into this situation simply because the documentation for proxy pass from atlassian walks them through this setup leading them to the point I was at before.
My proposed solution is more options (yay?) in the administrators settings to define the "remote_address" value in authorize. If it is defined then we should add the 'X-Forwarded-For' as above. If it's blank then just do what you did before.
Thoughts?
Comment #4
tm1000 CreditAttribution: tm1000 commentedJust read up on: https://confluence.atlassian.com/display/CROWD/Configuring+Trusted+Proxy...
Seems as though when I add 127.0.0.1 and 0:0:0:0:0:0:0:1 as my trusted proxy servers I no longer have the issue with the orignal code. So I would say this can be closed without any modifications!
Comment #5
rjacobs CreditAttribution: rjacobs commentedSo are you running a reverse proxy and both your Atlassian apps and Drupal are behind it? We too have everything segmented out into subdomains (app1.example.com, app2.example.com, etc...) but each is either running on its own webserver (with its own public IP) or is running under a shared public IP but with a separate vhost, so no proxy is involved.
Anyway, yes, the way this plays out in terms of validation factors could be a bit tricky, and if Atlassian systems set those factors differently, this could lead to issues. The place I got my understanding of these factors was here:
https://answers.atlassian.com/questions/123130/sso-between-confluence-an...
That info lead to some modifications to crowd_rest_client::authorize (in #1943110: Need to address interoperability for SSO with other atlassian tools (Crowd Console, Confluence, etc).) to get things working for our case by correctly setting validation factors. What is interesting is that the drupal ip_address() function, which is used to set the "remote_address" factor, automatically resolves to the "X-Forwarded-For" value if one is found. Initially I thought this might be a good thing but as I think about it more I'm not sure. This "remote_address" value may actually need to be the proxy address when a proxy is involved, because that's the way other Atlassian products expect it to be (and they instead look to the separate "X-Forwarded-For" value to get the real validating IP).
To be honest I'm not sure what the best solution would be. The Atlassian documentation about how their own products handle this stuff seems to be lacking, so it's hard to say. It's good to know that adding some trusted proxies in crowd fixes this without any other changes, I just wonder if that poses any security concerns, as it could mean no apps validate any IP addresses anymore ("X-Forwarded-For" is ignored?). Could that be a concern in a reverse proxy situation, as the proxy itself is not enforcing any trust over who can use it?
Anyway, as you have a working case that really tests this situation (and know it best), I'd certainly be open to your thoughts on the best fix (leave as-is and tell users to set trusted proxies vs. change something in the code to properly handle and "X-Forwarded-For" validation factor).
Comment #6
tm1000 CreditAttribution: tm1000 commentedYes I have them running on the same server and behind a proxy. Drupal is no behind a proxy but the atlassian apps are. Let me look into this a little more deeply in terms of crowd logs. From what I can tell adding the proxy just changed the x-forwarded-for IP to the remote_address. So the IP is still kept, just moved to a more reliable place. But I need to look into that.
Comment #7
rjacobs CreditAttribution: rjacobs commentedThere is also a "Require Consistent Client IP Address" setting in Crowd Console under "Administration" > "Session Config" that I think might influence things here. My guess is that whenever that setting is active (and it seems to be by default) Crowd will always need to validate the user's IP address along with the token. Furthermore, it's up to each authenticating app to fetch and pass the "correct" IP address. I suppose this is what these validation factors are all about, and that the IP will be interpreted from the the "X-Forwarded-For" factor when it's passed or the "remote_address" factor otherwise.
This is total speculation, but it would be interesting to know if things still work for you if you disable this "Require Consistent Client IP Address" setting and then also remove any trusted proxy settings.
Comment #8
rjacobs CreditAttribution: rjacobs commentedSo at the moment it looks like there are a couple of ways to get around this issue (see comment #4 and #7), but it's clear that we'll ultimately need a more robust solution. For now I don't think I personally will be able to troubleshoot this too much more (due to limited time and no access to reverse proxy setups for testing), so I'm going to mark this as postponed. If anyone wants to get involved and help out with this one we can certainly re-prioritize it.
Comment #9
rjacobs CreditAttribution: rjacobs commentedI just re-read this document which explains the Crowd "Tusted Proxy" concept:
https://confluence.atlassian.com/display/CROWD/Configuring+Trusted+Proxy...
There's an interesting quote in there which says:
So, I think what this means is that even if a request comes through a proxy, and that proxy is in the "trusted proxy" list, the requesting users IP is still validated. Initially I thought that if the request came through a "trusted" proxy it meant that the IP info was just ignored (comment #5), but it seems that this is not the case and that Crowd still goes on the validate the IP... it's just smarter about which one it chooses. This is good and I guess is what tm1000 was alluding to in comment #6.
So, I think that as long as Drupal sets a "remote address" during authentication that is not an address of a proxy, it should be totally compatible with what Crowd, and other apps validating an SSO session against Crowd, expect. As long as the "Trusted Proxy" details are configured correctly it should not matter too much which specific validation field ("remote address" vs "X-Forwarded-For") is set, because Crowd can check against both later when validating. Furthermore, as Drupal's ip_address() function already extracts the correct IP for us (the non-proxy one), we are in good shape.
So I think this can be closed without any changes. I don't personally have the resources to exhaustively test further, but based on the docs, and the fact that at least one person conformed that the current design works (comment #4), I think we're ok.
Comment #10
rjacobs CreditAttribution: rjacobs commentedHere's an additional doc reference in case anyone (e.g., me) needs to get up to speed on all this again at some point in the future....
https://confluence.atlassian.com/display/CROWD/Debugging+SSO+in+environm...