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

rjacobs’s picture

Hummm, 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.

tm1000’s picture

This 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:

2013-04-23 02:07:26,206 http-8095-17 DEBUG [plugin.rest.filter.BasicApplicationAuthenticationFilter] Application '<appname>' authenticated successfully
2013-04-23 02:07:26,206 http-8095-17 DEBUG [plugins.rest.module.RestDelegatingServletFilter] Setting base uri for REST to 'latest'
2013-04-23 02:07:26,206 http-8095-17 DEBUG [plugins.rest.module.RestDelegatingServletFilter] Incoming URI : /rest/usermanagement/latest/session/wwq5QzZQFgOiwOEoksLcEw00
2013-04-23 02:07:26,207 http-8095-17 DEBUG [mchange.v2.resourcepool.BasicResourcePool] trace com.mchange.v2.resourcepool.BasicResourcePool@26de017b [managed: 1, unused: 0, excluded: 0] (e.g. com.mchange.v2.c3p0.impl.NewPooledConnection@1ab1b70e)
2013-04-23 02:07:26,207 http-8095-17 DEBUG [crowd.manager.authentication.TokenAuthenticationManagerImpl] InvalidateToken: token wwq5QzZQFgOiwOEoksLcEw00
2013-04-23 02:07:26,209 http-8095-17 DEBUG [crowd.manager.authentication.TokenAuthenticationManagerImpl] Removing token from the database
tm1000’s picture

Ok. 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:

    $XML = new SimpleXMLElement("<?xml version='1.0' encoding='utf-8'?><authentication-context></authentication-context>");
    $XML->addChild('username',htmlspecialchars($username, ENT_NOQUOTES, 'UTF-8'));
    $XML->addChild('password',htmlspecialchars($password, ENT_NOQUOTES, 'UTF-8'));
    $vfs = $XML->addChild('validation-factors');
    $vf = $vfs->addChild('validation-factor');
    $vf->addChild('name','remote_address');
    $vf->addChild('value',ip_address());

Changes to this:

    $XML = new SimpleXMLElement("<?xml version='1.0' encoding='utf-8'?><authentication-context></authentication-context>");
    $XML->addChild('username',htmlspecialchars($username, ENT_NOQUOTES, 'UTF-8'));
    $XML->addChild('password',htmlspecialchars($password, ENT_NOQUOTES, 'UTF-8'));
    $vfs = $XML->addChild('validation-factors');
    $vf = $vfs->addChild('validation-factor');
    $vf->addChild('name','remote_address');
    $vf->addChild('value','0:0:0:0:0:0:0:1');
	$vf1 = $vfs->addChild('validation-factor');
    $vf1->addChild('name','X-Forwarded-For');
    $vf1->addChild('value',ip_address());

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?

tm1000’s picture

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

rjacobs’s picture

So 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).

tm1000’s picture

Yes 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.

rjacobs’s picture

There 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.

rjacobs’s picture

Title: SSO Cookie not always working » Support IP validation when creating SSO session in Drupal (and proxies are involved)
Status: Active » Postponed

So 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.

rjacobs’s picture

Issue summary: View changes
Status: Postponed » Closed (works as designed)

I 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:

Configuring a trusted proxy server means that Crowd will iterate through client IP address and IP addresses in the X-Forwarded-For header from right to left and pick the first IP address that is not a trusted proxy. The address is then used as the client's IP address.

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.

rjacobs’s picture

Here'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...