Configuring PrivacyIDEA Node For Push Proxying

Working on testing push tokens. I’ve got the firebase projects setup for IOS and Android as well as the firebase SMS provider setup in PrivacyIDEA. Since part of the traffic flow involves outside devices communicating with PrivacyIDEA across the internet, what would be the best way to proxy these requests to PrivacyIDEA without directly exposing the PrivacyIDEA server?

Would setting up a separate PrivacyIDEA server exposed to the internet and proxying the token authentications be the way to do it? I haven’t seen what port/protocols are being used for this inbound traffic, is it “standard” HTTPS traffic?

Hi,
we use a Web Application Firewall to expose just the necessary endpoints to the www.

2 Likes

Ya, we have a WAF that will go in front of it as well and planned on only allowing the specific endpoint through. Just wondering if it’s worth putting another device in front of it for when the compromise occurs. Do we want just the WAF or a WAF plus another proxying device. If the WAF is compromised, then is it open season on hitting the server that connects directly to AD and contains your user’s tokens or do we make it mildly more difficult by adding another device layer to reach the primary PrivacyIDEA server?

It is all HTTPS.

You could put one privacyIDEA node in the DMZ and in addition by means of policies (e.g. based on the privacyIDEA node) only allow the push communication.

Would this DMZ node proxy the information to an internal PrivacyIDEA node, or would the DMZ node communicate with AD and store tokens on it itself?

I just noticed this in the documentation, would the federation handler module be used to forward these requests? Or is the whole idea of putting another box in front unnecessary?

https://privacyidea.readthedocs.io/en/latest/eventhandler/federationhandler.html#federationhandler

The DMZ node would be a full featured mode, just with a more restrictive policy set.
So yes, I understand that you are looking for a stronger separation, just wanted to drop this for completeness.

The Federation handler would in theory be used to forward requests from one privacyIDEA machine to a complete independent privacyIDEA machine. The original idea was to have independent privacyIDEA machines in different departments and a central machine, that gets all requests and sends these requests to the destinct departmnet.

It was intended and tested with /validate/check - I do not know if it works in a sensible way with other endpoints.