Skip to content

Synchronized access control

There are many factors that influence who should have access to a digital service or data source:

  • the type of data
  • the scope of data
  • the accuracy of data
  • the origin of data
  • the data subject's permissions
  • the data owner's permissions
  • the person or system requesting access
  • the use that the data is to be put to

Egeria enables all of this information to be assembled and linked together at multiple levels - for example a database column may be linked to a glossary term called employee-salary that is in turn classified as sensitive personal information (SPI).

Security managers, such as Apache Ranger, however just needs to know that the column is SPI. So engine actions convert this complex model into something much more operationally-focused in the form of security tags. The security tags attached to the schemas are all that needs to be distributed to the security managers.

Representing security tags

Figure 1 shows the open metadata type definition for the SecurityTag classification from model 0423.

Figure 1

Figure 1: The classification SecurityTags contains the list of security labels and properties that can be attached to assets and schema attributes that describe the data fields within the asset

A SecurityTags classification can be attached to any referenceable but is typically attached to the schema attributes that represent the data fields. For example the columns in a database. However, it may be attached to groups of data fields - such as a database table or a database schema - to indicate that the security tags apply to all data fields in the group - or to the asset itself if all of the data within the asset should have the same security tags. Figure 2 shows a SecurityTag attached to a database column.

Figure 2

Figure 2: The classification SecurityTags is attached to a database column to indicate the security tags that apply to the data stored in that column

The security tags can be simple labels that indicate that the data item(s) belong to a specific category of data. Alternatively, they can be name-value property pairs.

Security tag examples

In the example below there are two security labels: reference-data and product-description and one property called expires-on that has a value of 31/12/2024.

securityLabel = [ "reference-data", "product-description" ]
securityProperties = ["expires-on"->"31/12/2024"]
These are the types of values that are stored in the SecurityTag classification.

Using the security tags in security rules

The rules that are associated with the security tags are defined in the security manager, such as Apache Ranger.

Figure 3 shows an Apache Ranger rule that is activated when the reference-data security label is attached to a column.

Figure 3

Figure 3: Configuring a tag-based rule in Apache Ranger involves identifying the security label and then defining what should happen based on the type of user requesting access to the data

Figure 4 shows an Apache Ranger rule that works with a security property expires-on. It is activated when the security property is present and uses the value of the security property in the rule execution.

Figure 4

Figure 4: Configuring a tag-based rule that uses a security property

Phases of synchronized access control

Figure 5

Figure 5: The five phases of synchronized access control: (1) capture of technical metadata; (2) augmentation of technical metadata with governance metadata that define the factors that effect access control; (3) consolidation of governance metadata into the security tags; (4) distribution of the technical metadata with the security tags to the security manager(s); (5) audit of the security tag settings and rules to ensure that the data is appropriately protected


Cataloguing of assets and their schemas (often called technical metadata) may be manually catalogued by individuals/tools or through the integration daemon.


Using templates, metadata discovery or governance action services, governance metadata is added to the assets that provide the business and jurisdictional context to the assets.


A governance action service trawls the metadata about the asset and sets up the SecurityTags classification.


Through an integration connector running in the Security Integrator OMIS hosted by the Integration Daemon, the security tags are synchronized with the external security manager that is manage access control.


Audit of security set up is possible because both governance metadata and the resulting security tags are available. These can then be verified against the rules in the security policy enforcement engines.

Figure 6

Figure 6: Deployment of the synchronized access control technology showing the capture of the technical metadata, plus any additional governance metadata through the use of templates through the Integration Daemon on the top left-hand side. The augmentation and consolidation is running in the Engine Host at the bottom left-hand side and the distribution to the external security manager through another Integration Daemon is shown on the right-hand side. The separation of the connectors across different integration daemons and their use of different cohort members is purely to help with the layout of the diagram. You are free to distribute these connectors and services as you choose.

Summary of the services that support synchronized access control

Figure 7 provides a summary of the registered services involved in supporting synchronized access control.

Figure 7

Figure 7: Summary of the services that support synchronized access control

The links below take you to each service's description that includes how to configure and use these services.

Catalog Services

Augmentation Services

Consolidation Services

Distribution Services

Audit Services

Raise an issue or comment below