Tailoring Website Security with Kademi’s Custom IDP Rules

When you run a partner portal or incentive program, some security decisions depend on how your program operates. A particular function may need to be restricted to an approved group. Repeated login failures may warrant a temporary account lockout. A sensitive request may need to notify an administrator while remaining permitted.

Kademi’s global Intrusion Detection and Prevention (IDP) policy provides a shared baseline for handling specified suspicious requests and activity patterns. Custom rules let you address additional requirements for your website.

The starting point is the behavior you want to manage. What should the platform check, when, and how should it intervene? Understanding those choices helps you turn a security requirement into a clear brief for your technical team.

Kademi supports both a global IDP policy and website-level policies. This article focuses on website-level customization; for an overview of the shared protections, read How Kademi’s Global IDP Policy Helps Protect Your Website.

How custom IDP rules work

Kademi’s IDP framework filters requests within the application. Each rule pairs a condition with an action.

The condition identifies something you want to respond to. It might concern a source IP address, a requested page, information submitted with a request, or the number of login failures recorded during a particular period.

The action determines the response. A matching request could be rejected, logged, or used to trigger an administrator notification. Some actions affect subsequent activity, such as adding an IP to a list or temporarily preventing an account from logging in.

You can combine conditions to make a rule more specific. For example, a restriction could apply when a request targets a particular endpoint and arrives outside an approved host. Other rules might match any of several conditions or include an explicit exception.

Actions can also be combined. A rule could block a request and record the event, or add its source IP to a blocklist as well.

This gives you control over both the activity being identified and the response it receives. Website-level policies use the same underlying framework as Kademi’s global policy, with rules configured for the needs of an individual site.

Where custom rules can help

Restricting traffic from selected sources

You may have a requirement to allow requests from approved networks or restrict traffic from selected sources.

Custom conditions can check named IP lists, individual addresses, address prefixes, and IPv4 or IPv6 network ranges. A rule can also add a matching request’s source IP to a named list for subsequent rules to check.

Country-based restrictions are available through IP geolocation. For example, a rule could reject and log requests associated with a configured list of countries.

The country is inferred from the source IP address, so this should be understood as a network-location check. It does not establish a person’s nationality or exact physical location.

Before choosing a restriction, consider how legitimate users connect. A corporate VPN or shared network may affect the address or country visible to the application. Approved services and internal systems may also need carefully scoped exceptions.

Applying controls to particular website functions

Sometimes the requirement concerns one part of your website rather than its traffic as a whole.

A custom rule can match a requested path, the host receiving the request, and the request method. This allows you to distinguish, for example, a request to view a page from a POST request submitting information to a particular endpoint.

You could use these conditions to block an endpoint entirely on one website or restrict it outside an approved host.

For more specific requirements, the framework can inspect request headers, submitted form values, and other URL or request properties. It also supports matching against paths supplied dynamically by active Kademi apps.

These details help narrow the rule to the activity you actually want to manage. A condition aimed at one sensitive function can be more appropriate than applying the same response across the entire website.

Using authenticated user and request-token information

Access decisions may depend on who is making the request.

Where an authenticated user context is available, custom rules can check whether the user belongs to one or more specified groups. Combined with a path condition, this can support restrictions around a particular function or area of the site.

The framework also supports validation of Kademi’s CSRF request token, checking its signature and age. This provides another input for rules that need to consider token validity.

These checks serve different purposes. Group membership uses authenticated identity information; token validation checks the relevant request token. Your technical team can determine which information is available and appropriate for the requirement.

Responding to repeated login failures

A single failed login is usually a different situation from repeated failures against the same account. Custom rules can use measurements over a rolling time window to distinguish between them.

For example, a rule could temporarily prevent an account from logging in after more than 10 failed logins within 10 minutes, with a 30-minute lockout.

This is an illustrative custom rule, not a setting included in the shared global policy. The threshold, measurement window, and lockout duration should reflect your requirements.

Account lockout also differs from IP blocking. The login metric can count failures against a username, allowing the response to target the account. An IP-based rule instead responds to activity associated with a source address.

The available metrics extend beyond failed logins. Rules can use successful login counts, request volumes, specified response codes, and average response times. Depending on the metric, activity can be measured per IP, per authenticated user, or across all traffic.

Metrics can also be limited to matching requests, such as a particular path or method. That helps you measure the activity relevant to a rule rather than mixing it with unrelated traffic.

Adjusting traffic limits to performance

A fixed request threshold may be useful for some requirements. For others, you may want the permitted rate to change with application performance.

Kademi’s adaptive limiter uses a request-count measurement alongside another metric, such as average response time. Faster responses can permit a higher request rate; as responses slow, the allowed rate decreases.

The configured rule then determines what happens when the limit is exceeded. One response is to stop the request and return 429 Too Many Requests.

As with other custom controls, the measurement scope and response need to be configured. The presence of this capability does not mean a particular limiter is already active on your website.

Making important activity visible

Not every event calls for a block. Sometimes you need to know that something happened while allowing normal processing to continue.

Consider a sensitive export function. A custom rule can identify a POST request to its path and queue an email to administrators. That notification tells the team that the request was received; it does not, by itself, confirm that an export completed or that data was accessed.

Rules can also write events to the IDP request log or capture selected request data in a time-series store for monitoring and analysis. Captured fields can include the source IP, URL, request method, host, and user-agent information.

Event collection can use sampling and limits on the number of records captured per minute. You can therefore define what information to collect and how much, rather than assuming every matching request must be stored.

Logging and notification are useful responses in their own right. They can also accompany a blocking or account-lockout action when a record of the event is needed.

Choosing the response that fits the requirement

Once you have identified the activity, decide how far the response should reach.

• Does the current request need to stop? A rule can reject it and set an appropriate response status.

• Should the response affect future activity? You can add the source IP to a named list that later rules check, or lock an account out of login. Account lockouts can have a configured duration or be indefinite.

• Does your team need visibility? Logging, administrator emails, and selected event capture may provide the information needed without blocking the request.

These choices can be combined, but each action should serve the requirement. A notification about a sensitive request does not necessarily need an IP block. A temporary account lockout may be more relevant than rejecting all requests from a shared network.

You can also configure what the browser or calling application receives. The framework supports response status codes, content, content types, and headers. That allows a browser request to receive an explanatory page while an API request receives a structured response appropriate to its caller.

The response is part of the rule’s design, not simply an error message added afterward.

Turning your requirements into working rules

You do not need to write the configuration to explain the outcome you want.

A useful brief for your technical team should identify:

• The activity: Which endpoint, traffic source, account behavior, or request pattern needs attention?

• The trigger: Which conditions must match, and is a threshold or time window involved?

• The response: Should the request be allowed, rejected, logged, or used to trigger another action?

• The exceptions: Which approved users, networks, services, or hosts need different treatment?

Rules are currently authored in XML; the supplied configuration model does not include a visual rule builder. Implementation therefore requires technical configuration, even when the requirement itself can be expressed in a straightforward sentence.

Rule order also deserves attention. An explicit allow action lets a request proceed without evaluating the remaining IDP rules. An exception that is too broad could therefore skip checks you intended to apply. Allowing a request through IDP does not remove the application’s normal authentication and permission requirements.

Before introducing a rule, review its expected effect on legitimate activity as well as the behavior it is intended to address. Test the matching conditions and exceptions, confirm that identity-dependent checks have the required authenticated context, and agree on the information needed to assess the result.

Start with the behavior you want to manage

Kademi’s custom IDP rules give you several ways to address website-specific requirements: restrict access, respond to repeated activity, adjust traffic limits, or make sensitive requests visible to your team.

You do not need to use every capability. The useful starting point is a clear description of what should happen on your website and under which circumstances.

Discuss those requirements with the Kademi team to identify the appropriate conditions, responses, and exceptions. Together with the global policy, that gives you a defined set of controls aligned with how your program operates.