12. Rate limiting#
Nubus doesn’t provide rate limiting for its APIs and services. If you expose an API or service to a network outside the Nubus deployment, you’re responsible for placing a reverse proxy, API gateway, or comparable component in front of it that enforces rate limiting.
12.1. What rate limiting protects against#
Rate limiting in front of an exposed API is a security hardening measure that reduces the risk of unauthorized automated use, such as:
- Credential stuffing and password guessing
Automated, high-volume attempts to authenticate, for example, against the Keycloak token endpoint or a sign-in page.
- Scraping and data harvesting
Automated, high-volume read requests against APIs that return directory or portal data.
- Denial of service through resource exhaustion
A high volume of requests, legitimate or not, that degrades the service for other users.
12.2. Generic implementation guide#
Implement rate limiting at the HTTP proxy or gateway layer in front of the Nubus component. This keeps the enforcement point independent of the application. It also lets you apply the same mechanism consistently across exposed APIs.
Consider the following aspects when you design your rate limiting:
- Identify the client
Rate limit anonymous or pre-authentication traffic per client IP address. Examples include requests to a token or sign-in endpoint. For authenticated traffic, consider rate limiting per authenticated identity, such as an API client or subscription name, in addition to, or instead of, the client IP address. Per-identity limiting prevents a shared IP address, for example, behind a NAT gateway, from penalizing every user behind it.
- Distinguish expensive and sensitive endpoints from cheap ones
Apply stricter limits to endpoints that perform authentication, change state, or are computationally expensive, such as a token endpoint, a sign-in form, or a password reset request. Apply more permissive limits to inexpensive, read-only endpoints.
- Allow for legitimate bursts
A limit based only on a long-term average request rate can still allow a damaging short burst of requests. A limit that’s too strict for short bursts can reject legitimate usage patterns. For example, a client might retry after a network interruption to catch up on pending requests. Most reverse proxies let you configure both a sustained rate and a burst allowance.
- Respond consistently
When you reject a request because it exceeds the limit, respond with the HTTP status code
429 Too Many Requests, and, where your proxy supports it, aRetry-Afterheader that tells the client when to retry. This lets well-behaved clients back off correctly, instead of retrying immediately and adding to the load.- Exempt trusted, internal traffic where appropriate
Some Nubus components already distinguish trusted internal callers from external callers for their built-in protections. For details, see Management UI. Apply the same principle at your proxy. Use a policy for traffic from your infrastructure that differs from the policy for internet traffic.
- Combine rate limiting with account lockout
Rate limiting throttles request volume. It doesn’t replace account lockout after repeated failed sign-in attempts.
Nubus supports account lockout as a separate, opt-in mechanism in both deployments. For Keycloak-backed sign-in, see Keycloak authentication APIs. For the directory service in both deployments use the approach for OpenLDAP, see Directory Service.
12.3. Monitor and alert on throttling#
Configure your reverse proxy or API gateway to log rejected requests.
Monitor the resulting 429 responses.
Configure an alert for a sudden increase in throttled requests
against a specific API.
Such an increase can indicate an automated abuse attempt,
even when the rate limit protects the backing service.
Investigate and respond to the attempt.
12.4. Configure rate limiting#
For deployment-specific configuration guidance, see:
For Nubus for Kubernetes: Rate limit externally exposed services in Univention Nubus for Kubernetes - Operation Manual [1].
For Nubus for UCS: Rate-limiting approaches for externally exposed services in Nubus for UCS - Operation Manual [2].
12.5. Nubus APIs to consider for rate limiting#
This section gives an overview of the APIs and services in scope, whether Nubus exposes them externally by default, and how each of them authenticates requests.
12.5.1. Keycloak authentication APIs#
Keycloak is an identity provider. It exposes OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) endpoints. Other components and third-party applications use these endpoints to sign in and retrieve tokens.
The /realms/REALM_NAME/protocol/openid-connect/token endpoint provides tokens.
Replace REALM_NAME with the Keycloak realm name.
Wherever Keycloak is in use, its token endpoint is intentionally reachable without an existing session. Callers authenticate directly with client credentials or a username and password. This makes the token endpoint a target for credential stuffing and password-guessing at high request volume.
Overview
- Authentication
OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) identity provider. The token endpoint itself accepts client credentials or a resource owner password without a prior session.
- Built-in abuse protection
No protection by default.
- Exposed by default
Yes, exposure by default.
Nubus for Kubernetes deploys Keycloak as the domain’s identity provider by default and exposes it externally by default.
Important
Nubus for Kubernetes deploys with the optional Keycloak Extensions deactivated by default. Without them, Keycloak has no brute force protection at all beyond a basic, username-only lockout counter. With them enabled, brute force protection still only covers the interactive sign-in page, not direct requests to the token endpoint.
No exposure by default. Nubus for UCS has single sign-on deactivated by default.
If you install the optional Keycloak app, it activates single sign-on.
See also
- Single sign-on
in Nubus for UCS - Operation Manual [2] for information about single sign-on and the Keycloak app in Nubus for UCS.
- Brute force protection
in Univention Nubus for Kubernetes - Architecture Manual [8] for information about the brute force protection for the Keycloak sign-in page, and why it doesn’t cover direct token endpoint requests.
- Keycloak Extensions
in Univention Nubus for Kubernetes - Operation Manual [1] for how to enable the Keycloak Extensions.
12.5.2. UDM HTTP REST API#
For the full description of the UDM HTTP REST API, see UDM HTTP REST API in Nubus - Customization and Modification Manual [5]
For API exposure and rate-limiting requirements, see UDM HTTP REST API in Nubus - Customization and Modification Manual [5].
Overview
- Authentication
HTTP Basic authentication against a directory account.
- Built-in abuse protection
None.
- Exposed by default
No exposure by default. You can activate it through
nubusUdmRestApi.ingress.enabled.Follows the exposure of the Primary Directory Node.
12.5.3. Provisioning API#
For the full description of the Provisioning API, see Provisioning API in Nubus - Customization and Modification Manual [5].
For API access and rate-limiting requirements, see Access to Provisioning API endpoint in Nubus - Customization and Modification Manual [5].
Overview
- Authentication
HTTP Basic authentication with subscription or administrator credentials.
- Built-in abuse protection
None.
- Exposed by default
No exposure by default, because ingress is deactivated.
No exposure by default. After you install the Provisioning API app it follows the exposure of the Directory Node that has the app installed.
12.5.4. Directory Service#
Nubus provides directory access through LDAP, served by OpenLDAP. It isn’t an HTTP API, so the generic HTTP-proxy rate limiting guide in Generic implementation guide doesn’t apply to it directly.
Overview
- Authentication
LDAP simple bind.
- Built-in abuse protection
None by default. Optionally, an OpenLDAP password policy locks out an account after repeated failed binds.
- Exposed by default
No exposure by default, The cluster-internal
ClusterIPservice by default.Univention recommends that third-party services connect through the LDAP proxy instances rather than directly to the primary LDAP instances. See Directory service high availability and scalability in Univention Nubus for Kubernetes - Operation Manual [1].
It follows the exposure of the Directory Node that provides the directory service.
Nubus for UCS optionally supports account lockout after repeated failed LDAP binds through an OpenLDAP password policy. This is a lockout, not rate limiting: it blocks an account after a threshold of failures instead of throttling request volume, and it’s off by default.
Important
If you need to expose LDAP to a network outside Nubus, for example, for an external directory synchronization, use network-level controls instead of an HTTP proxy. Use one of the following controls:
Firewall rules that allow only a limited set of remote networks.
A virtual private network (VPN).
Connection-count and rate limiting at the load balancer or an LDAP-aware proxy.
See also
- Configure lockout for OpenLDAP
in Nubus for UCS - Operation Manual [2] for how to configure the OpenLDAP password policy lockout.
12.5.5. Management UI#
The Management UI is the core management interface of Nubus. Nubus exposes the Management UI externally by default in Nubus for Kubernetes and Nubus for UCS.
Overview
- Authentication
OIDC sign-in through Keycloak, then a server-side session.
Local sign-in by default, or SAML through Keycloak if you install and activate it.
- Built-in abuse protection
The self-service management module, used for actions such as password reset and contact verification, already has built-in rate limiting for repeated requests from the same client, backed by Memcached. See Restrict users or groups from capabilities in End User Self Service in Univention Nubus for Kubernetes - Operation Manual [1].
Sign-in: No protection by default. Optionally, a PAM account lockout.
- Exposed by default
Yes, exposure by default.
Nubus for Kubernetes authenticates UMC users through Keycloak, followed by a server-side session.
Yes, exposure by default. The Management UI is the core UCS management interface.
Nubus for UCS signs users in locally by default, or through Keycloak if you install and activate single sign-on, see Keycloak authentication APIs.
Nubus for UCS optionally supports an account lockout after repeated failed sign-in attempts, through the PAM stack that UMC authenticates against. As with the OpenLDAP lockout, this blocks an account after a threshold of failures instead of throttling request volume, and it’s off by default.
Important
The self-service rate limiting only covers the self-service module. The rest of the UMC API surface, including its sign-in and session endpoints, has no rate limiting of its own.
See also
- User account lockout after failed sign-in attempts
in Nubus for UCS - Operation Manual [2] for how to configure account lockout after failed sign-in attempts, including for the PAM stack that UMC uses.
12.5.6. Portal#
The Portal is the domain’s landing page in Nubus. It exposes anonymous, static content and endpoints that reflect the signed-in user’s session, such as personalized navigation.
Overview
- Authentication
Session cookie for personalized content. Most static content is anonymous.
- Built-in abuse protection
None.
- Exposed by default
Yes, exposure by default.
Yes, exposure by default. The Portal is the domain’s default landing page.
Consider rate limiting for the Univention Portal for the following reasons:
Protect authenticated, session-bound endpoints against abuse.
Protect anonymous, static endpoints against scraping and high-volume automated requests.
12.5.7. Guardian#
The Guardian is the authorization engine for Nubus. It runs Cerbos as the policy decision point, and Nubus doesn’t expose it externally by default.
Overview
- Authentication
No authentication on its own.
- Built-in abuse protection
None.
- Exposed by default
No exposure by default.
No, exposure by default.
Important
Cerbos trusts every caller that can reach it and has no authentication of its own. If you build custom infrastructure to expose the Guardian outside its trusted network, add both authentication and rate limiting in front of it.