Access Control

Authorization and user database

Authorization is the process of mapping a known user to a set of specific permissions. GraphDB implements Spring Security, where permissions are defined based on a combination of a URL pattern and an HTTP method. When an HTTP request is received, Spring Security intercepts it, verifies the permissions, and either grants or denies access.

User roles and permissions

GraphDB’s access control is implemented using a hierarchical Role Based Access Control (RBAC) model. This corresponds to the hierarchical level of the NIST/ANSI/INCITS RBAC standard and is also known as RBAC1 in older publications.

The model defines three entities:

Users

Users are members of roles and acquire the permissions associated with the roles.

Roles

Roles group a set of permissions and are organized in hierarchies, i.e., a role includes its directly associated permissions as well as the permissions it inherits from any parent roles.

Permissions

Permissions grant access rights to execute a specific operation.

RBAC in GraphDB does not define sessions, as the security implementation is stateless. An authorized user always receives the full set of roles associated with it. Within a single API request call there is always an associated user and hence roles and permissions.

The core roles defined in GraphDB security model follow a hierarchy:

Role name

Inherits roles

Associated permissions (without the inherited ones)

ROLE_ADMIN

ROLE_REPO_MANAGER
ROLE_CLUSTER

Can perform all operations, i.e., the security never rejects an operation

ROLE_REPO_MANAGER

ROLE_MONITORING

Can create, edit, and delete repositories with read and write permissions to all repositories

ROLE_MONITORING

ROLE_USER

Allows monitoring operations (queries, updates, abort query/update, resource monitoring)

ROLE_USER

Can save SPARQL queries, graph visualizations, or user-specific settings

ROLE_CLUSTER

Can perform internal cluster operations

The following repository access roles are available as well:

Role name

Associated permissions

READ_REPO_*

Read permissions to all repository IDs

WRITE_REPO_*

Write permissions to all repository IDs

READ_REPO_xxx

Read permissions to a given repository, where xxx is the repository ID

WRITE_REPO_xxx

Write permissions to a given repository, where xxx is the repository ID

Note

When providing the WRITE_REPO_xxx role for a given repository, the READ_REPO_xxx role must be provided for it as well.

The GraphDB user management interface uses a simplified high level model, where each created user falls into one of three categories: a regular user, a repository manager, or an administrator. The three categories correspond directly to one of the core roles. In addition to that, regular users may be granted individual read/write rights to one or more repositories:

Inherent role and permissions

Regular user

Repository manager

Administrator

Core role

ROLE_USER

ROLE_REPO_MANAGER

ROLE_ADMIN

Read access to a specific repository

optional

no

no

Read/write access to a specific repository

optional

no

no

Read/write access to all repositories

no

yes

yes

Create, edit, and delete repositories

no

yes

yes

Access monitoring

no

yes

yes

Manage Connectors

no

yes

yes

Manage Users and Access

no

no

yes

Manage the cluster

no

no

yes

Attach remote locations

no

no

yes

View system information

no

no

yes

Built-in users and roles

GraphDB has two special internal users that are required for the functioning of the database. These users cannot be seen or modified via user management.

Username

Associated roles

Description

<cluster user>

ROLE_CLUSTER
READ_REPO_*
WRITE_REPO_*

Used for cluster-internal communication between cluster nodes.

<free access user>

None by default but administrators may grant access to one or more repositories.

The user associated with anonymous access if anonymous access is enabled.

GraphDB supports three types of user databases used for authentication and authorization, explained in detail below: Local, LDAP, and OAuth. Each of them contains the information about who the user is, where they come from, and what type of rights and roles they have. The database may also store and validate the user’s credentials, if that is required.

Only one database is active at a time. When one is selected, all available users are provided from that database.

The default database is Local.

Local user database

As mentioned above, this is the default security access provider. The local database stores usernames, encrypted passwords, assigned roles and user settings. Passwords are encrypted using the bcrypt algorithm.

The local database is located in the settings.js file under the GraphDB work/workbench directory. By default, this is $graphdb.home/work/workbench. If you are worried about the security of this file, we recommend encrypting it (see Encryption at rest).

The local user database does not need to be configured but can be explicitly specified with the following property:

graphdb.auth.database = local

Default admin user

A fresh installation of GraphDB comes with a single default user whose username is admin and default password is root. This user cannot be deleted or demoted to any of the non-administrator levels. It is recommended to change the default password at earliest convenience in order to avoid undesired access by a third party.

If you wish to disable the default admin user, you can unset its password from the Users and Access screen of the GraphDB Workbench.

LDAP user database

Tip

See also the configuration examples for Basic/GDB + LDAP, OpenID + LDAP, and Kerberos + LDAP.

Lightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services implementing X.500 standards. All its records are organized around the LDAP Data Interchange Format (LDIF), which is represented in a standard plain text file format.

When LDAP is enabled and configured, it replaces the local database and GraphDB security will use the LDAP server to provide authentication and authorization. An internal user settings database is still used for storing user settings. This means that you can use the Workbench or the GraphDB API to change them. All other administration operations need to be performed on the LDAP server side.

Note

As of GraphDB version 9.5 and newer, local users will no longer be accessible when using LDAP.

LDAP needs to be configured in the graphdb.properties file.

Enable LDAP with the following property:

graphdb.auth.database = ldap

When LDAP is turned on, the following security settings can be used to configure it:

Property

Description

Example value

graphdb.auth.ldap.url
(required)

LDAP endpoint

ldap://<my-openldap-server>:389/<partition>

graphdb.auth.ldap.user.search.base

Query to identify the directory where all authenticated users are located.

<empty>

graphdb.auth.ldap.user.search.filter (required)

Matches the attribute to a GraphDB username.

(cn={0})

graphdb.auth.ldap.role.search.base
(required)

Query to identify the directory where roles/groups for authenticated users are located.

<empty>

graphdb.auth.ldap.role.search.filter (required)

Authorize a user by matching the manner in which they are listed within the group.

The property value supports two placeholders, {0} and {1}, each with a different meaning:

  • The placeholder {0} is replaced with the full LDAP distinguished name, e.g., cn=johnsmith,o=example,o=com.

  • The placeholder {1} is replaced with just the common name (the cn field), e.g., “johnsmith”. Typically, users are mapped to groups using only the common name, so we recommend setting the value to {1}.

Tip

It may be useful to enable debug logging for LDAP by adding the following at the end of the conf/logback.xml in the GraphDB distribution:

<logger name="com.ontotext.forest.security.provider.ldap" level="DEBUG"/> <logger name="org.springframework.security.ldap" level="DEBUG"/>

This will print additional LDAP messages in the log showing what is queried and what is returned.

(uniqueMember={1})

graphdb.auth.ldap.role.search.attribute

The attribute to identify the common name.

cn (default)

graphdb.auth.ldap.role.map.administrator (required)

Map a single LDAP group to GDB administrator role.

my-group-name

graphdb.auth.ldap.role.map.repositoryManager

Map a single LDAP group to GDB repository manager role.

my-group-name

graphdb.auth.ldap.role.map.repository.read.<my-repo>

Map a single LDAP group to GDB repository-specific read permissions.

my-group-name

graphdb.auth.ldap.role.map.repository.write.<my-repo>

Map a single LDAP group to GDB repository-specific write permissions.

my-group-name

graphdb.auth.ldap.repository.read.base

Query to identify the directory where repository read groups for authenticated users are located.

graphdb.auth.ldap.repository.read.filter

Authorize a user by matching the manner in which they are listed within the group.

(uniqueMember={0})

graphdb.auth.ldap.repository.read.attribute

Specify the mapping of a GraphDB repository id to an LDAP attribute.

cn (default)

graphdb.auth.ldap.repository.write.base

Query to identify the directory where repository write groups for authenticated users are located.

graphdb.auth.ldap.repository.write.filter

Authorize a user by matching the manner in which they are listed within the group.

(uniqueMember={0})

graphdb.auth.ldap.repository.write.attribute

Specify the mapping of a GraphDB repository id to an LDAP attribute.

cn (default)

graphdb.auth.ldap.bind.userDn

Specify a userDN (distinguished name) allowing anonymous binds and anonymous access to an LDAP server.

dn (default)

graphdb.auth.ldap.bind.userDn.password

UserDN password

Mapping user type roles

GraphDB has three standard user roles: Administrator, Repository manager, and User. Every user authenticated over LDAP will be assigned one of these roles.

Mapping the Administrator role

Set the following property to the LDAP group that must receive this role:

graphdb.auth.ldap.role.map.administrator = gdbadmin
Mapping the Repository manager role

Set the following property to the LDAP group that must receive this role:

graphdb.auth.ldap.role.map.repositoryManager = gdbrepomanager
Mapping the User role

Unless a user has been assigned the Administrator or Repository manager role, they will receive the User role automatically.

OAuth user database

Tip

See also the configuration example for OpenID + OAuth.

OAuth is an open-standard authorization protocol for providing secure delegated access as a way for users to grant websites/applications access to their information on other websites/applications without sharing their initial login credential. OAuth is centralized, which means only the authorization server owns user credentials.

Note

OAuth requires OpenID for authentication, and the authorization comes from an OAuth claim. Direct password authentication with GraphDB (e.g., basic or using the Workbench login form) is not possible.

When OAuth is enabled and configured, it replaces the local database and GraphDB security will use only the OAuth claims to provide authorization. An internal user settings database is still used for storing user settings. This means that you can use the Workbench or the GraphDB API to change them. All other administration operations need to be performed in the OpenID/OAuth provider.

Enable OAuth authorization with the following property:

graphdb.auth.database = oauth

When OAuth authorization is enabled, the following property settings can be used to configure it:

Property

Description

Example value

graphdb.auth.oauth.roles_claim
(required)

OAuth roles claim. The field from the JWT token that will provide the GraphDB roles. No default value.

roles

graphdb.auth.oauth.roles_prefix
(required)

OAuth roles prefix to strip. The roles claim may provide the GraphDB roles with some prefix, e.g. GDB_ROLE_USER. The prefix will be stripped when the roles are mapped. The default value is the empty string. No default value.

GDB_

graphdb.auth.oauth.default_roles
(required)

OAuth default roles to assign. It may be convenient to always assign certain roles without listing them in the roles claim. The value is a comma-delimited list of GraphDB roles. The default value is the empty list. No default value.

ROLE_USER

Authentication methods

Whenever a client connects to GraphDB, a security context is created. Each security context is always associated with a single user authenticated user or a default anonymous user when no credentials have been provided.

Authentication is the process of mapping this security context to a specific user. Once the security context is mapped to a user, a set of permissions can be associated with it, using authorization.

When GraphDB security is ON, the following authentication methods are available:

  • Basic authentication: the username and password are sent in a header as plain text (usually used when using the RDF4J client, or via Java when run with cURL). Enabled by default (can be optionally disabled).

  • GDB: token-based authentication used by the Workbench for username/password login. This login method is also available through the REST API. Enabled by default (can be optionally disabled).

  • OpenID: single sign-on method that allows accessing GraphDB without the need for creating a new password. Its biggest advantage is the delegation of the security outside the database. Disabled by default (must be configured to be enabled).

  • Kerberos: highly secure single sign-on protocol that uses tickets for authentication. Disabled by default (must be configured to be enabled).

_images/authentication-authorization-schema.png

All four authentication providers - Basic, GDB, OpenID, and Kerberos - can be combined with both a local and an LDAP database. The only provider that can be combined with OAuth is OpenID, as OAuth is an extension of the latter.

There is also an additional authentication provider, the GDB Signature. It is for internal use only, works with a detached internal cluster user, and is always enabled. This is the built-in cluster security that uses tokens similar to those used for logging in from the Workbench.

The following combinations of authentication provider and user database are possible:

Authentication provider

User database

Basic authentication

Local DB
LDAP

Kerberos

Local DB
LDAP

GDB

Local DB
LDAP

OpenID

Local DB
LDAP
OAuth

We will look at each of the above in greater detail in the following sections.

Basic authentication

Basic authentication is a method for an HTTP client to provide a username and password when making a request. The request contains a header in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of the username and password joined by a single colon, e.g.:

Authorization: Basic YWRtaW46cm9vdA==

Warning

Basic authentication is the least secure authentication method. Anyone who intercepts your requests will be able to reuse your credentials indefinitely until you change them. Since the credentials are merely base-64 encoded, they will also get your username and password. This is why it is very important to always use encryption in transit.

GDB authentication

GDB authentication is a method for an HTTP client to obtain a token in advance by supplying a username and password, and then send the token with every HTTP request that requires authentication. The token must be sent as an HTTP header in the form of Authorization: GDB <token>, where <token> is the actual token.

This authentication method is used by the GraphDB Workbench when a user logs in by typing their username and password in the Workbench.

Note

Anyone who intercepts a GDB token can reuse it until it expires. To prevent this, we recommend to always enable encryption in transit.

It is also possible to obtain a token via the REST API and use the token in your own HTTP client to authenticate with GraphDB, e.g. with cURL:

  1. Log in and obtain a token:

    curl -X POST -I 'http://localhost:7200/rest/login/admin' -H 'X-GraphDB-Password: root'
    

    The token will be returned in the Authorization header. It can be copied as is and used to authenticate other requests.

  2. Use the returned token to authenticate with GraphDB:

    curl -H 'Authorization: GDB eyJ1c2VybmFtZSI6ImFkbWlu...' http://localhost:7200/repositories/myrepo/size
    

GDB tokens are signed with a private key and the signature is valid for a limited period of time. If the private key changes or the signature expires, the token is no longer valid and the user must obtain a new token. The default validity period is 30 days. It can be configured via the graphdb.auth.token.validity property that takes a single number, optionally suffixed by the letters d (days), h (hours) or m (minutes) to specify the unit. If no letter is provided, then days are assumed. For example, graphdb.auth.token.validity = 2d and graphdb.auth.token.validity = 2 will both set the validity to two days.

Note

During the token validity period, if the password is changed the user will still have access to the server. However, if the user is removed, the token will stop working.

The private key used to sign the GDB tokens is generated randomly when GraphDB starts. This means that after a restart all tokens issued previously will expire immediately and users will be forced to login again. To avoid that, you can set a secret to derive a static private key by setting the following property:

graphdb.auth.token.secret = <my-secret>

Treat the secret as any password, it must be sufficiently long and not easily guessable.

OpenID authentication

Tip

See also the configuration examples for OpenID + Local users, OpenID + LDAP, and OpenID + OAuth.

Single sign-on over the OpenID protocol enables you to log in just once and access all internal services. From a security standpoint, it provides a more secure environment, because it minimizes the number of places where a password is processed.

When OpenID is used for authentication, the authorization may come from the local user database, LDAP, or OAuth. Direct password authentication with GraphDB is possible only with the local database or LDAP, and can be optionally disabled.

OpenID needs to be configured from the graphdb.properties file. Enable it with the following property:

graphdb.auth.methods = basic, gdb, openid

The default value is basic, gdb.

Provide only openid if password-based login methods (Basic and GDB) are not needed, or if you combine OpenID with the OAuth user database.

When OpenID authentication is enabled, the following property settings can be used to configure it:

Property

Description

Example value

graphdb.auth.openid.issuer
(required)

OpenID issuer URL used to derive keys, endpoints, and token validation. No default value.

https://accounts.example.com

graphdb.auth.openid.client_id
(required)

OpenID client ID used to authenticate and validate tokens. No default value.

<my-client-id>

graphdb.auth.openid.username_claim
(required)

OpenID claim to use as the GraphDB username. No default value.

email

graphdb.auth.openid.auth_flow
(required)

OpenID authentication flow: code, code_no_pkce, implicit. The recommended value is code if the OpenID provider supports it with PKCE without a client secret. No default value.

code

graphdb.auth.openid.token_type
(required)

OpenID token type to send to GraphDB. The available values are access and id. Use the access token if it is a JWT token, otherwise use the id token. No default value.

access

graphdb.auth.openid.token_issuer

OpenID expected issuer URL in tokens, used to validate tokens. The default is the same as the actual issuer URL.

https://accounts.example.com/custom

graphdb.auth.openid.token_audience

OpenID expected audience in tokens, used to validate tokens. The default is the same as the client ID.

<my-audience>

graphdb.auth.openid.authorize_parameters

OpenID extra parameters for the authorize endpoint. Some OpenID providers require additional parameters sent to the authorize endpoint (e.g., resource=xxx). This is a URL-encoded string where each parameter-value pair is delimited by &. The string will be appended to the rest of the authorize URL parameters. The default value is the empty string.

param1=value%201&param2=value%202

graphdb.auth.openid.proxy

OpenID uses GraphDB as proxy for the JWKS URL and token endpoints. This can be used to bypass an OpenID provider without a proper CORS configuration. The value is a boolean true/false. False by default.

false

graphdb.auth.openid.extra_scopes

OpenID extra scopes to request. Multiple scopes can be specified by separating them with a space. By default, GraphDB requests only the ‘openid’ scope and, if supported, the ‘offline_access’ scope. Scopes are used to request sets of claims, e.g., you might need to set this to a provider-specific value in order to obtain the username_claim or the roles_claim (if using OAuth as well). The default value is empty.

profile email

graphdb.auth.openid.oracle_domain

OpenID Oracle identity domain. Oracle Access Manager has a non-standard OpenID implementation that requires an additional parameter – the Oracle identity domain name. If you use OAM, set this to your identity domain name.

my-oracle-domain

Note

Logging out in this mode when using the GraphDB Workbench only deletes the GraphDB session without logging you out from your provider account.

Configuring the OpenID provider

The OpenID provider needs to be configured as well, as the GraphDB Workbench will use its own root browser URL, e.g., https://graphdb.example.com:7200/ (note the terminating slash) as the redirect_uri parameter when it redirects the browser to the authorization endpoint. Once the login is completed at the remote end, OIDC mandates that the identity provider redirects back to the supplied redirect_uri.

Typically, the allowed values for redirect_uri must be registered with the OpenID provider.

Kerberos authentication

Tip

See also the example configurations for Kerberos + Local users and Kerberos + LDAP.

Kerberos is a highly secure single sign-on protocol that uses tickets for authentication, and avoids storing passwords locally or sending them over the Internet. The authentication mechanism involves communication between a trusted third-party connection encrypted with symmetric-key cryptography. Although considered a legacy technology, Kerberos is still the default single sign-on mechanism in big Windows-based enterprises, and is an alternative of OpenID authentication.

The basic support for authentication via Kerberos in GraphDB involves:

  • Validation of SPNEGO HTTP Authorization tokens. For example:

    Authorization: Negotiate XXXXXXX
    
  • Extraction of the username from the SPNEGO token and matching the username against a user from the local database or a user from LDAP.

SPNEGO is the mechanism that integrates Kerberos with HTTP authentication.

After the token is validated and matched to an existing user, the process continues with authorization (assigning user roles) via the existing mechanism.

Using Kerberos this way is equivalent to authenticating via Basic, GDB, or OpenID.

Configuring Kerberos in GraphDB

In order to validate incoming SPNEGO tokens, the Spring Security Kerberos module needs a Kerberos keytab (a set of keys associated with a particular Kerberos account) and a service principal (the username of the associated Kerberos account). This account is used only to validate and decrypt the incoming SPNEGO tokens and is not associated with any user in GraphDB. See more on how to create a keytab file here.

Enable Kerberos with the following property:

graphdb.auth.methods = basic, gdb, kerberos

The default value is basic, gdb.

Kerberos is configured via several properties:

Property

Description

Example value

graphdb.auth.kerberos.keytab
(required)

Full or relative (to the GraphDB config directory) path to where the keys of the Kerberos service principal are stored. Required if Kerberos is enabled.

graphdb-http.keytab

graphdb.auth.kerberos.principal
(required)

Name of the Kerberos service principal. Required if Kerberos is enabled.

HTTP/data.example.com@EXAMPLE.COM

graphdb.auth.kerberos.debug

Whether some of the Spring Kerberos classes print extra messages related to Kerberos.

false

In addition, you might want to specify a custom krb5.conf file via the java.security.krb5.conf property but Java should be able to pick up the default system file automatically.

User matching

Kerberos principals (usernames) need to be matched to GraphDB usernames. A Kerberos principal consists of a username, followed by @, followed by a realm. The realm looks like a domain name and is usually written out in capital letters. The principals are converted by simply dropping the @ sign and the realm. However, the realm from incoming SPNEGO tokens must match the realm of the service principal. Some examples:

Service principal

Principal from SPNEGO token

Username in GraphDB

HTTP/data.example.com@EXAMPLE.COM

john@EXAMPLE.COM

john

HTTP/data.example.com@EXAMPLE.COM

john@FOO.EXAMPLE.COM

Invalid authentication because of realm mismatch

Using SPNEGO tokens with GraphDB

There are various ways to use SPNEGO when talking to GraphDB as a client. All methods add the Kerberos/SPNEGO authentication in the HTTP client used by the RDF4J libraries.

Native method

The native method does not require any third-party libraries and relies on the built-in Kerberos capabilities of Java and Apache’s HttpClient. However, it is a bit cumbersome to use since it requires wrapping calls into an authentication context. This method supports only non-preemptive authentication, i.e., the GraphDB server must explicitly say it needs Kerberos/SPNEGO by sending a WWW-Authenticate: Negotiate header to the client.

Third-party library method

There is a third-party library called kerb4j, which makes some things easier. It does not require wrapping the execution into an authentication context and supports preemptive authentication, i.e., sending the necessary headers without asking the server if it needs authentication.

Both methods are illustrated in this example project.

Example configurations

This is a list of example configurations for some of the possible combinations of authentication methods (Basic, GDB, OpenID, and Kerberos) with the three supported user databases for authorization (Local, LDAP, and OAuth).

Hint

The OpenID, Kerberos and LDAP part of the examples is identical in all cases but is repeated for convenience.

Basic/GDB + LDAP

Example configuration of Basic and GDB authentication + LDAP authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BASIC AUTHENTICATION AND GDB AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# The methods basic and gdb are active by default but may be provided explicitly as such:
graphdb.auth.methods = basic, gdb

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LDAP AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Turn on ldap authentication and configure the server.
graphdb.auth.database = ldap
graphdb.auth.ldap.url = ldap://localhost:10389/dc=example,dc=org

# Permit access for all users that are part of the “people” unit of the fictional “example.org” organization.
graphdb.auth.ldap.user.search.base = ou=people
graphdb.auth.ldap.user.search.filter = (cn={0})

# Make all users in the Administration group GraphDB administrators as well.
graphdb.auth.ldap.role.search.base = ou=groups
graphdb.auth.ldap.role.search.filter = (member={1})
graphdb.auth.ldap.role.map.administrator = Administration

# Make all users in the Management group GraphDB Repository Managers as well.
graphdb.auth.ldap.role.map.repositoryManager = Management

# Enable all users in the Readers group to read the my_repo repository.
graphdb.auth.ldap.role.map.repository.read.my_repo = Readers

# Enable all users in the Writers group to write and read the my_repo repository.
graphdb.auth.ldap.role.map.repository.write.my_repo = Writers

# Required for accessing a LDAP server that does not allow anonymous binds and anonymous access.
graphdb.auth.ldap.bind.userDn = uid=userId,ou=people,dc=example,dc=org
graphdb.auth.ldap.bind.userDn.password = 123456

OpenID + Local users

Example configuration of OpenID authentication + local user database authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OPENID AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Enable OpenID authentication.
graphdb.auth.methods = openid
#  or alternatively with enabled Basic and GDB password authentication:
#graphdb.auth.methods = basic, gdb, openid

# OpenID issuer URL, used to derive keys endpoints and token validation.
graphdb.auth.openid.issuer = https://accounts.example.com

# OpenID client ID used to authenticate and validate tokens.
graphdb.auth.openid.client_id = my-client-id

# OpenID claim to use as the GraphDB username.
graphdb.auth.openid.username_claim = email

# OpenID authentication flow: code, code_no_pkce or implicit.
graphdb.auth.openid.auth_flow = code

# OpenID token type to send to GraphDB.
graphdb.auth.openid.token_type = access

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LOCAL USER AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# The local database is the default setting but it may be set explicitly as such:
graphdb.auth.database = local

OpenID + LDAP

Example configuration for OpenID authentication + LDAP authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OPENID AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Enable OpenID authentication.
graphdb.auth.methods = openid
#  or alternatively with enabled Basic and GDB password authentication:
#graphdb.auth.methods = basic, gdb, openid

# OpenID issuer URL, used to derive keys endpoints and token validation.
graphdb.auth.openid.issuer = https://accounts.example.com

# OpenID client ID used to authenticate and validate tokens.
graphdb.auth.openid.client_id = my-client-id

# OpenID claim to use as the GraphDB username.
graphdb.auth.openid.username_claim = email

# OpenID authentication flow: code, code_no_pkce or implicit.
graphdb.auth.openid.auth_flow = code

# OpenID token type to send to GraphDB.
graphdb.auth.openid.token_type = access

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LDAP AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Turn on ldap authentication and configure the server.
graphdb.auth.module = ldap
graphdb.auth.ldap.url = ldap://localhost:10389/dc=example,dc=org

# Permit access for all users that are part of the “people” unit of the fictional “example.org” organization.
graphdb.auth.ldap.user.search.base = ou=people
graphdb.auth.ldap.user.search.filter = (cn={0})

# Make all users in the Administration group GraphDB administrators as well.
graphdb.auth.ldap.role.search.base = ou=groups
graphdb.auth.ldap.role.search.filter = (member={1})
graphdb.auth.ldap.role.map.administrator = Administration

# Make all users in the Management group GraphDB Repository Managers as well.
graphdb.auth.ldap.role.map.repositoryManager = Management

# Enable all users in the Readers group to read the my_repo repository.
graphdb.auth.ldap.role.map.repository.read.my_repo = Readers

# Enable all users in the Writers group to write and read the my_repo repository.
graphdb.auth.ldap.role.map.repository.write.my_repo = Writers

# Required for accessing a LDAP server that does not allow anonymous binds and anonymous access.
graphdb.auth.ldap.bind.userDn = uid=userId,ou=people,dc=example,dc=org
graphdb.auth.ldap.bind.userDn.password = 123456

OpenID + OAuth

Example configuration for OpenID authentication + OAuth authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OPENID AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Enable OpenID authentication.
graphdb.auth.methods = openid

# OpenID issuer URL, used to derive keys endpoints and token validation.
graphdb.auth.openid.issuer = https://accounts.example.com

# OpenID client ID used to authenticate and validate tokens.
graphdb.auth.openid.client_id = my-client-id

# OpenID claim to use as the GraphDB username.
graphdb.auth.openid.username_claim = email

# OpenID authentication flow: code, code_no_pkce or implicit.
graphdb.auth.openid.auth_flow = code

# OpenID token type to send to GraphDB.
graphdb.auth.openid.token_type = access

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OAUTH AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# OAuth roles claim. The field from the JWT token that will provide the GraphDB roles.
graphdb.auth.oauth.roles_claim = roles

# OAuth roles prefix to strip. The roles claim may provide the GraphDB roles with some prefix, e.g., GDB_ROLE_USER.
# The prefix will be stripped when the roles are mapped.
graphdb.auth.oauth.roles_prefix = GDB_

# OAuth default roles to assign. It may be convenient to always assign certain roles without listing them in the roles claim.
graphdb.auth.oauth.default_roles = ROLE_USER

Kerberos + Local users

Example configuration for Kerberos authentication + local user database authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KERBEROS AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Enable Kerberos authentication and keep Basic and GDB authentication enabled.
graphdb.auth.methods = basic, gdb, kerberos

# Provides the Kerberos keytab file relative to the GraphDB config directory.
graphdb.auth.kerberos.keytab = graphdb-http.keytab

# Provides the Kerberos principal for GraphDB running at data.example.org and Kerberos users from
# the realm EXAMPLE.ORG.
graphdb.auth.kerberos.principal = HTTP/data.example.org@EXAMPLE.ORG

# Enable Kerberos debug messages (recommended when you first setup Kerberos, can be disabled later).
graphdb.auth.kerberos.debug = true

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LOCAL USER AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# The local database is the default setting but it may be set explicitly as such:
graphdb.auth.database = local

Kerberos + LDAP

Example configuration for Kerberos authentication + LDAP authorization:

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KERBEROS AUTHENTICATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Enable Kerberos authentication and keep Basic and GDB authentication enabled.
graphdb.auth.methods = basic, gdb, kerberos

# Provides the Kerberos keytab file relative to the GraphDB config directory.
graphdb.auth.kerberos.keytab = graphdb-http.keytab

# Provides the Kerberos principal for GraphDB running at data.example.org and Kerberos users from
# the realm EXAMPLE.ORG.
graphdb.auth.kerberos.principal = HTTP/data.example.org@EXAMPLE.ORG

# Enable Kerberos debug messages (recommended when you first setup Kerberos, can be disabled later).
graphdb.auth.kerberos.debug = true

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LDAP AUTHORIZATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# Turn on ldap authentication and configure the server.
graphdb.auth.module = ldap
graphdb.auth.ldap.url = ldap://localhost:10389/dc=example,dc=org

# Permit access for all users that are part of the “people” unit of the fictional “example.org” organization.
graphdb.auth.ldap.user.search.base = ou=people
graphdb.auth.ldap.user.search.filter = (cn={0})

# Make all users in the Administration group GraphDB administrators as well.
graphdb.auth.ldap.role.search.base = ou=groups
graphdb.auth.ldap.role.search.filter = (member={1})
graphdb.auth.ldap.role.map.administrator = Administration

# Make all users in the Management group GraphDB Repository Managers as well.
graphdb.auth.ldap.role.map.repositoryManager = Management

# Enable all users in the Readers group to read the my_repo repository.
graphdb.auth.ldap.role.map.repository.read.my_repo = Readers

# Enable all users in the Writers group to write and read the my_repo repository.
graphdb.auth.ldap.role.map.repository.write.my_repo = Writers

# Required for accessing a LDAP server that does not allow anonymous binds and anonymous access.
graphdb.auth.ldap.bind.userDn = uid=userId,ou=people,dc=example,dc=org
graphdb.auth.ldap.bind.userDn.password = 123456