Access Control¶

What’s in this document?

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 RBAC₁ 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. See how to configure free access here.

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 data directory. 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 Setup ‣ My Settings in the GraphDB Workbench.

Warning

If you unset the password for any user and then enable security, that user will not be able to log into GraphDB. The only way to log in would be through OpenID or Kerberos authentication.

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` file 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.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.	`ROLE_USER`
`graphdb.auth.oauth.roles_prefix`	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.	`GDB_`
`graphdb.auth.oauth.roles_suffix`	OAuth roles suffix to strip. The roles claim may provide the GraphDB roles with some suffix, e.g., GDB_ROLE_USER. The suffix will be stripped when the roles are mapped. The default value is the empty string.	`_GDB`

Note

GraphDB enables case-insensitive validation for user accounts so that users can log in regardless of the case used at login time. For example, if the user database contains a user “john.smith”, they can log in using any of these:

john.smith
John.Smith
JOHN.SMITH
JOHN.smitH

This is controlled via the boolean config property graphdb.auth.database.case_insensitive. It is optional and false by default.

When using the local database, it is enough to just set graphdb.auth.database.case_insensitive = true.

When using an external user database (LDAP, OpenID), the external database must support case-insensitive login as well.

Authentication methods ¶

Whenever a client connects to GraphDB, a security context is created. Each security context is always associated with a single 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:

curl -X POST -I 'http://localhost:7200/rest/login' -H 'Content-type: application/json' -d '{
     "username": "admin",
     "password": "root"
}'

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

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.

Note

The token secret is used to sign the internal cluster communication and needs to be the same on all cluster nodes.

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