Crowd authentication API

[Ganesh Srinivasan]

I looked at the proxy class and assembly generated from

wsdl /l:CS /protocol:SOAP http://localhost:8095/crowd/services/SecurityServer?wsdl and
csc /t:library /r:System.Web.Services.dll /r:System.Xml.dll SecurityServer.cs

in visual studio 2008 and attempted to create a .NET app using this assemply as reference.

I see various methods available such as authenticatePrincipal(), authenticatePrincipalSimple() etc, that require user credential.

While I can hard code application credential to match applications as configured in Crowd, I am attempting to use a two factor authentication with a smart card and PIN.

In short, we are attempting to verify user by external means and we want to forgo Crowd authentication altogether. We do have the user principal (without the password) once we have validated the user via external means.

How can we accomplish an implicit login to Crowd without user credential i.e without password ?

What is the PreAuthenticate boolean? Can we achieve our goals by setting the flag to true?

Where is more info on these API calls? I relied on this URL for my research: https://developer.atlassian.com/display/CROWDDEV/Crowd+Remote+API+Reference

Thanks in advance.

[Jason Keglovitz · Accepted solution]

This is my understanding based on experimentation, so take it with a grain of salt.

The whitelist is for the application IP address, not for users/visitors. I don't believe this has any relationship to the client IP addresses you use in the validation factor element.

The validation factor element in the REST calls is where you specify the remote address of the users/visitors. Crowd generates an SSO token based on the user credentials and the remote IP address in the validation factor. This is required so that the token will also be valid when you browse to Crowd since it's going to pull the remote address from the request header and validate the token.

(This post on debugging with proxy servers might help illustrate this: http://confluence.atlassian.com/display/CROWD/Debugging+SSO+in+environments+with+Proxy+Servers)

If you are pulling remote address off your request which is coming from your local network (e.g. 192.168.), this is challenging to test, because when you make a request to Crowd, the IP is going to be your external IP based on whatever proxy you're using to access Crowd. You'll have to decide the easiest way to test this given your network setup, but, in the end, for SSO to work, you want to hit Crowd using the same IP that you used in the validation factor element from your app.

[Ganesh Srinivasan]

Thank you very much. Everything works now within the intranet test environment.

[Rajiv Kulkarni]

Hello ganesh, I am new to Crowd authentication against AD. I currently have a couple asp.net webform and MVC app using windows auth currently and would like to use Crowd. Could you point me to some demo asp.net web application using Crowd for auth? Any help would be appreciated. Thanks.

[Ganesh Srinivasan]

Thanks. Actually you were quite correct - I have it working now. The problem was in the /session?validate-password=false POST, the XML structure I was passing was with the hostname of the calling machine. I had earlier tried both the hostname and fully qualified hostname in the validation-factor remote_address value field. I had configured crowd with white list of all 3 values namely hostname, fully qualified hostname and ip address. It turns out it only works if I pass the ip address in my POST! That was the last thing I tried this morning and voila, it worked! The documentation URL you provided, did show an example with 127.0.0.1 in the POST xml structure. I assumed it would work with the hostname just as well, but it does notb work with anything other than an ip address.

Now I am able to generate the token first from my ASP.NET application, then successfully go to crowd console without being prompted for userid / password. But I am now wrestling with another problem:

All the test I did above were from the same IIS box locally where my ASP.NET is running. Of course I never use localhost or `127.0.0.1 as the URL in my testing. I always use the fully qualified hostname + domain name in my URLS in the browser. Now if I pick a different client machine and try the test from there, it does not work. I point my browser (Firefox) from a remote machine to the same ASP.NET and it succesfully generates a token in my browser. Then I point the browser to crowd console, it prompts for my authentication. Again, everything works fine from the local ASP.NET machine browser.

Question: What ip address is required to be put in the POST xml during REST token generation? I assumed it is the ASP.NET web site ip address since crowd only knows about various "applications" configured in crowd. Unfortunately I was also doing my testing from the same machine, so the problems were not caught until this morning. If the visitor is coming from another remote machine, do I have to put that IP address instead? If so, the whiote list is going to get out of hand.

Thanks.

[Jason Keglovitz]

I take back my assertion about JSESSIONID. I didn't think it had anything to do with the solution, but what you're saying suggests otherwise. I'm now trying something similar to your setup and having a similar issue. I will also keep investigating. Please update here if you discover anything new.

[Jason Keglovitz]

3 things come to mind if you're seeing the cookie on the request

1. Is the Crowd cookie name correct? You said it matches what is configured in Crowd.

2. Is the token valid? It should be since you just created it, but I would check to make sure that your cookie payload is in fact valid. Have you tried the call to validate the token to see if it's legit? You can POST to /session/{token} The details are listed in that same table titled SSO Crowd Token Resource.

3. Your IP is not valid for authentication. I don't have the admin screen available at the moment, but there's a place in the Crowd admin UI to whitelist IPs

The JSESSIONID has nothing to do with the SSO solution

[Ganesh Srinivasan]

1. Yes, I invoked the GET config/cookie and examined the returned XML response body. The cookie name I add to the browser is correct as configured in crowd.
2. Yes, I invoked the GET session/abcd1234…….. (token string) and the returned XML response body is correct. It returns OK (200) and not the bad 40x status. So, all is well there. I did not do the POST to revalidate the token as I just created the token; rather I invoked the GET to retrieve the token instead. I will go back to try the revalidate just in case…..
3. I have verified that all 3 forms of remote address are configured in crowd against all 3 application RemoteAddresses tab(s): (i)crowd console application, (ii)demo application as well as my (iii)SSO ASPX application I have configured in crowd. The 3 forms are IP address, fully qualified domain (host.domain) and host name of machine where I am testing from.
The fact that you mention JSESSIONID is not important indicates that perhaps I am testing it the wrong way? Perhaps I have to set up Confluence or Jira for SSO with the crowd authenticator enabled, and then test my ASPX solution with confluence? Confluence / Jira probably will insert their own sessionid cookies in browser and the seraph crowd authenticator there perhaps looks for this crowd.token_key and magically eberything will work from there? I wanted to leave confluence/ jira out of it until I can prove the smart card 2 factor authentication works with crowd and other crowd apps like demo (built in to crowd).
One more thing: As I drive the remote REST API from my ASP.NET application, I noticed the crowd console does not show it. I started crowd from command line (started command line using Run As administrator) then ran Start_Crowd.bat file rather than starting crowd as a service so that I can view the traffic in the cmd prompt window. Is this behavior normal? Regardless I am certain REST itself is working fine as observed in POST and GET responses in Httpfox.
Any more ideas?
Thanks.

[Ganesh Srinivasan]

I should clarify why I think I may be testing it the wrong way: The documentation link

http://confluence.atlassian.com/display/CROWD/Integrating+Crowd+with+Atlassian+Confluence#IntegratingCrowdwithAtlassianConfluence-22EnableSSOintegrationwithCrowdOptional

says that Confluence 3.5 and above uses REST to communicate with Crowd and further that you have to uncomment ConfluenceCrowdSSOAuthenticator and comment out ConfluenceAuthenticator in seraph-config.xml and further you have to make crowd.properties changes after copying from crowd/client/... folder etc etc. Now I am not sure there are similar instructions to make other apps like the demo app that ships with crowd or for that matter other ASP.NET apps within customer intranet organization?? The above factors coupled with the fact that I notice several 302 followed by redirects whenever you visit the demo or crowd console with only the crowd.token_key cookie. It seemed as though the redirects occur to a login screen simply because the demo and crowd application believes a session needs to be established first via login. Hence my question about JSESSIONID. The fun thing is that after 302 redirects and login, the final flow on HttpFox shows clearly that the browser receives the same old token cookie crowd.ken_key with the same old value that was sent on the initial GET request to these apps to begin with - proving that my token is accurate and continued to be valid!

I can't help but wonder if there is a missing link such as seraph-config.xml etc that needs to be replicated behind these other apps like demo app and crowd console in order to make SSO work for these apps like it is documented for confluence.

Thanks.

[Jason Keglovitz]

I believe the Crowd REST API is the recommended approach.

https://developer.atlassian.com/display/CROWDDEV/Crowd+REST+Resources is the link to the detailed docs for these calls.

Have a look at the SSO Token Resource section if you want to establish a Crowd session and return the session token in a cookie on the response. A POST to /session will create a new session token and that call takes an optional validate-password query param. Setting that to true should allow you to create a session for your user w/o needing that credential.

The Cookie Configuration Resource gives you the details on the cookie settings to use for the response (name, domain, secure).

You use basic auth with the application credential on all calls. This credential is configured in the Crowd Admin console; it's not a user principal credential.

[Ganesh Srinivasan]

Great! Thanks for the response. I looked at it, yes, that should get me going. Thanks again.

[Ganesh Srinivasan]

I have successfully done the POST to /SESSION?validate-password=false with the post xml and successfully retrieved the CREATED success code with the headers and XML body response. Looking thru the headers I saw the token in xml body response which I set as cookie named crowd.token_key and path = / and domain=.esxx.xx.xx as configured in crowd. All of the above are done thru an ASPX web site I created for the explicit purpose of SSO with a smart card. When I however open a new browser window immediately and go to the same crowd site http://xxx.esxx.xx.xx:8095/crowd I am prompted to login again!! I do see my crowd.token_key with the correct token value as gotten from my ASPX web site - i see the flow in HttpFox. What am I doing wrong? Should I be trying the test by going to a different crowd URL like ..../loginaction or some such deep url path? Please advise. Also if I clear all cookies and try a test directly going to crowd without going thru my ASPX SSO site first, I see aside from the crowd.token_key cookie, there is also a JSESSIONID. Not sure if that is what is breaking my SSO solution? Thanks in advance for any guidance you can offer.

[Jason Keglovitz]

I would use the Crowd REST API to accomplish this.

https://developer.atlassian.com/display/CROWDDEV/Crowd+REST+Resources is the link to the detailed docs for these calls.

Have a look at the SSO Token Resource section if you want to establish a Crowd session and return the session token in a cookie on the response. A POST to /session will create a new session token and that call takes an optional validate-password query param. Setting that to true should allow you to create a session for your user w/o needing that credential.

The Cookie Configuration Resource gives you the details on the cookie settings to use for the response (name, domain, secure).

You use basic auth with the application credential on all calls. This credential is configured in the Crowd Admin console; it's not a user principal credential.