Openfire
Openfire copied to clipboard
igniterealtime
OF-2474: IP-based access control for the admin console
This adds an 'allow' and 'block' list of IP(v4) addresses, that controls access to the admin console.
A third property is added that can be used to configure if these lists should also be applied when accessing pages that are otherwise 'excluded' from access control by the AuthCheckFilter.
An admin console page has been added to easily configure the new properties.
When trying to set an invalid IP address in the Admin console, the value returns the previous value rather than allowing me to correct it. Is this the same behaviour in the rest of the Admin console?
When using a proxy that passes the X-Forwarded-For, and adminConsole.forwarded.enabled is set, the page correctly shows the client IP address.
When the proxy address is added to the blocklist, the proxy (and its clients) are not blocked. Intentional behaviour?
When trying to set an invalid IP address in the Admin console, the value returns the previous value rather than allowing me to correct it. Is this the same behaviour in the rest of the Admin console?
This is the same behavior in the rest of the Admin Console, but we should do better. I've now pushed a change that will populate the input fields with the unsaved / erroneous input values.
I've also modified the error messages to be more explicit in the fact that none of the settings have been saved. This should rule out any misconception in that other values (that were not erroneous) might have been saved.
When the proxy address is added to the blocklist, the proxy (and its clients) are not blocked. Intentional behaviour?
I'm not sure if I interpret what you're asking correctly. When a proxy is in play (and adminConsole.forwarded.enabled is enabled), the intentional behavior (which as far as I'm concerned can be up for debate), is that the blocklist and allowlist apply to the IP addresses of the clients as seen by the proxy (the client's "public" address).
Do we need to worry about a rogue proxy server being used?
That makes sense. I've confirmed that the help text shown on the page uses the correct client IP when adminConsole.forwarded.enabled is set to True. Is there an argument for making that property true by default for new installations?
Moreover, I'm in favour of merging this and tweaking it if/when we receive feedback
On the topic of a rogue proxy, that's an industry-wide problem, and not something we should try to solve, I think
Is there an argument for making that property true by default for new installations?
Maybe - the same could be said for the very similar property that's used by BOSH. The downside is that it would, by default, allow clients to 'spoof' their IP by using a X-Forwarded-For header.
If we do decide to change the default, let's take that on under a different issue number.
On the topic of a rogue proxy, that's an industry-wide problem, and not something we should try to solve, I think
Makes sense.