WO2022025749A1

WO2022025749A1 - System and method for network authorization and policies management therefor

Info

Publication number: WO2022025749A1
Application number: PCT/MY2020/050154
Authority: WO
Inventors: Chee Kiam LEE; Muhammad Awis Jamaluddin JOHARI; Muhammad Azlan Shahariman AHMAD; Muhammad Fuad MUSTAFA; Nur Izyan Nadhirah FAIZULNIZAM
Original assignee: Mimos Berhad
Priority date: 2020-07-28
Filing date: 2020-11-16
Publication date: 2022-02-03

Abstract

The present invention provides a method of access authorization for a client accessing to a network having an authorization system, the network having a data center (DC) server (200) remotely deployed from a local server (300), wherein a client (500) is connectable to the DC server (200) and the local server (300), the method comprises authenticating the client (500) with user credentials; requesting, by the client (500), a user authorization policy from the DC server (200), returning a signed user authorization policy to the client (500); and routing the signed user authorization policy from the client (500) to the local server (300) for storing on the local server (300). When the DC server (200) is inaccessible, the network is operable under an offline mode whereby the local server (200) operably authorizes the client access based on the signed user authorization policy stored. An authorization system and a network therefor are also provided.

Description

SYSTEM AND METHOD FOR NETWORK AUTHORIZATION AND POLICIES MANAGEMENT THEREFOR

Field of the Invention

[0001] The present invention relates to an authorization system. More specifically, a system and method for authorizing access when a data center is inaccessible.

Background

[0002] Authentication is used to verify identity of the user before allowing access. Once the user is authenticated, authorization policy is used to determine an appropriate access privilege. Policy definitions are maintained and stored in a policy repository, which are typically recites at a data center (DC).

[0003] It is also well known that DC is adapted mainly for data storage and management only, many deployments may not be appropriate to be handled at DC. For example, localized queue management, lab information system, and radiology information system, just to name a few.

[0004] US published patent application no. US2013/03969A1 discloses a method and apparatus for key distribution with implicit offline authorization. More specifically, the system relates to distribution of a key generation process with implicit authorization. Such system is not suitable for network involves multi domains. [0005] US patent no. US9,264,436B1 discloses an intelligent automated authorization system to grant access to a resources based on owner previous authorization decision and other client classifications. It is a user-centric identity protocols.

[0006] Therefore, there is a need to provide a network authorization system and method for authorizing user access when a data center server is inaccessible. Summary

[0007] In one aspect of the present invention, there is provided a method of access authorization for a client accessing to a network having an authorization system, the network having a data center (DC) server remotely deployed from a local server, wherein a client is connectable to the DC server and the local server. The method comprises authenticating the client with user credentials; requesting, by the client, a user authorization policy from the DC server; returning a signed user authorization policy to the client; and routing the signed user authorization policy from the client to the local server for storing on the local server. When the DC server is inaccessible, the network is operable under an offline mode whereby the local server operably authorizes the client access based on the signed user authorization policy stored therein.

[0008] In one embodiment, the method further comprises routing the signed user authorization policy to an outreach server for storing thereon, whereby when the DC server is inaccessible, the network is operable under an outreach mode whereby the outreach server operably authorizes the client access based on the signed user authorization policy. [0009] In another embodiment, the method further comprises persisting the signed user authorization policies on Policy Retrieval Point, PRP, of the local server and the outreach server respectively.

[0010] In yet another embodiment, wherein the user access authorization comprises intercepting a user access request by a policy enforcement point, PEP; conveying the user access request to policy decision point, PDP; and retrieving a corresponding user authorization policy from the policy retrieval point, PEP.

[0011] In a further embodiment, the method further comprises deploying an authorization policy router on the client, whereby the user authorization router operationally routing the signed user authorization policy to the local server and an outreach server; and deploying a trust store on the local server and the outreach server for storing a public key of the DC server, wherein the public key is used for verifying signed user authorization policy.

[0012] In another aspect of the present invention, there is provided a network having an authorization system. The network comprises a data center, DC, server for managing the data of the network, the data includes user authorization policies; a local server having an authorization module and a trust store. The trust store stores a public key of the DC server for verifying signed user authorization policies; a client connectable to the DC server and the local server, the client having an authorization policy router. The authorization policy router routes a corresponding user authorization policy from the DC server to store on the local server. The authorization module operably authorizes the client access based on the signed user authorization policies stored on the local server, when the network is in an offline mode where the DC server is inaccessible. [0013] In one embodiment, the network further comprises an outreach server having an outreach authorization module and an outreach trust store, the trust store stores a public key of the DC server for verifying signed user authorization policies received. The authorization policy router of the client routes a corresponding user authorization policy from the DC server to store on the outreach server, the outreach authorization module operably authorizes the client access based on the signed user authorization policies stored on the outreach server when the network is in an outreach mode where the DC server is inaccessible.

[0014] In a further aspect of the present invention, there is provided an authorization system for a network having a data center, DC, server remotely deployed from a local server, wherein a client is connectable to the DC server and the local server. The authorization system comprises a trust store deployed on the local server for storing a public key of the DC server for verifying signed user authorization policies, an authorization module deployed on the local server, and an authorization policy router deployed on the client, operationally routing the signed user authorization policy to the local server. When the DC server is inaccessible, the network is operable under an offline mode whereby authorization module of the local server operably authorizes the client access based on the signed user authorization policy stored therein.

[0015] In one embodiment, the authorization system further comprises an outreach server having an outreach authorization module and an outreach trust store stores a public key of the DC server for verifying signed user authorization policies received. The authorization policy router of the client routes a corresponding user authorization policy from the DC server to store on the outreach server, the outreach authorization module operably authorizes the client access based on the signed user authorization policies stored on the outreach server when the network is in an outreach mode where the DC server is inaccessible.

Brief Description of the Drawings

[0016] This invention will be described by way of non-limiting embodiments of the present invention, with reference to the accompanying drawings, in which:

[0017] FIG. 1 illustrates a network adopting an authorization system in accordance with an embodiment of the present invention;

[0018] FIG. 2A illustrates a control flow of the authorization in accordance with an embodiment of the present invention; [0019] FIG. 2B illustrates a control flow of verifying signed user authorization policy in accordance with an embodiment;

[0020] FIG. 3 illustrates a flow chart for a process of persisting user authorization policy to local server in accordance with an embodiment of the present intention;

[0021] FIG. 4 illustrates a flow diagram of persisting user authorization policies to outreach sever on premise in accordance with an embodiment of the present invention; and

[0022] FIG. 5 illustrates a flow chart of server initialization process in accordance with an embodiment of the present invention. Detailed Description

[0023] In line with the above summary, the following description of a number of specific and alternative embodiments are provided to understand the inventive features of the present invention. It shall be apparent to one skilled in the art, however that this invention may be practiced without such specific details. Some of the details may not be described at length so as not to obscure the invention. For ease of reference, common reference numerals will be used throughout the figures when referring to the same or similar features common to the figures.

[0024] Embodiments of the present invention include various steps, which will be described below. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general- purpose or special-purpose processor programmed with the instructions to perform steps. Alternatively, steps may be performed by a combination of hardware, software, firmware, and/or by human operators. [0025] Embodiments of the present invention may be provided as a computer program product, which may include a machine-readable storage medium tangibly embodying thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, data storage drives be it magnetic or optical disks, and/or semiconductor-based memories, such as RAMs, ROMs, flash memory, etc., for storing digital instructions executable by any processing devices.

[0026] Various methods described herein may be practiced by combining one or more machine -readable storage media containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present invention may involve one or more computers (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps of the invention could be accomplished by modules, routines, subroutines, or subparts of a computer program product.

[0027] The present invention is implementable on both local and remote computing device. A local computer include a personal computer or a handheld mobile device. A remote computer may be a remote server or cloud computing device, which includes virtual machine, which generally refers to a self-contained operating environment that behaves as if it is a separate computer even though is part of a separate computer or may be virtualized using resources form multiple computers.

[0028] In one embodiment, software applications can be developed based on available platforms or platform products to build new functionality as an extension to the existing functionality. For example, a platform can be provided by a third party, e.g. a cloud computing platform that allows provisioning of the software application in a cloud environment.

[0029] Cloud computing is an internet-based computing that provides shared processing of resources and data to computers and other devices based on demand. The cloud computing provides access to the resources like networks, servers, storage, applications and services. These resources can be rapidly provisioned and released with minimal management effort in the cloud computing. [0030] FIG. 1 illustrates a network adopting an authorization system in accordance with an embodiment of the present invention. The network comprises a plurality of client (device) 500 operationally connected to one or more of a data center (DC) server 200, a local server 300 and an outreach server 400. The authorization system is a novel policy framework adapted to support policy across multiple domains. Specifically, the authorization system is adapted to manage local servers and outreach servers’ authorization module, in the event that DC server is not accessible, the clients are still able to access the network applications. The authorization system also reduce workload of the DC server to manage local servers and outreach servers’ authorization module.

[0031] The DC server 200 can reside at a remote location (from the local server

300), such as centralised cloud, for hosting and managing all users authorisation policies. The local server 300 resides at the same premise as the client 500 adapted to manage users’ authorization policies under the premise. The authorization system is adopted across the network to manage the authorization in the case when the DC server 200 is inaccessible. Inaccessibility of the DC server 200 may occurs when, for example, no wide area network (WAN) connections or the DC server is down, such that the authorization is still possible within the premise (or local network). In this network, the outreach server 400 is a remote server resides outside of the premise of the local server 300. The outreach server 400 is adapted as extension to the local server 300 to host services outside of the premise of the local server 300, whereby it also adapted to manage users authorization policies, among others. In another embodiment, the outreach server 400 may be a temporary server deployed at a rural area for accessing by users. [0032] As illustrations, not limitation, data at local server 300 and outreach server

400 may have relatively less physical security (limited access by authorized personnel, lock-and-key protection of assets, and always-on heating, ventilation and air conditioning (HVAC), etc.) and network security (firewall network limitation, Intrusion Detection System/Intrusion Prevention System and content-level filtering). Data on the local server 300 and outreach server 400 (e.g. authorization policies) can be easily altered comparing to DC server 200. In one embodiment, data at local and outreach server shall therefore be limited, i.e. only the required data (e.g. authorization policies) is made available outside the DC server 200. [0033] Still referring to FIG. 1, the DC server 200 comprises a DC application core 210, a key store 220 and a DC authorization module 230. The application core 210 executes and performs the required functions and application logics for the DC server 200. The key store 220 stores the DC server’ s private key and its own identity certificate to be identified for verification. The authorization module 230 is adapted to authorize users’ access according to their corresponding authorization policies.

[0034] The local server (LS) 300 comprises an LS application core 310, an LS trust store 320 and an LS authorization module 330. The LS application core 310 executes and performs the required functions and application logics for the local server 300. The LS trust store 320 is adapted to store DC server’s public key and certificates from trusted Certificate Authority (CA), which are used for verification of the certificate provided by the DC server 200 under an SSL connection. The LS authorization module 330 is adapted to retrieve, update and verify the signed user authorisation policy from

DC server 200. [0035] The outreach server 400 comprises an outreach application core 410, an outreach trust store 420 and an outreach authorization module 430. The outreach application core 410 executes and performs the required functions and application logics for the outreach server 300. The outreach trust store 420 is adapted to store DC server’s public key. The authorization module 430 is adapted to retrieve, update and verify the signed user authorization policy from the local server 300.

[0036] The client 500 comprises a client core 510 and an authorization policy router 520. The client core 510 is adapted to execute and perform functions and application logics for the client core 510. The authorization policy router 520 is adapted to route user policy to the local server 300.

[0037] Under normal operations, when the client 500 is within the premise and connected online, the user accesses both DC server 200 and the local server 300, whereby the authorization of the user access is based on RFC2904 of the AAA Authorization Framework. [0038] But when only the DC server 200 is inaccessible, the local server 300 and/or the outreach server 400 are still capable of authorizing the user’s client 500 with the authorization system of the embodiment of the present invention.

[0039] FIG. 2A illustrates a control flow of the authorization in accordance with an embodiment of the present invention. The following are definition of the acronym used in this application:

[0040] Policy Administration Point (PAP) - manages access authorization policies; [0041] Policy Decision Point (PDP) - Point which evaluates access requests against authorization policies before issuing access decisions;

[0042] Policy Enforcement Point (PEP) - Point which intercepts user's access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision;

[0043] Policy Information Point (PIP) - The system entity that acts as a source of attribute values (i.e. a resource, subject, environment); and

[0044] Policy Retrieval Point (PRP) - Point where the access authorization policies are stored, typically a database or the filesystem. [0045] Returning to the FIG. 2A, the diagram illustrates a user (client device) is attempting to operate a secured application that requires connection to the DC server 200 and the local server 300 resided at premise. To access the secured application, the user must first be authenticated with the user credentials. Once the user is authenticated successfully, the system will authorize the user access according to the user authorization policy.

[0046] During the authorization process, the DC server 200 retrieves the user authorization policy and signs it accordingly. Retrieval and singing of the user authorization policy will need to go through the control flow below. The signed user authorization policy is then sent to the local server 300. Similarly, the local server 300 will also need to go through the control flow below.

[0047] Operationally, the control flow of the authorization comprises the PEP that serves as a gateway to enforce the policy to protect the system’s application, services, data and etc. on the system. The PEP intercepts an access request and convey such access request to an authorization request to the PDP. The PDP evaluates the incoming authorization request against the authorization policy (assigned to the user) to decide whether to grant authorization to the access. The authorization policies are stored on the PRP, which can be an internal database or external database. The PIP contains attributes values of the policies in aid of decision making by the PDP. PDP uses PRP to lookup for policies, which could be in an internal database, an external database or even flat files. PDP uses the PIP to lookup attributes that are referenced in the policy, like LDAP directories, SQL databases, CSV files, environmental information such as CURRENT_TIME, CURRENT_DATE etc. For example, policy in PRP uses attribute ‘ROLE’, but PEP only can provide attribute ‘username’, whereby an LDAP PIP lookup the role associated with the username. PEP operates at the front end to intercepts all requests and passes to PDP. The PAP allows administrator and possibly users to control and make changes to the policies. [0048] On the local server 300 side, the added PRP allows the signed user authorization policy to be verified and stored therein. In FIG. 2A, the user authorization policy stored on the PRP of the DC server 200 is unsigned, whilst the user authorization policy stored on the PRP of the local server 300 is verified and signed by the DC server

200. [0049] FIG. 2B illustrates a control flow of verifying signed user authorization policy in accordance with an embodiment. Similarly, the control flow in FIG. 2A is also adopted in the outreach server 400. After the user authentication, the outreach server 400 receives and verifies the signed user authorization policy to be stored on the PRP of the outreach server 400. The signed user authorization policy stored on the PRP of outreach server 400 can be used for authorization of the user in the event that the DC server 200 is inaccessible by the user.

[0050] In this embodiment, the outreach server 400 does not require the PAP to manage the user authorization policies. In an alternative, the outreach 400 may be provided with PAP, for fully or partially be able to manage the user authorization policies.

[0051] Under the presence of PRP on the outreach server 400, users may still be authorized access according to their respective authorization policies, when not on premise, whereby only the outreach server 400 is accessible.

[0052] Collectively in FIGs. 2 A and 2B, the authorization processes are initiated after a user has successful login into the DC server 200 with the user credentials and authenticated when the user is within the premise. During the authorization processes, the authorization system starts preparing authorization data, allowing the user to retrieve his/her authorization policy and route to the local server 300 for authorization in offline mode, and the outreach server 400 for authorization in outreach mode. More specifically, the authorization system of the embodiments persisting user authorization policy from the DC server 200 to local server 300 and user authorization policy from the local server 300 to the outreach server 400 through an authorisation policy router on the users’ client. Authorisation modules of the local server 300 and the outreach server 400 then may independently authorize the users according to their own authorization policy when the local server 300 and the outreach server 400 are in offline mode and outreach mode respectively.

[0053] FIG. 3 illustrates a flow chart for a process of persisting user authorization policy to local server 300 in accordance with an embodiment of the present intention. The process is carried through out a Client (device) 500, a data center (DC) server 200 and a local server 300. The process starts after the user is successfully authenticated by the data server 200, typically but not limited to the user ID and password authentication, which is well known in the art. At step 322, the client 500 sends a request for user authorization policy to the DC server 200. It is to be noted that before the step 322, user of the client 500 would have already been authenticated by the DC server 200, for example, with correct user ID and password, possibly passed two-factor-authentication. Upon receiving the request, at step 342, the DC server 200 checks/retrieves the corresponding user authorization policy from the PRP. At step 344, if the user authorization policy does not exist, the DC server 200 returns an error message at step

346. The error message is then sent to the client at step 324. And the process shall halt here.

[0054] In one embodiment of the present invention, users are granted the access in local offline mode and/or outreach mode only when they had been authenticated and authorized by the DC server 200 at least once with a valid authorization policy assigned to this user. For clarity, a user can be a valid user for successful authentication, but without a valid user authorization policy recorded, the user would not be able to perform any function, leading to the halt of the system when the authorization fails.

[0055] Returning to the step 344 to check if the user authorization policy exist. When the user authorization policy is found, at step 348, the user authorization policy is retrieved. The DC server 200 then signs the user authentication policy with a private key of the DC server 200 at step 350. The signed user authorization policy is returned to the client 500 at step 352. [0056] At the client 500 side, at step 326, the client receives the signed user authorization policy. At step 328, the client 500 sends the signed user authorization policy to the local server 300 via an authorization policy router resided on the client

500. [0057] At the local server 300, at step 362, it receives the signed user authorization policy (from the client 500). The local server 300 then verifies signed user authorization policy using a public key of the DC server 200 at step 364. At step 366, it is determined if the policy is a valid one. If the policy is not valid, at step 368, the local server 300 sets the PDP to deny all requests from the client 500. [0058] If the policy is determined to be valid at step 366, the signed user authorization policy is persisted at the PRP for offline mode later at step 370. The signed authorization policy is loaded into the PDP at step 372.

[0059] FIG. 4 illustrates a flow diagram of persisting user authorization policies to outreach sever 400 on premise in accordance with an embodiment of the present invention. At step 405, the outreach server 400 is being initialized to request all the signed authorization policies for all users involving in the outreach activity. At step 410, the outreach server 400 sends a request for the signed user authorization policies from the local server 300. At step 422, the local server 300 receives the request. At step 424, the local server 300 retrieves the signed user authorization policies from the PRP. At step 426, the local server 300 returns the signed authorization policies. At step 412, the outreach server 400 receives the sign authorization policies. At step 414, the outreach server 400 verifies the signed authentication policies with the public key of the DC server 200. At step 416, the outreach server 400 determines if the signed authentication policies are valid. If the signed authentication policies are invalid, the outreach server 400 logs the event as message at step 417. If the signed authorization policies are determined to be valid at the step 416, the signed authorization policies are persisted at the PRP at step

418. [0060] FIG. 5 illustrates a flow chart of server initialization process in accordance with an embodiment of the present invention. This process is carried out by the local server 300 and the outreach server 400 to verify if the signed policies are being tempered. The local server 300 performs the initialization when on-premise offline mode is enabled. The outreach server 400 performs the initialization when the outreach mode is enabled. At step 502, the signed authorization policies are verified with the public key of the DC server 200. The signed policies is then check if it has been tampered at step 504. If the signed policies has been tampered, at step 506, the server is terminated. If the signed policies has not been tampered at step 504, the signed policies are loaded into the PDP at step 508. [0061] While specific embodiments have been described and illustrated, it is understood that many changes, modifications, variations and combinations thereof could be made to the present invention without departing from the scope of the invention.

Claims

1. A method of providing access authorization for a client accessing to a network having an authorization system, the network having a data center, DC server (200) remotely deployed from a local server (300), wherein a client (500) is connectable to the DC server (200) and the local server (300), characterized in that, the method comprising: authenticating the client (500) with user credentials; requesting, by the client (500), a user authorization policy from the DC server

(200); returning a signed user authorization policy to the client (500); and routing the signed user authorization policy from the client (500) to the local server (300) for storing on the local server (300), wherein when the DC server (200) is inaccessible, the network is operable under an offline mode whereby the local server (300) operably authorizes the client (500) access based on the signed user authorization policy stored therein.

2. The method of claim 1, further comprising routing the signed user authorization policy to an outreach server (400) for storing thereon, whereby when the DC server (200) is inaccessible, the network is operable under an outreach mode whereby the outreach server (400) operably authorizes the client access based on the signed user authorization policy.

3. The method of claim 1, further comprises persisting the signed user authorization policies on Policy Retrieval Point, PRP, of the local server (300) and the outreach server

(400) respectively.

4. The method of claim 1, wherein the method of providing access authorization further comprising: intercepting a user access request by a policy enforcement point, PEP; conveying the user access request to a policy decision point, PDP; and retrieving a corresponding user authorization policy from the Policy Retrieval

Point, PRP.

5. The method of claim 1, further comprising: deploying an authorization policy router (520) on the client (500), whereby the user policy router (520) operationally routing the signed user authorization policy to the local server (300) and the outreach server (400); and deploying a trust store on the local server (300) and the outreach server (400) for storing a public key of the DC server (200), wherein the public key is used for verifying signed user authorization policy.

6. A network having an authorization system, the network comprising: a data center, DC, server (200) for managing the data of the network, the data includes user authorization policies; a local server, LS, (300) having a LS authorization module (330) and a LS trust store (320), wherein the LS trust store (320) stores a public key of the DC server (200) for verifying signed user authorization policies; and a client (500) connectable to the DC server (200) and the local server (300), the client (500) having an authorization policy router (520), wherein the authorization policy router (520) routes a corresponding user authorization policy from the DC server (200) to store on the local server (300), wherein the LS authorization module (330) operably authorizes the client (500) access based on the signed user authorization policies stored on the local server (300), when the network is in an offline mode and the DC server (200) is inaccessible.

7. The network according to claim 6, further comprises an outreach server (400) having an outreach authorization module (430) and an outreach trust store (420), wherein the trust store (420) stores a public key of the DC server (200) for verifying signed user authorization policies received.

8. The network according to claim 7, wherein the authorization policy router (520) of the client (500) operationally routes a corresponding user authorization policy from the DC server (200) to store on the outreach server (400), the outreach authorization module (430) operably authorizes the client (500) access based on the signed user authorization policies stored on the outreach server (400) when the network is in an outreach mode and the DC server (200) is inaccessible.

9. An authorization system for a network having a data center, DC, server (200) remotely deployed from a local server, LS, (300), wherein a client (500) is connectable to the DC server (200) and the local server (300), the authorization system comprising: a LS trust store (320) deployed on the local server (300) for storing a public key of the DC server (200) for verifying signed user authorization policies; an LS authorization module (330) deployed on the local server (300); and an authorization policy router (520) deployed on the client (500), operationally routing the signed user authorization policy to the local server (300), wherein when the DC server (200) is inaccessible, the network is operable under an offline mode whereby the LS authorization module (330) of the local server (300) operably authorizes the client (500) access based on the signed user authorization policy stored therein.

10. The authorization system according to claim 9, further comprising an outreach server (400) having an outreach authorization module (430) and an outreach trust store (420) stores a public key of the DC server (200) for verifying signed user authorization policies received.

11. The authorization system according to claim 10, wherein the authorization policy router (520) of the client (500) operationally routes a corresponding user authorization policy from the DC server (200) to store on the outreach server (400), the outreach authorization module (430) operably authorizes the client (500) access based on the signed user authorization policies stored on the outreach server (400) when the network is in an outreach mode and the DC server (200) is inaccessible.