Using Crowd with AWS Cloudfront

[M Amine]

Hi,

My team and are working on setting-up Crowd in AWS using Cloundfront as a Content Delivery Network and with an HTTPS navigation. 

We are gathering all interesting information about this topic and I think it will be a great thing to get all the community involved so each one can share experience and thoughts. 

So have you deployed Crowd using a CDN? if yes can what are the main pin points that you have dealt with? and what is your architecture? 

[M Amine]

Sharing our experience, until now, we were unable to set Cloudfront in front of Crowd because of Crowd "trusted proxies" configuration. In fact, Crowd asks to configure a trusted proxy (or proxies) but in the case of Cloudfront the proxy address varies. We got in touch with Atlassian team and no solution has been found. So in our point of view it is impossible to set Cloudfront with Crowd (at least until now!)

[Bruno Vincent]

Hi @M Amine 

As per AWS documentation, you can find CloudFront's IP addresses in JSON format on this link (you will need to filter elements whose service's value is "CLOUDFRONT").

The problem is that you need to periodically retrieve those values and add them to the list of trusted proxy servers in Crowd's console. As far as I know, at the time of writing, Crowd's REST API does not provide the ability to import them programmatically.

[M Amine]

Hi @Bruno Vincent 

In fact, we have already tried that and it didn't work. The reason behind it is that when you access crowd the first time, you may get though a first IP adresse (IP1 for example). But when you make a second call, you get through another IP address (IP2 for example). The 'fun' part is that crowd is getting lost and this is a know 'bug' in Crowd : link. 

When a user first logs into Crowd, the application generates a token for the user with validation factors. The validation factors above include a remote_address (which is the IP address of the proxy), and X-Forwarded-For address (which should be client/user's original IP address). When a user tries going to another application, Crowd tries to validate that token with the original X-Forwarded-For address. As long as the remote_address is in your trusted proxy settings, Crowd will not expect these IPs to be the same. Since one of the proxies is generating a new IP each time the user tries to access, Crowd thinks that these requests are coming from two different IPs, even though they are both coming from the same user on the same machine.

[Bruno Vincent]

Thanks @M Amine , that's a very interesting piece of information.

I suppose you have already tried to uncheck the 'Require Consistent Client IP address' option, haven't you?

In your specific case, you would instead need to uncheck a 'Require Consistent Proxy IP address' option. Did Atlassian mention whether they would open a feature request on this?

[M Amine]

Message edited in order to change "Require Consistant Proxy IP address" by "Require Consistant Client IP address"

This is it. It worked. Need to make additional tests but the first tests are working fine. 

In fact Atlassian support haven't suggested this option and we didn't notice it either. 

So as a conclusion (that needs more tests to be confirmed) Crowd can be set with a CDN and requires to uncheck 'Require Consistant Client IP address'. 

Thank you vm @Bruno Vincent for your help. It was really a pleasure discussing with you.

[Bruno Vincent]

Hi @M Amine 

I suppose you mean 'Require Consistent Client IP address'.

'Require Consistent Proxy IP address' does not exist anywhere but in my own mind at the time of writing 😉

My understanding is that unchecking 'Require Consistent Client IP address' tells Crowd to bypass checking on both the client IP address and the proxy IP address.

Anyway, that's good news. Thanks for letting us know!

[M Amine]

Message edited so readers won't get confused. Thank you vm @Bruno Vincent