SSO Between Confluence and Custom Web Application

[Raymond Ho]

I am experiencing a problem similiar to these two posts, but no sufficient answer was listed for them.

#1 : https://answers.atlassian.com/questions/1820/sso-cookie-ignored-overridden

#2 : https://answers.atlassian.com/questions/20020/where-to-put-crowd-token-for-sso-towards-confluence-jira

Trying to set up Crowd (2.5.3) with SSO between Confluence (3.5.13) and my custom web application (.Net MVC).

When I log into Confluence or the Crowd Console, then go to my application... the SSO works. So that tells me my app can read whatever cookie is created in Crowd Console or Confluence.

But when I log into my application, then go to Crowd Console or Confluence... then SSO does not work. Which seems to indicate that the cookie I am creating is incorrect...

Following the instructions for creating a proper SSO cookie... created cookie with key "crowd.token_key", set Path = "/", set Domain = ".mydomain.com", set Expiration to Current Time + 12 hours, and set value to Token received from Crowd server after authentication. I see my cookie being created. If I go to my app, my app uses the cookie properly. But once I go to Confluence / Crowd Console, I see a similiar behavior to post #1 where my cookie is "overwritten". Similiar to post #2, SSO between Crowd and Confluence works fine.

Any resolutions to the two items above? Or any ideas on where I might be going wrong? Thanks in advance.

[Raymond Ho · Accepted solution]

Finally resolved the problem. Issue ended up being the Validation Factors I was using to get the Crowd Token. The "updated" code used in the example in the documentation was actually for Crowd 1.6.

By going to "%CROWDHOME%\crowd-webapp\WEB-INF\lib" and reverse engineering the "crowd-integration-client-soap-2.5.3.jar", I was able to find the correct mix of validation factors to use for authorization. Short answer, "remote_address" and "X-Forwarded-For" was enough. No user agent strings or others required.

Once I made this change, I was able to create a cookie which both Confluence and Crowd accepted... thereby enabling SSO between my custom .Net application.

[Philip Colmer]

Raymond

Is the order of the validation factors important?

Looking at the source for the Apache Crowd add-on, that also uses remote_address and X-Forwarded-For. The code wraps the value from X-Forwarded-For in a CDATA block - did you have to do that?

I'm trying to get the PEAR Crowd code working but the tokens it generates are still not matching those generated by Atlassian's own apps.

Thanks for any help you can provide.

Philip

[Jackson Ong]

Philip,

Did you manage to solve the problem? I am having he exact same problem and google for weeks for solutions. This is the closest I get. I have the cookie, I can authenticate via the custom application, and confluence with crowd works, but with custom application, SSO just doesnt work. I have also put in the validation factor. Not really sure what else is missing.

Thanks if you have any info.

[Sam Kenny]

Thanks for your response, Joe. Even after rebooting and clearing all cookies we still get the same error - so it is not related to an active Confluence/Crowd session. Also, the problem occurs for all users.

The token is being received but it does not seem to be accepted. We were wondering whether this was because the cookie is missing other information - such as the user agent - but even after setting these, the cookie does not seem to be accepted.

[joe]

There are a couple of things you might want to check. Make sure you don't have an existing active session in Confluence/Crowd when you go there with the cookie received from your application. Can you confirm that, when you connect to the Crowd Console that the token received from your app is being sent along with the initial request?

[Raymond Ho]

Joseph,

Turned on Crowd logging and ran a sample where I first login to my custom application and then login to confluence. The cookie from my custom application is received and looked at, but the token does not match.... I believe these are the relevant logging lines...

2013-01-11 13:57:42,538 http-8095-12 DEBUG [crowd.manager.authentication.TokenAuthenticationManagerImpl] comparing existing token com.atlassian.crowd.model.token.Token@75dbdfec with a validation token com.atlassian.crowd.model.token.Token@c2d0707a
2013-01-11 13:57:42,538 http-8095-12 DEBUG [crowd.manager.authentication.TokenAuthenticationManagerImpl] The token keys don't match

After looking further into this issue, the issue might be that the ValidationFactors are not the same. So I attempted various permutations of different factors, include user-agent, remote_address, x-forworded-for, etc. Was not able to find a permutation which solved my problem. Not 100% sure I am on the right track.

I suppose what would be extremely helpful would be a working example / demo of a .Net client working with SSO. Looking at the documentation (https://developer.atlassian.com/display/CROWDDEV/Microsoft+.NET+Client), the link for an "updated" client leads here :

https://plugins.atlassian.com/plugins/plugin.CNET

But this code is labeled for Crowd 1.6, while we are using the 2.5.3 version.

The other link in the documentation :

https://developer.atlassian.com/download/attachments/2424840/Crowd.Integration.Sample.cs?version=1&modificationDate=1170830210353

Is some very basic code on authentication, which I can currently do. But gives no hint on how to correctly enabled SSO.

Is there any current sample code for .Net clients? Or maybe if you can direct me to where the correlating code would be in the java demo application would be, I can try a conversion.

Thanks much for your help.

Ray

[Sam Kenny]

So one not very nice way of doing this is to capture the userid/password of the user and log them into Confluence from the Web Application.

After logging in, the Web Application takes the user to a page running the redirect macro which in turn takes them back to the Web Application - because the user has now authenticated (and the authentication works if the user has logged into Confluence first) they are able to progress.

This works, but there must be a better solution, surely.