Deploying UAA for external users #cf #uaa


Shetty, Viraj S [CTR]
 

We want to deploy UAA for external users of the organization. This UAA deployment would only be used by external users and so some of the URLs would have to be exposed to the internet. But I want a large part of the UAA api urls like /identityzones, /groups, /users etc to not be exposed to the internet (this is for extra security). The only URLs that really need to be exposed are the ones which is useful for the OAuth 2 flows for external users. I can use the IP filtering mechanism to remove access to these URLs. Can I do this in the uaa.yml file and if so - is there a known set of URLs which are normally exposed in these conditions? I would rather whitelist a set of URLs. Any help is appreciated. 


Enrique Cano
 

I would expect you place a well hardened reverse proxy in front of your UAA, and that is what you use to control what is exposed to the outside world and what is not?

Regards

Enrique


Shetty, Viraj S [CTR]
 

Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml. I can also probably check all the URLs used for a authentication_code or client_credentials flow using chrome and then whitelist only those. However, I am trying to see if this list is documented anywhere that I can simply use it. 

Thanks,
Viraj 


Jonathan Matthews <contact+cfdev@...>
 

On Tue, 21 Jul 2020 at 14:07, Shetty, Viraj S [CTR] via lists.cloudfoundry.org <vshetty=fdic.gov@...> wrote:
Thanks Enrique. We are deploying UAA in cloud.gov for our agency and it will be used by applications deployed in cloud.gov for our agency. I can add a nginx proxy in front but I think I should be able to filter IP addresses with spring or in the web.xml

Just in case this is useful to you, I suggest taking a look at the CF (hence probably also cloud.gov) feature called “Route Services”. 

Using this platform feature would allow you to deploy a vanilla UAA and decouple it (as an app) from its layer 4 / layer 7 protection.

Nginx can be used as a WAF in that topology, as can Haproxy or anything else reverse-proxy-ish. 

Personally, I’d chose that over relying on a block-/allow-list feature in the UAA itself, where you’d be dependent both on the feature’s presence and its correctness with no regressions over time. 

My 2¢ :-)

Jonathan
--
Jonathan Matthews
https://jpluscplusm.com


Shetty, Viraj S [CTR]
 

Thanks Jonathan. I will take a look at that.