WO2019218020A1

WO2019218020A1 - A security gateway and method for controlling user interaction with one or more databases

Info

Publication number: WO2019218020A1
Application number: PCT/AU2019/050467
Authority: WO
Inventors: Bruce Talbot; Phillip Dean; Daniel Lai
Original assignee: archTIS Limited
Priority date: 2018-05-16
Filing date: 2019-05-16
Publication date: 2019-11-21

Abstract

The invention provides a security gateway for controlling user interaction with one or more databases, the security gateway determining and implementing access rules to control the interaction. The invention also provides a method for controlling user interaction with one or more databases, the method comprising the step of determining and implementing access rules to control the interaction using a security gateway.

Description

A SECURITY GATEWAY AND METHOD FOR CONTROLLING USER INTERACTION WITH

ONE OR MORE DATABASES

Field of the invention

The present invention relates to a security gateway and method for controlling user interaction with one or more databases.

Background of the invention

Attribute-based access control (ABAC) is a method of controlling and managing access to objects such as content, devices, shared web-based databases and applications. When implemented, this method grants users access to content and applications based on predefined access policies. The predefined access policies are statements comprising a combination of various attributes on both the user and the object.

ABAC is a standard defined by the National Institute of Standards and Technology (NIST) as one means of granting or denying specific requests for accessing and using information, shared data sources and related information processing services. However, NIST’s 2014 Special Publication 800-162 identifies more than 40 issues and considerations that could have an impact on the costs, timeframes, maintenance, management and the effectiveness of ABAC implementations.

Some issues identified by NIST include:

(a) the complexity of interactions between existing applications, systems and networks can impact performance, scalability and cost;

(b) the bespoke nature of most ABAC solutions which incur high costs of development and ongoing maintenance; and

(c) the difficulty in identifying and managing data worth protecting, determining who is authorised to access it, ensuring that all attributes are“established, defined, and constrained by allowable values required by the appropriate policies”, and that discrepancies between conflicting rules are corrected early. ln short, NIST’s publication recommends the standardisation of attribute-based access configurations within one or more products.

A standardised approach would allow for the definition of policies and metadata schema and their application against large and disparate data sets. Moreover, the application of these policies and schema can be done by the users, thereby decentralising the release management and control of information.

It is desired to overcome or alleviate one or more of the issues described above, or to provide a useful alternative.

Summary of the invention

The present invention provides a security gateway for controlling user interaction with one or more databases, the security gateway determining and implementing access rules to control the interaction.

In an embodiment, the security gateway comprises a control module, the control module comprising a receiver to receive requests from multiple users for interacting with one or more databases.

In an embodiment, the receiver is configured to forward a received request to a policy communication module to determine whether the requesting user has permission to execute the request.

In an embodiment, if the user does not have permission to execute the request, the control module sends an error notification to the requesting user via a user interface.

In an embodiment, if the user has permission to execute the request, the control module determines at least one target database which the user needs to interact with in order to execute the request.

In an embodiment, the control module determines the at least one target database using a secure configuration database.

In an embodiment, the control module transmits action instructions to each of the target databases to execute the request. ln an embodiment, a database communication connector is provided for each of the databases, the database communication connector being configured to establish communication between the control module and the corresponding database for transmitting action instructions to each of the target databases to execute the request.

In an embodiment, each of the target databases sends a notification via the database communication connector to the control module upon execution of the request.

In an embodiment, each of the one or more databases is configured to store data and data access rules.

In an embodiment, the received request comprises at least one of: attributes of a requesting user, and attributes for the request.

In an embodiment, the attributes of the requesting user comprise at least one of: user attributes, user role, user identity, user organisation, user location, user network, etc.

In an embodiment, the policy communication module transmits the request to a policy processor, and the policy processor compares the attributes of the requesting user and the attributes for the request with at least one predefined policy to determine whether the requesting user has permission to execute the request.

In an embodiment, the predefined policy is retrieved from a policy database.

In an embodiment, the policy processor communicates an outcome of whether the requesting user has permission to execute the request to the control module.

In an embodiment, the request is directed to at least one of the following tasks: a. Accessing data b. Accessing data access rules c. Creating new data d. Creating new data access rules e. Updating existing data f. Updating existing data access rules g. Deleting data access rules h. Deleting users i. Deleting metadata j. Deleting data k. Creating and managing new security fields (metadata) which can be applied to existing or new data access rules

L. Creating and managing new security fields (metadata) which can be applied to existing or new access rules m. Creating a new information container and the access rules for that new information container, wherein both the data and data access rules are stored in one or more databases.

In an embodiment, the database is a database associated with any one or more of: web services applications, people directory and content management systems.

In an embodiment, the security gateway is for logical implementation of attribute-based access within a cloud computing or enterprise information management environment.

In an embodiment, the access rules are policy statements based on different attributes including at least one of: user identity, geographical location, device identity, and network identity.

In an embodiment, the security gateway is a single network layer interacting with multiple databases for a logical implementation of attribute-based access control.

In an embodiment, the security gateway provides a central point of data access for different entities, users and organisations, and wherein data access to different entities, users or organisations is based on their individual security rules.

In an embodiment, the security gateway is configured to undertake user management, document management and administration management.

In an embodiment, user management comprises creation and management of access rules which define access permissions to users for carrying out different operations.

In an embodiment, document management comprises creation and management of access rules of different documents.

In an embodiment, a metadata tag is used for securing a document, wherein the metadata tag comprises security attributes.

In an embodiment, the security gateway manages access rules by various system functions which comprise: policies, attributes, maintenance, data sets, workspaces, metadata for documents, organisation, identity, reports and so on.

The present invention also provides a method for controlling user interaction with one or more databases, the method comprising the step of determining and implementing access rules to control the interaction using a security gateway.

In an embodiment, the method comprises the step of receiving requests from multiple users for interacting with one or more databases using a receiver comprised in a control module.

In an embodiment, the method comprises a further step of forwarding a received request to a policy communication module to determine whether the requesting user has permission to execute the request.

In an embodiment, the method comprises a further step of determining at least one target database using a secure configuration database.

In an embodiment, the method comprises a further step of transmitting action instructions to each of the target databases to execute the request.

In an embodiment, the method comprises a further step of establishing communication between the control module and the target databases using database communication connectors for transmitting action instructions to each of the target databases to execute the request.

In an embodiment, the method comprises a further step of sending a notification upon execution of the request from each of the target databases to the control module via the database communication connector.

In an embodiment, the attributes of the user comprise at least one of: user attributes, user role, user identity, user organisation, user location, and user network.

In an embodiment, the method comprises a further step of transmitting the request to a policy processor using the policy communication module; wherein the policy processor compares the attributes of the requesting user and the attributes for the request with at least one predefined policy to determine whether the requesting user has permission to execute the request.

In an embodiment, the predefined policy is retrieved from a policy database.

In an embodiment, the policy processor communicates the outcome of whether the requesting user has permission to execute the request to the control module.

In an embodiment, the request is directed to at least one of the following tasks: a. Accessing data b. Accessing data access rules c. Creating new data d. Creating new data access rules e. Updating existing data f. Updating existing data access rules g. Deleting data access rules h. Deleting Users i. Deleting Metadata j. Deleting data k. Creating and managing new security fields (metadata) that can be applied to existing or new data access rules

L. Creating and managing new security fields (metadata) that can be applied to existing or new access rules m. Creating a new information container and the access rules for that new information container, wherein both the data and data access rules are stored in one or more databases.

In an embodiment, the method is directed to logical implementation of attribute-based access within a cloud computing or enterprise information management environment.

In an embodiment, the method uses a single network layer for interacting with multiple databases for a logical implementation of attribute-based access control.

In an embodiment, the method provides a central point of data access for different entities, users and organisations, and wherein data access to different entities, users or organisations is based on their individual security rules. ln an embodiment, the method is equipped to perform user management, document management and administration management.

In an embodiment, the access rules are managed by various system functions which comprise: policies, attributes, maintenance, data sets, workspaces, metadata for documents, organisation, identity, reports and so on.

Brief description of the drawings

Embodiments of the invention are further described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 illustrates a working concept of an ABAC solution;

Figure 2 shows an architecture of a security gateway, in accordance with an embodiment of the present invention;

Figure 3 shows a flow diagram with various steps of a method for controlling user interaction with one or more databases or applications using a Universal Access Console (UAC) system;

Figure 4 shows execution of a specific user request in the UAC system;

Figures 5(a) to (c) show example data security problems within or across organisations and Figures 5(d) to (f) show their respective solutions provided through the implementation of the UAC system;

Figure 6 shows component structure of the UAC system;

Figure 7 shows a high-level system architecture system; Figure 8 shows a component relationship diagram showing relationships between various components of the UAC system; and

Figures 9 to 15 show data flow diagrams for the UAC system.

Detailed description

Figure 1 illustrates a fundamental working concept of an ABAC solution. The ABAC solution controls user access to a digital asset 1 a (including various databases and/or applications) based on various predefined access policies. A predefined access policy is a policy statement defining the conditions for allowing or restricting user access to various databases or applications. As shown in Figure 1 , the predefined access policy 1 b is based on various attributes, for example, user attributes 1 c (e.g. name, nationality, security clearance, organisation, group), geographic attributes 1 d (e.g. country, state, address), device attributes 1 e (e.g. name, MAC address, credential, classification), network attributes 1 f (name, credential, classification) and so on. An incoming request directed to access certain information of the digital asset 1 a is processed by the ABAC solution only if certain attributes of the request are allowed by the predefined access policy 1 b.

The inventors have realised that to overcome problems associated with implementation and operation of the ABAC solution (or other access control methods), the solution should be able to structure and apply a consistent and coherent metadata set through a set of functional application programming interfaces (APIs) or services that can be consumed by all applications. Additionally, the metadata set needs to be secured against tampering and have ABAC policies applied to ensure that the security model is consistent and true.

Embodiments of the present invention disclose a method of ABAC implementation which provides a centralised administration point for managing and enforcing the application of fine grained inter-enterprise access to content and other objects within an enterprise information environment.

The security gateway (referred to as Universal Access Console (UAC) system hereinafter) is useful for implementing access control methodologies (for example ABAC or other access control methods) for addressing problems faced by conventional implementations of ABAC.

The UAC system can address problems faced by the ABAC solution by providing an

orchestration fabric that allows solution administrators to manage ABAC assets in a logical manner, and provides the ability to realise complex and difficult combinations of access attributes in an understandable and intuitive User Interface (Ul).

In addition, the UAC system provides a universal means of managing information and content management solutions allowing for the creation of collaboration workspaces across a number of different technologies.

Figure 2 shows a high-level architecture of a security gateway 10 for controlling user interaction with multiple databases. The security gateway 10 is referred to as Universal Access Console (UAC) system or“DataKloak” (DataKloak is the product name for the UAC system). The UAC system 10 can be accessed by multiple users via multiple user interfaces 1 1 a to 1 1 e. A user can interact with the UAC system 10 via a computer interface 1 1 a to 1 1 d or a mobile device interface 1 1 e. The UAC system 10 comprises a control module 13. The control module 13 comprises a receiver 13a and a secure configuration database 13b. The receiver 13a is configured to receive requests from multiple users for interacting with multiple databases 17a to 17e. The databases 17a to 17e can interact with the control module 13 via their corresponding communication connectors 16a to 16e.

A policy communication module 18 is configured to interact with the UAC system 10. The policy communication module 18 comprises a policy processor 18a and a policy database 18b.

The databases 17a to 17e are associated with various applications such as: web services applications, people directory and content management systems. Each of the databases is for storing data and the data access rules of its associated application (not shown in Figure 2).

A user can submit a request for interacting with a database via the computer-based user interfaces 1 1 a to 1 1 d or mobile device-based user interface 1 1 e.

The user request for interacting with one of the databases can be directed to one or more of the following tasks: a. Accessing data b. Accessing data access rules c. Creating new data d. Creating new data access rules e. Updating existing data f. Updating existing data access rules g. Deleting data access rules h. Deleting Users i. Deleting Metadata j. Deleting data k. Creating and managing new security fields (metadata) that can be applied to existing or new data access rules

L. Creating and managing new security fields (metadata) that can be applied to existing or new access rules m. Creating a new information container and the access rules for that new information container.

The user request is received by the receiver 13a of the UAC system. The request is then forwarded to the policy communication module 18 for determining whether the requesting user is allowed to perform the task associated with the request.

The policy communication module 18 transmits the request to its policy processor 18a. The policy processor 18a compares the attributes of the requesting user and the attributes for the request with a predefined policy to determine whether the requesting user has permission to perform the task associated with the request. The predefined policy is retrieved from the policy database 18b which comprises a plurality of predefined policies. The plurality of predefined policies in the policy database 18b are defined according to the security requirements of the databases 17a to 17e.

The policy processor 18a communicates the outcome of whether the requesting user has permission to execute the request to the control module 13.

The secure configuration database 13b locates all the target databases and applications where the request needs to be executed. The control module 13 transmits action instructions to each of the target databases or applications to execute the request. The control module 13 transmits required action instructions to each of the target databases/applications via their corresponding data communication connectors 16a to 16e to execute the request.

The action instructions are company level statements. The action instructions typically include one or more of the following instructions for performing related defined actions: a. adding a user with a first attribute and a second attribute to the fields Security

Classification and Releasability, respectively, b. creating an Information compartment with the metadata fields desired (and validated against the metadata database and schema and apply against policy number), c. changing the details of a user to reflect access to a new Information compartment by adding a new security metadata field and entry to the user against the metadata schema, and d. adding a new device with security attributes and profile to the authorised device list with a certain Security Clearance, a certain Nationality and certain Information

Compartments.

Each of the target databases (e.g. one or more of 17a to 17e) sends a notification via their corresponding database communication connectors (e.g. one or more of 16a to 16e) to the control module 13 upon execution of the request. The notification regarding the completion of the request is then passed on to the user via a corresponding user interface 1 1 a to 1 1 e.

Figure 3 shows a flow diagram with various steps of a method for controlling user interaction with one or more databases using the UAC system. At step 31 a request is received by the receiver 13a which is sent by a user through a user interface 1 1 a to 1 1 e. The request can be, for example, related to creating a new access rule or updating an existing access rule. At step 32, the previously defined policy communication module 18 determines whether the user is allowed to perform the request. At step 33, the outcome of whether the requesting user has permission to execute the request is communicated to the control module 13. If the user attributes do not match the predefined policy stored in the policy database 18b then the user is not allowed to perform the request. At step 34a, an error notification is sent to the requesting user via the user interface notifying that the user does not have permission to execute the request. If the user is allowed to perform the request, at step 34b, the control module 13 determines at least one target database which the user needs to interact with in order to execute the request. At step 35, action instructions are transmitted via the control module to each of the target databases to execute the request. At step 36, a notification is sent via one or more database communication connectors (e.g. one or more of 16a to 16e) to the control module 13 upon execution of the request. Finally, at step 37, a notification is sent to the user interface (e.g. one or more of 1 1 a to 1 1 e) confirming the execution of the request.

Figure 4 shows the execution of a user request received from a user via a computer-based user interface 41 . User requests for security functions are submitted by a client application. These requests are validated, processed and orchestrated by the security gateway or UAC or “DataKloak” 40 (“DataKloak” is the product name for the UAC system). The UAC system 40 comprises a control module 43. The control module 43 comprises a receiver 43a and a secure configuration database 43b. DataKloak 40 normalises the requests and sends them to one or more of the technology specific communication connectors 46a to 46e as Standardised

Requests.

A policy communication module 48 is configured to interact with the UAC system 40. The policy communication module 48 comprises a policy processor 48a and a policy database 48b.

DataKloak 40 also updates the secure policy database 48b to ensure a record and configuration change is maintained for long term session/policy persistence. The target communication connectors 46a to 46e receive the normalised request and convert it into the specific technology functions and calls expected by the end capability. This results in an update to one or more underlying databases/applications 47a to 47e.

Figures 5(a) to (c) respectively show three examples of data security problems within or across organisations and Figures 5(d) to (f) show their corresponding solutions provided through the implementation of the UAC system. Figure 5(a) shows a relatively complex system in which multiple organisations (organisations A, B, C and D) are required to establish secure connections with one another. Figure 5(d) shows that the implementation of the UAC system within System Architecture 70 (referred to as“Kojensi”) facilitates an easy interaction among the organisations A, B, C and D for securely accessing data/information. Therefore, the

implementation of the UAC system is useful in resolving the complexities of security problems.

Figure 5(b) shows an example problem where multiple networks are used to perform tasks of different security requirements. It is expensive to build and manage multiple networks. The UAC system implements multi-level security via a single network (see Figure 5(e)) for performing tasks of various security requirements. This reduces the cost of associated with multiple networks and increases productivity.

Figure 5(c) shows an example problem of sharing information between independent data systems of two merged organisations A and B. The UAC system can be implemented for rapidly sharing information between the merged organisations A and B (see Figure 5(f)). This allows a user to access the data systems of the merged organisations A and B through the UAC system via a UAC user interface.

The UAC system is an orchestration engine that relies on the use of microservices that use APIs to communicate with each other. Figure 6 shows a high-level diagram of the UAC architecture showing component structure of the UAC system.

The UAC components are developed in discrete service layers. These layers are comprised of:

• Micro Services Layer 60

• Orchestration Layer 66

• Technology Adaptor Layer 600 (layer comprising adapters/connectors 601 to 606)

The Micro Services layer

The Micro Services layer 60 provides the front end to the UAC system as a set of callable functions from the UAC user interface (Ul). In an embodiment, the Micro Services layer 60 comprises various micro services such as user service 61 , organisation service 62, group service 63, security service 64, metadata service 65, and so on. These callable functions include the full set of required capabilities defined for the component sets and carry out the following tasks:

1 . Ensure the user has the rights to access the function according to their UAC Role and rights

2. Validate that the function call has all of the required variables and parameters for the function

3. Validate the parameters / variable match existing metadata requirement

4. Log this step of the transaction in an Audit log The output will be either:

1 . Return an error to the Ul for any of the above error conditions

2. Pass the validated function to the appropriate service(s) in the orchestration layer for further processing and await a return code(s) for passing as a completion notice to the Ul

As an example, a CreateWorkgroup function in the Micro Services layer 60 can gather information on the new Workgroup such as:

A. Workgroup Name

B. ABAC Code (derived and unique)

C. Workgroup Administrator UserlD

D. Workgroup Description

E. Metadata Tags

F. Security Fields

G. Other workgroup information The checks could be:

1 . The Workgroup Name is unique and does not have invalid characters

2. A unique ABAC code is created

3. The Administrator exists in the ID repository

4. The Workgroup description does not have invalid characters

5. The Security fields match the organisation profile for maximum values etc.

The Orchestration layer

The Orchestration layer 66 provides the configuration structure for the UAC system. A service in the Micro Services layer 60 will connect to one or more functional orchestration services in this layer 66. In an embodiment, the Orchestration layer 66 comprises multiple functional orchestration services which are labelled SVC1 to SVC9 in Figure 6. The functional

orchestration services SVC1 to SVC9 are configured to interact with an orchestration management module 68. The orchestration management module 68 communicates with various Technology Adaptors (also known as Communication Connectors) 601 to 606 (such as an identity connector 601 , a content connector 602 and an entitlements server connector 603), which in turn, communicate with their corresponding datasets 607 to 612, such as identity data 607, content data 608 and policy query data 609.

The Orchestration layer 66 receives the validated call and interacts with a Configuration database (the Configuration database is a component of Configuration Management 67) and the embedded workflow for the particular function to:

1 . Update Configuration database elements as required

2. Validate the Configuration database has been updated and return an error code on invalid condition

3. Read the technology adaptors 601 to 606 that have been configured to support the Orchestration function

4. Pass the function to the configured Technology Adaptors 601 to 606 and manage the return status of each

5. Log this step of the transaction in an Audit Log The output will be either:

1 . Return an error to the Micro Services layer 60 for any of the above error conditions

2. Pass the validated function to the appropriate service(s) in the Technology Adapter layer 600 for further processing and await a return code(s) for passing as a completion notice to the Micro Services Layer 60.

As an example, the CreateWorkgroup function in the Micro Services layer 60 could connect to a CreateWorkgroupOrch function in the Orchestration layer. The CreateWorkgroupOrch function could:

A. Add the following to the Configuration Database a. Workgroup Name b. ABAC Code c. Description d. Administrator ID e. Metadata tags f. Security Fields

B. Create the Workgroup in the selected Content Repositories (via the configured

technology adapter(s)) a. Workgroup Name b. ABAC Code c. Description d. Metadata tags e. Security Fields

C. Update the UserlD in the ID Stores Repositories (via the configured technology

adapter(s)) a. ABAC Code b. Workgroup Role Code - Administrator The Technology Adaptor layer

The Technology Adapter layer 600 provides the functionality to connect to an individual technology instance from a function call from the Orchestration layer 66. Technology adapters (also known as communication connectors as described in Figures 2 and 4) 601 to 606 are required for each instance of a new connection type and will perform the following tasks. Note that a single orchestration service may call a technology adapter multiple times with different calls to achieve a final result. The following steps detail a single iteration of a call through the technology adapter.

1 . Call the connection details for the technology from the Configuration Database a. Connection String (including host and port details) b. Connection User Name c. Connection Password

2. From the calling service/function of the Orchestration Layer, reformat the call into the required format that is used by the receiving technology

3. Submit the call to the connected technology

4. Receive the response and confirm valid action or error

5. Return the success or error status to the Orchestration Layer 66

6. Log this step of the transaction in an Audit log

The output could be: 1 . Pass the technology formatted message to the end-technology service or API

2. Return an error to the Orchestration Layer 66 for any of the above error conditions

3. Return a success message to the Orchestration Layer 66

As an example, the CreateWorkgroupOrch function in the Micro Service layers 60 could connect to a configured Content Repository and an ID Store Repository in the Technology Adapter Layer 600.

Call 1 - The Content Repository function could:

A. Call up the Content Repository connection information from the Configuration Database a. Connection String b. Connection User c. Connection Password

B. Select the function to manage workgroup entries in the technology adapter and format the call to create a workgroup in Content Repository using the following information: a. Workgroup Name b. ABAC Code c. Description d. Metadata tags e. Security Fields

C. Update the UserlD in the Content Repository (if required) with: a. ABAC Code b. Workgroup Role Code - Administrator Call 2 - The ID Store function could: A. Call up the ID Store connection information from the Configuration Database a. Connection String b. Connection User c. Connection Password

B. Select the function to update a UserlD in the Technology Adapter and format the call to update a User using the following information: a. User ID b. ABAC Code c. Workgroup Role Code - Administrator

Functional Breakdown of UAC

From a functional perspective, the main areas that UAC covers are discussed below:

• Managing attributes

• Managing roles

• Managing identities

• Managing organisations

• Managing policies

• Managing metadata

• Managing workspaces

• Managing networks / locations / devices

• Managing system artefacts

• Reporting 1 . Managing Attributes

Organisations need to be able to create and manage attributes, even though the default configuration may provide a number of pre-created ones. Managing attributes includes the following functional areas:

Table 1 : Attribute Management

2. Managing Roles

A role is a way of grouping privileges, normally to define an organisation function or set of functions that are performed by one or more users. UAC includes both predefined system roles and the ability to create“organisation” roles. Organisations require the ability to provision and manage roles. Managing roles includes the following functionality areas:

Table 2: Role Management

3. Managing Identities

In UAC terms, identity includes information that authenticates the identity of a user (such as username / password) as well as information that describes information and actions that the user is authorised to access and / or perform. An identity can therefore be thought of as the security domain of a user. Organisations need to be able to provision and manage identities access to information objects simply and easily. Managing identities comprises the following functionality areas:

Table 3: Identity Management

4. Managing Organisations

Organisations can be added to UAC (and therefore Kojensi) as part of the onboarding process. Managing organisations includes the following functional areas:

Table 4: Organisation Management

5. Managing Policies

Managing policies comprises the following functionality areas:

Table 5: Policy Management

6. Managing Metadata

Metadata is defined as‘information that describes data’. This can include how the data was created, the time and date of creation, the author of the data and the location on a network where the data was created. Much of this data can be automatically populated, but where it is not users can be prompted for it. Organisations must have the ability to easily manage and organise metadata attributes and the use of those attributes as part of an Information Management capability. Managing metadata comprises the following functionality areas:

Table 6: Metadata Management

7. Managing Workspaces

Managing workspaces comprises the following functionality areas:

Table 7: Workspace Management

8. Managing Networks / Locations / Devices

Organisations need to be able to provision and manage networks / locations / devices and their access to information objects simply and easily. Managing networks, locations and devices comprises the following functionality areas:

Table 8: Location Management

9. Managing System Artefacts

Managing system artefacts comprises the following functionality areas: Table 9: Managing System Artefacts

10. Reporting

Reporting comprises the following functionality areas:

Table 10: Managing Reports

Figure 7 shows a high-level system architecture 70 of the Kojensi system and how the UAC functionality fits within a complete enterprise / cloud scale system architecture. The UAC system is one of the most important parts of the Kojensi system. Originally, the UAC system was designed to be a solution that could compatibly work with Kojensi. However, it is to be noted that the UAC system can be easily implemented within environments and/or solutions other than Kojensi.

The secure external gateways 72, firewalls 74, 76 and load balancers 75 limit the connections to secure HTTPS traffic only, provide for resource sharing and block malicious access attempts. These connections are provided to a web server and dedicated published APIs and Web Services for functions required by the enterprise application. The UAC system 79 provides the central management capability for this with core security functionality services and process. The UAC system 79 connects to critical services such as a secure User Identity Store e.g. LDAP repository 81 , a policy decision engine data store e.g. entitlements repository 82, and maintains a secure off-line copy in the UAC Repository 83. The UAC repository 83 acts as a master and validation point for integrity checking on any subordinate on-line information source. Not shown in Figure 7 is any additional capability / data store required by the enterprise that is

supplementary to the core functionality.

Figure 8 is a component relationship diagram showing the component relationships between each of the major functional areas of the UAC system as identified in the“Functional Breakdown of UAC” section above. It is to be noted that the content management side of Kojensi receives information from the UAC system but is not a component of the UAC system so it is not shown in Figure 8.

The key points shown in Figure 8 are:

• System management, which is a representation of the entirety of UAC, is made up of the sums of all the other entities.

• Each entity also provides data into administration reporting. Note that actual report requirements have not yet been clearly broken down, but it seems unlikely that any entity will not have reporting needs.

Data Flow Diagrams

Figures 9 to 15 show data flow diagrams (DFDs) for the UAC system.

The data flow diagram for UAC is a graphical representation of the "flow" of data through UAC, modelling its process aspects.

A. Managing Identities

A high level DFD for managing identities is shown in Figure 9. A UAC administrator 91 manages identities. The process to load identities in bulk 92 has been separated out as it is a one- directional data flow. It is separated using an operation such as an LDIF import to load data in bulk directly into the LDAP store 93. Likewise, identity information needs to be passed to the external (to UAC) content management entity 94 as a one-directional data flow.

The remaining operations on identities (creating / editing an identity, adding roles to an identity, deleting roles from an identity, adding attributes to an identity, deleting attributes from an identity, disabling an identity, assigning biometrics for an identity, restoring an identity, setting permissions for an identity, changing identity status, and transferring an identity profile between organisations) require bi-directional data flows, to update both the LDAP store 93 and the UAC repository 95.

B. Managing Policies

A high level DFD for managing policies is shown in Figure 10. A UAC administrator 101 manages policies. Policy information is passed to the external (to UAC) content management entity 104 as a one-directional data flow.

The remaining operations on policies (creating / editing a policy, adding roles to a policy, deleting roles from a policy, configuring attribute mappings, disabling a policy, configuring access policy decisions, managing default settings, and applying access policies) require bi directional data flows, to update either (or both, depending on the operation) the LDAP store 103 and the UAC repository 105.

C. Managing Metadata

A high level DFD for managing metadata is shown in Figure 1 1 . A UAC administrator 1 1 1 manages metadata. Metadata information is passed to the external (to UAC) content management entity 1 14 as a one-directional data flow.

The remaining operations on metadata (creating metadata elements, adding or editing metadata values, deleting metadata values, deleting metadata elements, creating a taxonomy, editing a taxonomy, and deleting a taxonomy) require bi-directional data flows, to update the UAC repository 1 15.

D. Managing Workspaces

A high level DFD for managing workspaces is shown in Figure 12. A UAC administrator 121 manages workspaces. Workspace information needs to be passed to the external (to UAC) content management entity 124 as a one-directional data flow.

The remaining operations on workspaces (creating workspaces, editing workspaces, disabling workspaces, deleting workspaces, configuring workspaces and archiving workspaces) require bi-directional data flows, to update the UAC repository 125.

E. Managing Networks / Locations / Devices

A high level DFD for managing networks, locations and devices is shown in Figure 13. A UAC administrator 131 manages networks/locations/devices. Network, location and device (NLD) information needs to be passed to the external (to UAC) content management entity 134 as a one-directional data flow.

The remaining operations on NLDs (creating / editing NLDs, adding roles to NLDs, deleting roles from NLDs, adding attributes to NLDs, deleting attributes from NLDs, disabling NLDs, bulk creation of NLDs, restoring an NLD, setting permissions for an NLD, changing NLD status, and transferring an NLD profile between organisations) require bi-directional data flows, to update either (or both) the LDAP store 132 and the UAC repository 135.

F. Managing System Artefacts

A high level DFD for managing networks, locations and devices is shown in Figure 14. A UAC administrator 141 manages system artifacts. System artefact information is passed to the external (to UAC) content management entity 144 as a one-directional data flow.

The remaining operations on system artefacts (adding a content management system (CMS) source, adding a CMS repository, configuring identity connectors, configuring schema mappings, adding interfaces for target CMSs, and adding or editing languages) require bi directional data flows, to update either (or both) the LDAP store 142 and the UAC repository 145.

G. Reporting

A high level DFD for reporting is shown in Figure 15. A UAC administrator 151 manages reporting. Unlike all the other UAC DFDs, data for the reporting DFD needs to be passed from the external (to UAC) content management entity 154 (other DFDs pass data to the content management entity) as a one-directional data flow.

The remaining operations on reporting (creating reports, generating reports, creating ad hoc reports, and publishing reports) require bi-directional data flows, to update the UAC repository 155. ln some of the above embodiments, the UAC system is discussed as a component of the Kojensi system. In the embodiments described, the UAC is the security gateway for the Kojensi infrastructure including databases, policy communication modules and interfaces. The UAC system is a part of the Kojensi system and in further embodiments the UAC may be provided independently to perform the role of security gateway in other access security systems. In embodiments of the invention the communication connectors of the UAC and other network interfaces are configured to communicate with databases, policy communication modules, and user interfaces.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. It will be apparent to a person skilled in the relevant art that various changes in form and detail can be made therein without departing from the spirit and scope of the invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as, an acknowledgement or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Claims

1 . A security gateway for controlling user interaction with one or more databases, the security gateway determining and implementing access rules to control the interaction.

2. The security gateway of claim 1 , wherein the security gateway comprises a control module, the control module comprising a receiver to receive requests from multiple users for interacting with one or more databases.

3. The security gateway of claim 2, wherein the receiver is configured to forward a

received request to a policy communication module to determine whether the requesting user has permission to execute the request.

4. The security gateway of claim 3, wherein if the user does not have permission to

execute the request, the control module sends an error notification to the requesting user via a user interface.

5. The security gateway of claim 3, wherein if the user has permission to execute the request, the control module determines at least one target database which the user needs to interact with in order to execute the request.

6. The security gateway of claim 5, wherein the control module determines the at least one target database using a secure configuration database.

7. The security gateway of claim 5 or 6, wherein the control module transmits action instructions to each of the target databases to execute the request.

8. The security gateway of claim 7, wherein a database communication connector is provided for each of the databases, the database communication connector being configured to establish communication between the control module and the corresponding database for transmitting action instructions to each of the target databases to execute the request.

9. The security gateway of any one of claims 5 to 8, wherein each of the target

databases sends a notification via the database communication connector to the control module upon execution of the request.

10. The security gateway of claim 1 to 9, wherein each of the one or more databases is configured to store data and data access rules.

1 1 . The security gateway of any one of claims 2 to 10, wherein the received request comprises at least one of: attributes of a requesting user, and attributes for the request.

12. The security gateway of claim 1 1 , wherein the attributes of the requesting user

comprise at least one of: user attributes, user role, user identity, user organisation, user location, and user network.

13. The security gateway of claim 12, wherein the policy communication module transmits the request to a policy processor, and wherein the policy processor compares the attributes of the requesting user and the attributes for the request with at least one predefined policy to determine whether the requesting user has permission to execute the request.

14. The security gateway of claim 13, wherein the predefined policy is retrieved from a policy database.

15. The security gateway of claim 13 or 14, wherein the policy processor communicates an outcome of whether the requesting user has permission to execute the request to the control module.

16. The security gateway of any one of claims 2 to 15, wherein the request is directed to at least one of the following tasks: a. Accessing data b. Accessing data access rules c. Creating new data d. Creating new data access rules e. Updating existing data f. Updating existing data access rules g- Deleting data access rules h. Deleting Users i. Deleting Metadata j. Deleting data k. Creating and managing new security fields (metadata) that can be

applied to existing or new data access rules

L. Creating and managing new security fields (metadata) that can be

applied to existing or new access rules m. Creating a new information container and the access rules for that new information container, wherein both the data and data access rules are stored in one or more databases.

17. The security gateway of any one of the preceding claims, wherein the database is a database associated with any one or more of: web services applications, people directory and content management systems.

18. The security gateway of any one of the preceding claims, wherein the security

gateway is for logical implementation of attribute-based access within a cloud computing or enterprise information management environment.

19. The security gateway of any one of the preceding claims, wherein the access rules are policy statements based on different attributes including at least one of: user identity, geographical location, device identity, and network identity.

20. The security gateway of any one of the preceding claims, wherein the security

gateway is a single network layer interacting with multiple databases for a logical implementation of attribute-based access control.

21 . The security gateway of any one of any one of the preceding claims, wherein the

security gateway provides a central point of data access for different entities, users and organisations, and wherein data access to different entities, users or

organisations is based on their individual security rules.

22. The security gateway of any one of the preceding claims, wherein the security gateway is configured to undertake user management, document management and administration management.

23. The security gateway of claim 22, wherein user management comprises creation and management of access rules which define access permissions to users for carrying out different operations.

24. The security gateway of claim 22 or 23, wherein document management comprises creation and management of access rules of different documents.

25. The security gateway of claim 24, wherein a metadata tag is used for securing a

document, wherein the metadata tag comprises security attributes.

26. The security gateway of any one of the preceding claims, wherein the security

gateway manages access rules by various system functions which comprise: policies, attributes, maintenance, data sets, workspaces, metadata for documents,

organisation, identity, and reports.

27. A method for controlling user interaction with one or more databases, the method comprising the step of determining and implementing access rules to control the interaction using a security gateway.

28. The method of claim 27, wherein the method comprises the step of receiving requests from multiple users for interacting with one or more databases using a receiver comprised in a control module.

29. The method of claim 28, wherein the method comprises a further step of forwarding a received request to a policy communication module to determine whether the requesting user has permission to execute the request.

30. The method of claim 29, wherein if the user does not have permission to execute the request, the control module sends an error notification to the requesting user via a user interface.

31 . The method of claim 29, wherein if the user has permission to execute the request, the control module determines at least one target database which the user needs to interact with in order to execute the request.

32. The method of claim 31 , wherein the method comprises a further step of determining at least one target database using a secure configuration database.

33. The method of claim 31 or 32, wherein the method comprises a further step of

transmitting action instructions to each of the target databases to execute the request.

34. The method of claim 33, wherein the method comprises a further step of establishing communication between the control module and the target databases for transmitting action instructions to each of the target databases to execute the request.

35. The method of any one of claims 31 to 34, wherein the method comprises a further step of sending a notification upon execution of the request from each of the target databases to the control module via the database communication connector.

36. The method of any one of claims 27 to 35, wherein each of the one or more databases is configured to store data and data access rules.

37. The method of any one of claims claim 28 to 36, wherein the received request

comprises at least one of: attributes of a requesting user, and attributes for the request.

38. The method of claim 37, wherein the attributes of the user comprise at least one of: user attributes, user role, user identity, user organisation, user location, and user network.

39. The method of any one of claims 29 to 38, wherein the method comprises a further step of transmitting the request to a policy processor using the policy communication module, wherein the policy processor compares the attributes of the requesting user and the attributes for the request with at least one predefined policy to determine whether the requesting user has permission to execute the request.

40. The method of claim 39, wherein the predefined policy is retrieved from a policy

database.

41 . The method of claim 39 or 40, wherein the policy processor communicates the

outcome of whether the requesting user has permission to execute the request to the control module.

42. The method of any one of claims 28 to 41 , wherein the request is directed to at least one of the following tasks: a. Accessing data b. Accessing data access rules c. Creating new data d. Creating new data access rules e. Updating existing data f. Updating existing data access rules g. Deleting data access rules h. Deleting Users i. Deleting Metadata j. Deleting data k. Creating and managing new security fields (metadata) that can be

applied to existing or new data access rules

L. Creating and managing new security fields (metadata) that can be

43. The method of any one of claims 27 to 42, wherein the database is a database

associated with any one or more of: web services applications, people directory and content management systems.

44. The method of any one of claims 27 to 43, wherein the method is for logical implementation of attribute-based access within a cloud computing or enterprise information management environment.

45. The method of any one of claims 27 to 44, wherein the access rules are policy

statements based on different attributes including at least one of: user identity, geographical location, device identity, and network identity.

46. The method of any one of claims 27 to 45, wherein the method uses a single network layer for interacting with multiple databases for a logical implementation of attribute- based access control.

47. The method of any one of claims 27 to 46, wherein the method provides a central point of data access for different entities, users and organisations, and wherein data access to different entities, users or organisations is based on their individual security rules.

48. The method of any one of claims 27 to 47, wherein the method is equipped to perform user management, document management and administration management.

49. The method of claim 48, wherein user management comprises creation and

management of access rules which define access permissions to users for carrying out different operations.

50. The method of claim 48 or 49, wherein document management comprises creation and management of access rules of different documents.

51 . The method of claim 50, wherein a metadata tag is used for securing a document, wherein the metadata tag comprises security attributes.

52. The method of any one of claims 47 to 51 , wherein the access rules are managed by various system functions which comprise: policies, attributes, maintenance, data sets, workspaces, metadata for documents, organisation, identity, and reports.