Methods for evaluating a radius request

Abstract

It is provided a method for evaluating whether to provide a RADIUS request to a RADIUS server (3), the method being performed by a rule evaluation server (1). The method comprises: extracting (40) at least one value of an attribute of a RADIUS request (22) from a RADIUS client (4), the RADIUS request (22) being addressed to the RADIUS server (3); obtaining (44) a rule set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access; evaluating (46), in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request (22), until a matching access rule, whose trigger condition is true, is found; and providing (48) the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to reject access.

Description

METHODS FOR EVALUATING A RADIUS REQUESTTECHNICAL FIELD

[0001] The present disclosure relates to the field of evaluation of Remote Authentication Dial-In User Service (RADIUS) requests, and in particular to whether to provide a RADIUS request to a RADIUS server.BACKGROUND

[0002] Remote Authentication Dial-In User Service (RADIUS) is a widely used protocol for managing authentication, authorisation, and accounting (AAA) in network access scenarios. It enables centralised control of network access by validating user credentials and enforcing access policies. RADIUS is commonly employed in environments such as enterprise networks, wireless access points, virtual private networks (VPNs), and Internet Service Providers (ISPs).

[0003] In a typical RADIUS-based architecture, a Network Access Server (NAS) acts as a RADIUS client to the RADIUS server, transmitting a RADIUS request based on access requests from users or devices. The RADIUS server processes these RADIUS requests by evaluating various attributes, such as user credentials, device identifiers, and network location. Based on this evaluation, the server responds with an Access-Accept, Access-Reject, or Access-Challenge message, which the RADIUS client can enforce based on the response from the RADIUS server.

[0004] The increasing complexity of modern networks has led to the deployment of multi-tenant systems, hierarchical network structures, and diverse device types, such as loT (Internet of Things) devices and headless systems. These developments necessitate more sophisticated mechanisms for managing and evaluating access requests. Central to this is the ability to define and enforce flexible, granular access policies that account for variables such as device type, user roles, network location, and security requirements.

[0005] The RADIUS implementations of today rely on policy engines that evaluate attributes within access requests, for example, by comparing attributes such as NAS identifiers, Called Station Identifiers, and usernames against predefinedconditions. However, the policies of the RADIUS server are limited in their scope and flexibility.SUMMARY

[0006] One object is to improve flexibility and granularity of how a RADIUSbased system evaluates access.

[0007] According to a first aspect, it is provided a method for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server. The method is performed by a rule evaluation server. The method comprises: extracting at least one value of an attribute of a RADIUS request from a RADIUS client, the RADIUS request being addressed to the RADIUS server; obtaining a rule set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access; evaluating, in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request, until a matching access rule, whose trigger condition is true, is found; and providing the RADIUS request to the RADIUS server based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request to the RADIUS server based on the action of the matching rule being to reject access.

[0008] The method may further comprise: extracting a rule set identifier from one of the at least one value of an attributes. In this case, the obtaining the rule set comprises finding the rule set based on the rule set identifier.

[0009] The evaluating the trigger conditions may comprise, for at least one trigger condition, evaluating a transformed representation of an address of a device requesting access against a set of transformed representations.

[0010] The evaluating the trigger conditions may comprise, for at least one trigger condition, evaluating a value of one of the following attributes of the RADIUS request: an identifier of a network access server, NAS, an identifier of a called station, an identifier of a calling station, and / or a user name.

[0011] The rule set may comprise an access rule to inherit a rule set of a parent node.

[0012] There may be an explicit or implicit rule to reject the RADIUS request if the trigger conditions of all evaluated rules are false.

[0013] The providing the RADIUS request may comprise providing an indicator of the matching rule.

[0014] The rule set may comprise a plurality of access rules.

[0015] According to a second aspect, it is provided a rule evaluation server for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server. The rule evaluation server may comprise: processing circuitry; and memory circuitry storing instructions that, when executed by the processing circuitry, cause the rule evaluation server to: extract at least one value of an attribute of a RADIUS request from a RADIUS client, the RADIUS request being addressed to the RADIUS server; obtain a rule set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access; evaluate, in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request, until a matching access rule, whose trigger condition is true, is found; and provide the RADIUS request to the RADIUS server based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request to the RADIUS server based on the action of the matching rule being to reject access.

[0016] The rule evaluation server may comprise the RADIUS server.

[0017] According to a third aspect, it is provided a computer program for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server. The computer program comprising computer program code which, when executed on a rule evaluation server causes the rule evaluation server to: extract at least one value of an attribute of a RADIUS request from a RADIUS client, the RADIUS request being addressed to the RADIUS server; obtain a rule group set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access; evaluate, in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request, until a matching access rule, whose trigger condition is true, is found; and provide the RADIUS request to the RADIUS serverbased on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request to the RADIUS server based on the action of the matching rule being to reject access.

[0018] According to a fourth aspect, it is provided a computer program product comprising a computer program according to the third aspect and a computer readable means comprising non-transitory memory in which the computer program is stored.

[0019] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0021] Figs 1A-B are schematic diagrams illustrating environments in which embodiments presented herein can be applied;

[0022] Fig. 2 illustrates an example hierarchy structure for managing rule sets in a RADIUS-based access control system;

[0023] Fig 3 is a swimlane diagram illustrating embodiments of methods for evaluating whether to provide a RADIUS request to a RADIUS server;

[0024] Fig 4 is a schematic diagram illustrating components of the rule evaluation server of Fig 1 or Fig 3;

[0025] Fig 5 shows one example of a computer program product 90 comprising computer readable means;DETAILED DESCRIPTION

[0026] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0027] According to embodiments presented herein, it is provided a more flexible and granular solution to controlling access in a RADIUS system. This is achieved by evaluating a set of access rules for each RADIUS request. Each access rule is configured with a trigger condition and an action. The trigger condition is evaluated based on an incoming RADIUS request and its attributes. The action can be to reject or to accept, where a reject action causes a rejection of the RADIUS request, and an accept leads to conventional RADIUS server processing to occur. There can be an arbitrary number of access rules, providing fine-grained control and granularity for access control.

[0028] Figs 1A-B are schematic diagrams illustrating environments in which embodiments presented herein can be applied. It is shown a system architecture for managing access requests in a RADIUS-based network environment. It is illustrated a requesting device 2, a RADIUS client 6, a rule evaluation server 1 and a RADIUS server 3. It is to be noted that while RADIUS technically refers to dial up, this is only because RADIUS was originally specified at the time when dial up connections were common. In fact, RADIUS can be applied for any scenario where network access is requested.

[0029] It is to be noted that whenever the terms “rule evaluation server” and “RADIUS server” are used herein, unless otherwise specific, these terms relate to any implementation of the respective functionalities as described herein.

[0030] Looking to Fig 1A, it is provided a RADIUS evaluation system 7 which includes the rule evaluation server 1 and the RADIUS server 3. The rule evaluation server 1 and the RADIUS server 3 can be different logical entities forming part of the same physical entity. In this case, the RADIUS evaluation system 7 can be implementedby based on a RADIUS server with modifications to implement the embodiments presented herein.

[0031] The requesting device 2 represents any user device or endpoint seeking access to a network. Examples of such devices include laptops, smartphones, loT devices, or any network-enabled hardware that connects to the network through a RADIUS-controlled access mechanism. The requesting device 2 communicates its access request to the RADIUS client 6.

[0032] The RADIUS client 6 serves as the intermediary between the requesting device 2 and the RADIUS evaluation system 7. It processes the access request from the requesting device 2, extracting the relevant attributes such as user credentials, device identifiers, or network parameters and forwarding the request to the RADIUS evaluation system 7. The RADIUS client 6 could be implemented as a network access server (NAS), such as a wireless access point, switch, or VPN concentrator. The RADIUS client 6 generates a RADIUS request based on the access request from the requesting device 2, and transmits the RADIUS request to the RADIUS evaluation system 7.

[0033] The RADIUS evaluation system 7 performs access control functions for evaluating whether the requesting device 2 should be allowed access. More specifically, the rule evaluation server 1 evaluates the attributes of the received RADIUS request against a set of access rules to determine whether the request should be allowed or denied, as described in more detail below. This evaluation is based on any standard attributes or Vendor Supplied Attributes (VSAs) such as NAS identifiers, device addresses, user names, or other conditions defined in the access rules. The RADIUS server 3 may perform additional authentication, authorisation, and accounting functions based on the outcome of the rule evaluation server 1.

[0034] In operation, the rule evaluation server 1 processes the RADIUS request that is transmitted by the RADIUS client 6. The rule evaluation server 1 compares the attributes of the request against predefined access rules and makes a decision to either accept or reject the request. If access is granted, the RADIUS request is provided to the RADIUS server 3 for further handling, which may include assigning resources, or applying additional policies. If access is denied, a reject response is transmitted to the RADIUS client 6, either by the rule evaluation server 1 or by the RADIUS server 3.

[0035] Looking now to Fig 1B, the rule evaluation server 1 is implemented in a separate physical device from the RADIUS server 3. In this case, both the rule evaluation server 1 and the RADIUS server 3 can communicate with the RADIUS client 6.

[0036] Fig. 2 illustrates an example hierarchy structure for managing rule sets in a RADIUS-based access control system. The hierarchy includes a top-level node 10, intermediate nodes 11a and 11b, and leaf nodes 12a, 12b, 12c, and i2d. This structure facilitates the organisation, inheritance, and customisation of access rules across multiple levels. Wherever a relationship exists between a higher level node and a lower level node, the higher level node is herein denoted as a parent node and the lower level node is denoted a child node.

[0037] The top-level node 10 represents a centralised entity responsible for defining global access rules that apply across the entire hierarchy. These global access rules may include baseline security policies, default access control settings, or shared configurations applicable to all descendant nodes. The top-level node 10 could represent a large company controlling several brand chains of establishments. Alternatively, in an office connectivity embodiment, the top-level node 10 could represent a large company with several offices across one or multiple countries.

[0038] The intermediate nodes 11a and 11b are positioned directly beneath the top-level node 10 and serve as parent nodes for specific groups or subdivisions. These intermediate nodes can inherit access rules from the top-level node 10 and may define additional access rules specific to their respective groups. For example, a first node 11a could represent a particular brand chain, while a second node 11b could represent another brand chain. Alternatively, in the office connectivity embodiment, the first node 11a could represent groups of offices in one region or country, and the second node 11b could represent groups of offices in another region or country.

[0039] The leaf nodes 12a, 12b, 12c, and i2d represent the lowest level in the hierarchy. These nodes can inherit access rules from their respective parent nodes 11a and 11b. In addition to inherited access rules, each leaf node may include custom access rules tailored to specific requirements, such as individual sites, user groups, or device types. For example, leaf node 12a could define access rules for loT devices, while leafnode 12b could include access rules for guest users. The leaf nodes could represent individual establishments or individual office sites.

[0040] It is to be noted that the number of nodes at each level and the number of levels presented in Fig 2 is only an example and embodiments presented herein are applicable for any number of nodes and levels.

[0041] This hierarchical structure enables efficient management of access rules by allowing parent nodes to define shared rules that are automatically or explicitly inherited by child nodes. At the same time, child nodes can override or extend the inherited rules to address localised needs. The architecture is particularly beneficial in multi-tenant or large-scale deployments, where consistency across the hierarchy is essential but flexibility for individual nodes is also desired.

[0042] Fig. 3 is a swimlane diagram illustrating embodiments of methods for evaluating whether to provide a RADIUS request to a RADIUS server 3. The swimlane diagram can be considered to include a flow chart for methods performed by the requesting device 2 on the left, the RADIUS client 6 in the middle, and the rule evaluation server 1 on the right. Selected communication between the various entities is also shown.

[0043] In a request access step 140, the requesting device 2 initiates an access request 20 to a RADIUS client 6 to gain access to a network. This access request 20 can include attributes such as user credentials, device identifiers, or other information relevant to access evaluation. The access request 20 does not need to comply with RADIUS specifications.

[0044] In a receive access request step 240, the RADIUS client 6 receives the access request 20 from the requesting device 2. The RADIUS client 6 processes the access request and uses this as a base for preparing a RADIUS request for submission to the rule evaluation server 1. The RADIUS request complies with RADIUS specifications.

[0045] In a send RADIUS request step 242, the RADIUS client 6 sends the prepared RADIUS request 22 to the rule evaluation server 1. The RADIUS request includes attributes extracted from the access request.

[0046] In a receive RADIUS request step 38, the rule evaluation server 1 receives the RADIUS request 22 from the RADIUS client 6. This step marks the beginning of the evaluation process for determining whether the RADIUS request should be forwarded to the RADIUS server 3. The RADIUS request 22 is addressed to the RADIUS server 3.

[0047] In an extract attributes step 40, the rule evaluation server 1 extracts at least one value of an attribute of the RADIUS request, such as user credentials, device addresses, or NAS identifiers. These values are later used for evaluation of access rules, see e.g. Table 1 below.

[0048] In an optional extract rule set identifier step 42, the rule evaluation server 1 extracts a rule set identifier from one of the at least one value of an attributes of the RADIUS request. This rule set identifier is optionally used, as described for the obtain rule set step 44 below, to locate a specific set of access rules. The rule set identifier can be included in any suitable attribute value of the RADIUS request. For instance, the rule set identifier can be included as a prefix or suffix to the username, a prefix or suffix to the NAS identifier, the NAS identifier itself, or a prefix or suffix to called station identifier. The rule set identifier can be in any format that allows it to form part of an attribute value of the RADIUS request. For instance, the rule set identifier can be in the form of a 6-character case-sensitive alphanumeric string, offering more than 56 billion permutations in a compact and relatively legible representation.

[0049] In an obtain rule set step 44, the rule evaluation server 1 obtains a rule set comprising at least one access rule. In one embodiment, the rule set comprises a plurality of access rules. Including a plurality of access rules in a rule set enables more granular and flexible access control in a RADIUS-based system. It allows the evaluation of multiple conditions sequentially, facilitating nuanced decision-making based on various attributes such as NAS ID, MAC address, or username (described in more detail below). This structure supports scalable and maintainable policy management, where general and specific rules can coexist within the same framework. It also enables fallback handling, ensuring appropriate defaults or exceptions are applied when higher-priority rules do not match.

[0050] Each access rule includes a trigger condition and an action. The trigger condition specifies under what circumstances the access rule is triggered, and the action specifies whether to accept or reject access when the rule is triggered. The rules can beobtained from a database. Optionally, one or more of the rule sets are cached in transitory memory that is accessible to the rule evaluation server 1. Optionally, when the extract rule set step 42 has been performed, the rule set is located and obtained based on the extracted rule set identifier.

[0051] Optionally, the rule set includes a rule to inherit a rule set of a parent node. In this case, the rule set of the parent node is also obtained and combined to the other rules of the obtained rule set. The inheritance enables the creation of rule sets that are propagated from a parent node to one or more child nodes, while the child node(s) can still have additional access rules in a more specific rule set. The inheritance can be nested in multiple steps. For instance, if the parent rule set includes a rule to inherit its parent’s rule, the determined rule set also comprises the rule set of the grandparent.

[0052] In an evaluate rule conditions step 46, the rule evaluation server 1 evaluates the trigger conditions of the access rules within the rule set. The evaluation is performed sequentially for the rules of the rule set, and the evaluation is based on the attributes value(s) extracted in the extract attribute(s) step 40. The evaluation continues until a matching access rule, whose trigger condition is true, is found, or until all access rules have been evaluated without finding a matching access rule. When a matching access rule is found, no more rules of the rule set need to be evaluated.

[0053] For at least one trigger condition, the evaluation may involve comparing a transformed representation of an address of the requesting device 2 against a set of transformed representations. The transformed representation can, for instance, be based on a hashing algorithm, or any other algorithm that makes it very difficult or practically impossible to derive the address from the transformed representation. The address can, for instance, be a MAC address of the requesting device, here denoted a calling station ID. This allows the address of the requesting device to be used in the trigger condition, without revealing the actual MAC address. Specifically, the MAC address of the requesting device and a salt can be input into a hashing algorithm, resulting in a hashed MAC. The hashing can be performed by a third party server. The hashed MAC can be included in the password field, the username field or any other suitable field. Once received by the rule evaluation server 1, an equivalent calculation is performed, i.e. salting and hashing the MAC of the calling station ID, resulting in a verification hash. If the received hashed MAC is the same as the verification hash, thecheck is affirmative. The check relies on the same salt being available to the RADIUS client 6 and the rule evaluation server i.

[0054] Alternatively or additionally, the evaluation may involve assessing a value (retrieved from the RADIUS request) of attributes such as a NAS identifier, a called station identifier, a calling station identifier, and / or a username. If no trigger conditions of the access rules are true, an explicit or implicit rule may apply to reject the RADIUS request.

[0055] Put in another way, Table 1 below summarises examples of the various types of trigger conditions that can be used in an access rule.Table 1: Examples of attributes for trigger conditions

[0056] When a datastore is used, this implies that the trigger condition of the access rule cannot be evaluated based only on the RADIUS request; also an external datastore containing data is required for evaluating the trigger condition. Specifically, the datastore can contain a list of valid calling station IDs against which the value of the calling station ID attribute of the RADIUS request is checked. Optionally, the datastore is selected from a plurality of datastores based on the rule ID.

[0057] Rules can be grouped into logical sets by customers or resellers and a rule set can call another rule set recursively. This allows a default rule set to be created thatallows devices having no user ID (e.g. headless / IoT devices) to connect automatically, while gating user-authenticated accounts with additional rules.

[0058] In a conditional matching accept rule step 47, the rule evaluation server 1 determines whether a matching access rule indicating an accept has been found. If this is the case, the method proceeds to the provide RADIUS request step 48. If no matching rule indicating an accept is found, the method proceeds to a process RADIUS request, or the method ends. In any case, when no matching rule indicating an accept is found, the RADIUS request is rejected.

[0059] In the provide RADIUS request step 48, the rule evaluation server 1 acts based on the accept action specified by the matching access rule. Specifically, the rule evaluation server 1 provides the RADIUS request to the RADIUS server 3 for further processing. It is to be noted that the further processing by the RADIUS server 3 can entail performing no additional action. Hence, if the action is to reject access, the rule evaluation server 1 does not perform the provide RADIUS request step 48, whereby the rule evaluation server 1 abstains from providing the RADIUS request to the RADIUS server 3. When the RADIUS server 3 is implemented in the same physical device as the rule evaluation server 1, the rule evaluation server 1 can provide the RADIUS request to the RADIUS server 3 using internal communication. When the RADIUS server 3 is implemented in another physical device than the rule evaluation server 1, the rule evaluation server 1 can provide the RADIUS request to the RADIUS server 3 e.g. using internet protocol (IP) communication.

[0060] In a process RADIUS request step 50, the rule evaluation server 1 or the RADIUS server 3 processes the RADIUS request according to conventional RADIUS processing. Once the processing is done, a response 24 is transmitted to the RADIUS client 6. If both the rule set evaluation and the conventional RADIUS processing result in a positive outcome (i.e. no rejection), the response 24 is an Access-Accept response. On the other hand if at least one of the rule set evaluation or the conventional RADIUS processing is negative, the response 24 is an Access-Reject response.

[0061] Optionally, the rule evaluation server 1 may also provide an indicator of the matching rule that is included in the response 24. This allows the collection of statistics of how defined access rules are used, e.g. for billing. Alternatively, thecollection of statistics can be used to find access rules that are never, or very rarely, triggered, which could then be removed to clean up unused access rules.

[0062] A couple of illustrating examples will now be presented to provide better understanding of embodiments presented herein. These examples are based on a hierarchical structure, referring to Fig 2, where a top-level node 10 is provided, in these examples, without any rule set identifier. On the level below, the first intermediate node 11a has a rule set identifier of 4XjXLs, and the second intermediate node 11b has a rule set identifier of 5U5iCk. Below the first intermediate node 11a, the first leaf node 12a and the second leaf node 12b have the same rule set identifiers as their parent, i.e. 4XjXLs. Below the second intermediate node 11b, the third leaf node 12c has the same rule set identifier as its parent, i.e. 5U5iCk. The fourth leaf node has its own rule set identifier of FHtvs6.

[0063] This hierarchy illustrates an example where the first intermediate node 11a represents a first brand, and the second intermediate node 11b represents a second brand, both owned by an owner company which corresponds to the top-level node 10. The leaf nodes i2a-d represent various branches, i.e. physical establishments, of the brands that they belong to. In this example, where applicable, inheritance is implemented by a child node having the same rule set identifier as its parent node. It is to be noted, however, that inheritance could also be implemented by a child node having, in its rule set, a rule defining that a rule set of its parent should be included, which enables the child node to add additional rules, if desired.

[0064] For these examples, a rule set identifier is extracted from an incoming RADIUS request. The rule set identifier is used to retrieve a rule set. The retrieved rule set for the extracted rule set identifier comprises number of access rules that are shown in Table 2.Table 2: Access rules of an example rule set

[0065] In Table 2, it is to be noted that the second column is only used as a value referred to from the value column when the value column is [Rule ID]; the second column does not define the rule set of Table 2 in itself. Columns three, four, and five, optionally combined with column two, make up the trigger condition for each rule. The last column, priority, defines order of evaluation if there are multiple rows with the same rule number.

[0066] Now looking into specific examples, in a first example, the NAS has an ID of “4XjXLs”, which is included as a value in the RADIUS request for the NAS ID attribute. Looking to the rule set of Table 2, rule #1 is triggered, and the action of rule #1 is “Accept”. Hence, the radius request is provided to the RADIUS server for further processing.

[0067] In a second example, the NAS has an ID of “NAS-5U5iCk-oi”, which is included as a value in the RADIUS request for the NAS ID attribute. Looking to the rule set of Table 2 again, rule #2 is now triggered, and the action of rule #2 is again “Accept”. Hence, also here, the RADIUS request is provided to the radius server for further processing.

[0068] In a third example, a called station ID has the value of “FHtvs6-oi”, which is included as a value in the RADIUS request for the called station ID attribute. The rule set of Table 2 again, specifies that rule #3 that is now triggered. This is a multi -part rule (indicated by the third and fourth row in the table having the same rule number, and in that action of the third row is “chain”. Rule number 3 requires the called station ID to begin with “FHtvs6” AND the Password field to match the hash of the calling station ID. The first part of the rule is matched with “FHtvs6”. The rule continues (indicated by the “chain” action) to require that the Password field matches the hash of the calling station ID as described in Table 1. If, on hashing the calling station ID, the value matches thePassword field, the action is “Accept”. Hence, this is another example of where the RADIUS request is provided to the RADIUS server for further processing. In the event that the hash did not match, the request would be denied for further processing.

[0069] In a fourth example, the NAS has an ID of “dT81ha”, which is included as a value in the RADIUS request for the NAS ID attribute. Walking through all the access rules of the rule set of Table 2, the trigger condition for rule number 1, 2 and 3 are evaluated to be false. Instead, the final rule, rule number 4, is triggered, which is the default rule to reject the request. Hence, the RADIUS request is not provided to the radius server for further processing and the access request is rejected.

[0070] It can be seen how embodiments presented herein provide great flexibility and granularity in how to define when to accept and reject incoming RADIUS requests. The rule sets allow detailed customisation, while still enabling inheritance to reduce the need for duplication. All evaluation is based on values of attributes in the RADIUS request, whereby no changes are needed for the requesting device or the RADIUS client.

[0071] Fig 4 is a schematic diagram illustrating components of the rule evaluation server 1 of Fig 1 or Fig 3. It is to be noted that when the rule evaluation server 1 is implemented in a host device, such as a RADIUS server 3, one or more of the mentioned components can be shared with the host device. Processing circuitry 60 is provided using any combination of one or more of a suitable central processing unit (CPU), graphics processing unit (GPU), multiprocessor, neural processing unit (NPU), microcontroller, digital signal processor (DSP), etc., capable of executing software instructions 67 stored in memory circuitry 64, which can thus be a computer program product. The processing circuitry 60 could alternatively be implemented using an application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc. The processing circuitry 60 can be configured to execute the method described with reference to Fig 3 above.

[0072] The memory circuitry 64 can be any combination of random-access memory (RAM) and / or read-only memory (ROM). The memory circuitry 64 also comprises non-transitory persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory.

[0073] A data memory 66 is also provided for reading and / or storing data during execution of software instructions in the processing circuitry 60. The data memory 66 can be any combination of RAM and / or ROM.

[0074] The rule evaluation server 1 further comprises an 1 / O interface 62 for communicating with external and / or internal entities, e.g. with the RADIUS client 6 and the RADIUS server 3.

[0075] Other components of the rule evaluation server 1 are omitted in order not to obscure the concepts presented herein.

[0076] Fig 5 shows one example of a computer program product 90 comprising computer readable means. On this computer readable means, a computer program 91 can be stored in a non-transitory memory. The computer program can cause processing circuitry to execute a method according to embodiments described herein. In this example, the computer program product 90 is in the form of a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product 64 of Fig 4. While the computer program 91 is here schematically shown as a section of the removable solid-state memory, the computer program can be stored in any way which is suitable for the computer program product, such as another type of removable solid-state memory, or an optical disc, such as a CD (compact disc), a DVD (digital versatile disc) or a Blu-Ray disc.

[0077] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims. Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the following claims.

Claims

CLAIMS1. A method for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server (3), the method being performed by a rule evaluation server (1), the method comprising:extracting (40) at least one value of an attribute of a RADIUS request (22) from a RADIUS client (4), the RADIUS request (22) being addressed to the RADIUS server (3);obtaining (44) a rule set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access;evaluating (46), in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request (22), until a matching access rule, whose trigger condition is true, is found; andproviding (48) the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to reject access.

2. The method according to claim 1, further comprising:extracting (42) a rule set identifier from one of the at least one value of an attributes; andwherein the obtaining (44) the rule set comprises finding the rule set based on the rule set identifier.

3. The method according to claim 1 or 2, wherein the evaluating (46) the trigger conditions comprises, for at least one trigger condition, evaluating a transformed representation of an address of a device (2) requesting access against a set of transformed representations.

4. The method according to any one of the preceding claims, wherein the evaluating (46) the trigger conditions comprises, for at least one trigger condition, evaluating a value of one of the following attributes of the RADIUS request: an identifier of a network access server, NAS, an identifier of a called station, an identifier of a calling station, and / or a user name.

5. The method according to any one of the preceding claims, wherein the rule set comprises an access rule to inherit a rule set of a parent node.

6. The method according to any one of the preceding claims, wherein there is an explicit or implicit rule to reject the RADIUS request if the trigger conditions of all evaluated rules are false.

7. The method according to any one of the preceding claims, wherein the providing (48) the RADIUS request comprises providing an indicator of the matching rule.

8. The method according to any one of the preceding claims, wherein the rule set comprises a plurality of access rules.

9. A rule evaluation server (1) for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server (3), the rule evaluation server (1) comprising:processing circuitry (60); andmemory circuitry (64) storing instructions (67) that, when executed by the processing circuitry, cause the rule evaluation server (1) to:extract at least one value of an attribute of a RADIUS request (22) from a RADIUS client (4), the RADIUS request (22) being addressed to the RADIUS server (3);obtain a rule set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access;evaluate, in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request (22), until a matching access rule, whose trigger condition is true, is found; andprovide the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to reject access.

10. The rule evaluation server (1) according to claim 9, wherein the rule evaluation server (1) comprises the RADIUS server.

11. A computer program (67, 91) for evaluating whether to provide a Remote Authentication Dial-In User Service, RADIUS, request to a RADIUS server (3), the computer program comprising computer program code which, when executed on a rule evaluation server (1) causes the rule evaluation server (1) to:extract at least one value of an attribute of a RADIUS request (22) from a RADIUS client (4), the RADIUS request (22) being addressed to the RADIUS server (3);obtain a rule group set comprising at least one access rule, wherein each rule comprises a trigger condition and an action being to accept access or reject access;evaluate, in sequence, the trigger conditions of the at least one access rule of the rule set based on the at least one value of an attribute of the RADIUS request (22), until a matching access rule, whose trigger condition is true, is found; andprovide the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to accept access, or abstaining from providing the RADIUS request (22) to the RADIUS server (3) based on the action of the matching rule being to reject access.

12. A computer program product (64, 90) comprising a computer program according to claim 11 and a computer readable means comprising non-transitory memory in which the computer program is stored.

Images