Information security · Federation · 3 min read
Locking Down a Federation Server: Expose Only What You Must
Short answer
Keep the federation server's admin console off the internet, publish only the runtime endpoints your partners and apps actually use through a reverse proxy or rewrite rules that allowlist paths and methods, and send security headers such as HSTS on every response.
Key takeaways
- The admin console and admin API belong on a management network, never on the public listener.
- Allowlist the protocol endpoints you use (SAML SSO, OAuth authorize and token, JWKS, metadata) and return 404 for everything else.
- Rewrite or proxy rules are defense in depth; patching and configuration review still come first.
A federation server is one of the most sensitive systems you run. It holds signing keys that every connected application trusts and it sees every sign-in. Yet in many deployments it is published to the internet with its full set of endpoints, including features nobody uses. Shrinking that surface is cheap and effective. The examples below mention PingFederate, Ping Identity's self-managed federation server, but the approach applies to AD FS, Keycloak, Shibboleth and others.
What should never be exposed?
The administrative console, the admin API and any endpoint for features you have not enabled.
PingFederate separates its administrative node and runtime engine, and by default listens on different ports for each (9999 for admin, 9031 for runtime). Keep the admin listener bound to a management network reachable only through a bastion or VPN with MFA. In clustered setups, the console node does not need a public interface at all.
Unused endpoints are the second category. If you only use SAML IdP features and OAuth authorization, there is no reason for WS-Trust STS endpoints, SP features or legacy protocols to be reachable from outside.
How do I allowlist endpoints?
At a reverse proxy or web application firewall in front of the runtime, permit only known paths and methods, and return 404 for the rest.
Make the list from what you use. For an IdP that serves SAML SSO and OAuth/OIDC, typical paths include the SAML SSO and SLO endpoints, the OAuth authorization and token endpoints, the JWKS and OpenID discovery documents, metadata, and the sign-in pages' static assets. PingFederate's own endpoints include paths such as /idp/SSO.saml2, /as/authorization.oauth2, /as/token.oauth2 and /pf/heartbeat.ping; check your version's documentation for the full list.
An nginx sketch:
location ~ ^/(idp/SSO\.saml2|idp/SLO\.saml2|as/authorization\.oauth2|as/token\.oauth2|pf/JWKS|\.well-known/openid-configuration)$ {
proxy_pass https://pf-runtime:9031;
}
location /assets/ { proxy_pass https://pf-runtime:9031; }
location / { return 404; }
Then restrict methods: the token endpoint accepts POST, discovery and JWKS accept GET. Keep the heartbeat endpoint for the load balancer on an internal listener.
Why use rewrites inside the server?
When there is no proxy, or as a second layer behind one.
PingFederate runs on embedded Jetty, and Jetty's rewrite handler can match paths and redirect, rewrite or respond. That was a common technique in older versions and still works as defense in depth. The downside is that changes live in product configuration files, which upgrades may replace, so document and re-apply them as part of each upgrade.
Which headers should a federation server send?
HSTS, X-Content-Type-Options, a frame-ancestors restriction and a sensible Referrer-Policy at minimum.
Clickjacking a sign-in page and downgrading to HTTP are both realistic attacks. Current PingFederate versions let administrators add custom response headers through response-header-runtime-config.xml (runtime) and response-header-admin-config.xml (console) in the server's config store, followed by a restart. The HSTS on Jetty-based servers article covers HSTS specifically, and the Security Header Builder produces header sets for nginx, Apache, IIS, Jetty and static hosts.
What else belongs on the hardening list?
Patching, key protection, strict metadata, logging and regular configuration review.
| Area | Practice |
|---|---|
| Patching | Track vendor advisories; test and upgrade on a schedule |
| Signing keys | HSM or protected keystore; planned rollover with overlap |
| Partners | Exact ACS and redirect URLs; signed metadata where possible |
| Protocols | Disable unused grant types, bindings and legacy algorithms (SHA-1 signatures) |
| Logging | Ship audit and server logs centrally; alert on admin changes |
| Admin access | MFA, named accounts, least privilege roles |
The OWASP SAML Security Cheat Sheet is a good checklist for the SAML side. For a neutral overview of the product, see our PingFederate page.
Questions
Which PingFederate ports are used by default?
By default PingFederate's administrative console listens on port 9999 and the runtime engine on 9031. Most deployments change the bindings and put a reverse proxy or load balancer in front of the runtime port.
Can I do this with Jetty rewrite rules instead of a proxy?
PingFederate runs on an embedded Jetty server, and Jetty's rewrite module can block or redirect paths. A reverse proxy is usually easier to manage and audit, and keeps the rules outside the product's configuration, which helps during upgrades.
Sources
Tagged: PingFederate, Ping Identity, Federation, Apache HTTP Server, nginx, Jetty, Security