Security Overview | AllegroGraph 9.0.1
Author: Franz Incorporated

Copyright (c) 2005 - 2026 Franz, Incorporated
Last updated 27 May 2026 at 10:34

# AllegroGraph 9.0.1 Security Overview

- Documentation Index
  - Release Notes
  - Quick Start
  - SSL/TLS Quick Start
  - Introduction
  - Setup and Configuration
    - Download
    - Server Installation
    - Server Configuration and Control
    - WebView
    - Database Upgrading
    - Managing Users
  - Server Management
    - Performance Tuning
    - Deleting Duplicate Triples
    - Purging Deleted Triples
    - Auditing
    - Managing Users
    - Replication
    - Point-in-Time Recovery
    - Transaction Log Archiving
    - Security Overview
    - Security Implementation
  - Tools
    - agtool
    - Data Loading
    - Data Export
    - Backup and Restore
    - Querying
    - RDFS++
    - Materializer
    - Event Scheduler
    - SHACL
  - Details
    - Triple Indices
    - Freetext Indices
    - Encoded IDs
    - Connection Pooling
    - N-dimensional Geospatial Overview
    - 2-D Geospatial
    - Temporal
    - Social Network
    - JavaScript
    - Datatypes
    - Data Conversion (Rapper)
    - Stored Procedures
    - Triple Attributes
    - Lineparse Format
  - Querying
    - SPARQL documentation summary
    - SPARQL Reference
    - SPIN
    - SPARQL Magic Properties
    - Prolog
  - 3rd-party tools
    - Solr text Indices
    - MongoDB integration
    - TopBraid Composer Plugin
    - Cloudera
  - Client APIs
    - Gruff
    - GraphTalker
    - REST/HTTP interface
    - HTTP reference
    - Javadocs (Sesame and Jena)
    - Python API
    - Lisp Reference
    - JavaScript
  - Tutorials
    - N-dimensional Geospatial
    - SPARQL Tutorial
    - Java Sesame
    - Java Jena
    - Python Sesame
    - Lisp
    - Prolog
    - More...
  - Other
    - Conferences and Seminars
    - Source Code on Github
    - Amazon EC2
    - Copyrights
  - Franz, Inc.

- AllegroGraph Enterprise Security and Management
- Security in general
- General Discussion of Security
  - External authentication
    - LDAP
    - OAuth and OpenID Connect
  - Transport Layer Security - Encryption in Transit
    - Connections using SSL
    - X.509 Certificates
  - Encryption At Rest
  - Management, Access Control, and Security
    - Configuration of Repositories and Catalogs
    - Management of JavaScript and Lisp Stored Procedures
    - User Management
    - Programmatic System Management
  - Triple Level Security

Documentation Index

## AllegroGraph Enterprise Security and Management

AllegroGraph represents the first Semantic Technology Database with OLTP, ACID compliance and Enterprise Management functionality. AllegroGraph Enterprise Security and Management (ESM) provides the mission critical functionality that organizations need to support 24/7/365 operations. AllegroGraph has received a Certificate of Networthiness for the product to run on the Department of Defense `.mil` network.

This document gives and overview of security in AllegroGraph. See Security Implementation for implementation details.

## Security in general

AllegroGraph is set up to maintain data security from potential threats internal and external. While the exact details of implementing the various security measures are described in the various technical documents, the following overview should provide a good introduction to AllegroGraph and data security.

We organize the discussion with five questions. But before getting to those, everyone concerned with security needs to carefully consider what the threats are and where they might come from.

Threats can be internal or external. Internal threats (typically from dishonest or disgruntled employees) are in many ways harder to guard against because trust is basic to an employer/employee relationship but AllegroGraph provides advanced tools to makes sure that damage is limited and recovery is as fast and complete as possible when a problem is discovered.

External threats are in many ways easier to understand and guard against. You want to prevent unauthorized access to and modification of your data.

1. How do I make sure only the right user has read/write permissions for a particular repository?

To begin, AllegroGraph access can be configured with your corporate LDAP/OAuth policies (see Top-level directives for external authentication in the Server Configuration and Control document) Then every user is given permissions on a repository basis, so a particular user will have read, write, or read/write permission on repos granted which the user is created in the system and modifiable at any time by the system administrator. Users not granted access to a repo will not even be able to see that the repo exists. Roles are supported, which allows defining repo access permissions which can be given to a class of people (everyone in the accounting department, for example). Using roles reduces the likelihood of permission errors caused by having permissions specified for each individual employee. Anonymous access can be enabled. Such access typically have read permission on the public repos but no write permission at all. See the Managing Users for information on repository permissions.

2. How can I make sure that no one can listen in to the communication between server and client?

In today's distributed world, it is often convenient, indeed often necessary, to allow remote access to sensitive data. Obviously this access is restricted by password and the like, but open communication can be intercepted and usernames and passwords might be extracted and then improperly used, or data can be intercepted as it passes between the legitimate user and the central system.

This is of course a well known problem in the internet world, and for Encryption in Transit the general solution is to use SSL client certificate authentication. This is fully supported by AllegroGraph. See the Transport Layer Security section below for more information and links to other documents.

Also supported are logs of access and interactions. If you suspect there might be a problem, reference to these logs can indicate whether there are suspicious accesses and interactions. See the Auditing document.

3. How can I encrypt my data on disk so no one can read and/or decipher it?

Another concern that users have is that someone might copy the data and then decipher the contents of the database. By encrypting the data we can prevent that. We recommend that users use an encrypted file system for the storage of the AllegroGraph directories. See the Encryption At Rest section below for more on this topic.

4. What mechanisms do you have to restrict access to triples or triple-patterns within a repository?

There are several ways, with varying degrees of fineness of control.

- Access Restrictions: Access can be restricted to specific repositories, as described in # 1 above, and this is often sufficient for many uses, particularly where data is easily categorized.

- Security Filters: These can restrict access to triples with specific subjects or predicates or objects or graphs. They allow finer control than just by repo, but they are still fairly coarse-grained. Security filters are discussed briefly below and in the Managing Users document.

- Triple Attributes: The above mechanisms may be too coarse for many applications. Sometimes data cannot be so easily classified, or there are too many classifications (requiring too many different repositories), so AllegroGraph provides security at the triple level, similar to Cell-Level security in a relational database.

AllegroGraph supports triple-level attributes, which are metadata added to each triple. Every triple can have its own set of attributes (attributes are name/value pairs associated with a triple). For example, an attribute "securityLevel" could have values of "low", "medium" and "high". Users too can have a security level. User access of triples can then be controlled by comparing the attribute/value pairs assigned to a user with the attribute/value pairs on the triples. If the user does not have access to triples with particular attribute/value pairs, it is as if, from the point of view of the user, those triples simply do not exist.

See Triple Security for a full description of this form of triples security, with examples. Attributes are described in the Triple Attributes document.

5. How can I protect my data from corruption?

There are various ways to preserve data from loss or corruption. One way is using replication. AllegroGraph supports replica repositories on multiple servers (called Multi-master Replication or MMR), so a change to the repo on one server is propagated to replicas on the other servers. The propagation typically has minimal latency and is extremely fast so an unexpected failure of one server can result in minimal data loss. Multi-master replication provides the best mechanism for fast recovery of all data except the small amount that may have been lost due to latency. See the Multi-master Replication (MMR) document.

A second scheme (best used in addition to MMR) is to make express backups of data to files. This is a point-in-time backup: the data is good through the time of the backup but subsequent changes are not, of course, reflected. However, a regular backup schedule, performed at all replication sites, can guarantee that data loss can be minimized. See the Repository Backup and Restore document.

Note that backups to disk, when set up correctly and managed by workers separate from those who add and delete data, does provide protection against dishonest or malicious employees. When a problem is caused by such an employee, so long at that employee does not have access to the backup files, recovery from at least from a known starting point (the time of the last backup) is easy and quick.

## General Discussion of Security

AllegroGraph ESM includes the following:

- External Authentication Support (LDAP/OAuth), see Top-level directives for external authentication in the Server Configuration and Control document.
- Transport Layer security to and from database clients.
- Management, Access Control and Security for the AllegroGraph database server and AllegroGraph Enterprise Subsystems; such as Backup, Restore, Point-in-Time Recovery, Warm Standby and Replication.
- Data Access Control
- Data Access Control – Triple Level Security

### External authentication

#### LDAP

AllegroGraph supports using LDAP (Lightweight Directory Access Protocol, see this Wikipedia entry) for external authentication. All user data (permissions, etc) are stored locally, so in order to be able to authenticate a user externally, a user with the same name must already exist on a given AllegroGraph server. See the Managing Users document for information about creating and managing users.

Use of LDAP is enabled with several configuration directives described here in the Server Configuration and Control document.

Note that external authentication refers to a support of an external user password database, so other AllegroGraph authentication methods (tokens, certificates etc) are not affected when authentication policy is set to external-only.

#### OAuth and OpenID Connect

AllegroGraph suports OAuth/OIDC authentication. As with LDAP, user information (permissions, etc) is stored internally, but the authentication itself can be delegated to an external service.

OAuth/OIDC authentication can be enabled with an AllegroGraph configuration directive described here in the Server Configuration and Control document.

### Transport Layer Security - Encryption in Transit

Access to an AllegroGraph database server can be obtained via AllegroGraph’s RESTful interface (for HTTP and HTTPS clients), through AllegroGraph’s built-in web interface – AGWebView, through a Lisp client application, or with other clients such as Java and Python.

All client network access to AllegroGraph occurs though the product’s HTTP and HTTPS RESTful interfaces. The AllegroGraph interface, and RESTful interfaces in general, are remarkable in that they are by definition client-server, stateless, cacheable and provide a uniform interface identifying system resources in the client request.

AllegroGraph clients can connect directly to the server via HTTP, sending and receiving clear text. AllegroGraph clients also have the ability to send and receive encrypted requests.

#### Connections using SSL

An AllegroGraph session can be established over Secure Sockets Layer (SSL). AllegroGraph supports TLS versions 1.0, 1.1, and 1.2.

Several AllegroGraph configuration options relate to SSL. See the Top-level directives for SSL client certificate authentication section in Server Configuration and Control document. See also the SSL/TLS Quickstart document.

AllegroGraph utilizes FIPS 140-2 compliant encryption for data in transit. Reference http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf.

#### X.509 Certificates

The server provides an X.509 certificate to the client during the SSL/TLS handshake when the connection is established. Therefore the client can check the contents of the certificate if desired.

### Encryption At Rest

To enable data-at-rest encryption with AllegroGraph we recommend using a third party tool such as Linux LUKS disk encryption.

If running AllegroGraph using a cloud service provider, we recommend using the provider's disk encryption mechanism (such as EBS encryption on AWS). Google Cloud Services encrypts storage volumes by default.

### Management, Access Control, and Security

AGWebView provides a GUI management and data access interface to AllegroGraph, as we describe in Security Implementation. The web-browser based interface allows the system administrator to manage access control to individual repositories, maintain users and roles, and control the Warm Standby and Replication interfaces.

#### Configuration of Repositories and Catalogs

Repositories are effectively managed through AGWebView. Control over placement of the catalogs and server settings is managed during initial server configuration.

#### Management of JavaScript and Lisp Stored Procedures

Both JavaScript and Lisp stored procedures are supported. The user manages stored procedures through AGWebView.

#### User Management

The system administrator is given fine-grained control over creation and management of users, passwords and roles through the AGWebView interface.

There are several predefined user permissions, including Superuser, Start Sessions, Eval (stored procedures) and (control) Replication.

For each user and role, the administrator can manage these permissions and repository access. Access can be granted to specific repositorities in specific catalogs, all repositories in a catalog, or all repositories in the server.

#### Programmatic System Management

All the management functions of the product are exposed via HTTP, Java, Python, Lisp and others. Organizations can take advantage of AGWebView or provide their own custom interface to AllegoGraph security and management.

Summary:

Manage User Permissions and Access Rights

- Super User - Manages user accounts and all security.
- Eval User - Manages access to AllegroGraph stored procedure functionality.
- Session - Allows users to manage their own sessions.
- Read/Write - Defined per user for each database and catalog.

Administrative Functionality

- List Users
- Create Users
- Delete Users
- Change Password
- List User Roles
- Add Role to User
- Delete Role from User
- List User Permission Flags
- Assign Permission Flags
- Delete Permission Flags
- List User Database and Catalog Access
- Set User Database and Catalog Access
- List Users within specified Role
- Create New Role
- Delete Role
- Grant and Revoke Permissions for each Role
- Create and Delete Database
- Specify security filters for roles and for users

### Triple Level Security

As graph databases become more entrenched in enterprise applications, increased security and fine-grained data access control is required. To support this, AllegroGraph supports statement-level Security Filters, which are described in the Security Filters section of Security Implementation and triple attributes, described in the Triple Attributes section of Security Implementation

With Security Filters the system administrator is able to grant user access to the entire repository, or restrict access to a limited and filtered view of a repository.

Security Filters can be applied to individual repositories for all add/delete/query operations, per user and per role. You specify which values of the subject, predicate, object, or graph should be allowed or disallowed and then query responses are filtered appropriately, and attempts to add or delete filtered triples fail.

Key Security Filter Features:

- Apply Security Filters per user and/or role.
- Prevents data access to unauthorized users.
- Minimal administration.
- The user `views` the repository based on the applied Security Filter.
- Allows fine-grained and flexible access to data.

Key Triple Attributes Features:

- Can apply to individual users
- Applies to each individual triple