GraphDB Users Ask: How Does GraphDB’s Security Work, Especially for Automated APIs?

ONTOTEXT ANSWER:

GraphDB has a fairly versatile suite of authentication and authorization providers. When it comes to authentication, essentially, there are three providers:

• Basic authentication – the username and password are provided plainly in the URL. For example, https://user:password@graphdb.com/. This is a very easy workaround for small tests. However, it does not scale and presents a very big security risk.
• Local authentication with JWT – the REST API for authentication is activated. The user gives their details and a Java Web Token (JWT) is generated for them, if they are present in the local database. This uses the GraphDB API.
• Remote authentication with JWT (Single Sign On) – the REST API for authentication is disabled. The user gives their details and a Java Web Token (JWT) is generated for them, if they are present in the remote security provider. This uses the remote security provider API. There are two options:
  • OIDC-compliant providers such as FusionAuth and Keycloak
  • Kerberos

However, authentication is only part of the problem. GraphDB employs Role-based access control (RBAC) to determine the access rights of its users. Essentially, it can use one of two authorization providers for this:

• Local security – the default. Users are created locally and their permissions are assigned via the Ontotext API. Their passwords are encrypted and stored at the local filesystem. This is great for development and prototyping, but hard to scale.
• SSO – the users are managed and stored at the remote security provider and the remote security provider is used for this. There are two SSO providers:
  • LDAP – in this case, the security configuration is provided by filters within the properties file. Users are managed by your LDAP provider. You can use other providers utilizing the LDAP protocol, e.g., Active Directory.
  • Oauth – in this case, access is granted according to the roles of the users. For example, a user must have the role READ_REPO_TEST to have read access over the repository “test”.

Here’s the compatibility matrix for our security providers.

This means that in order to use Oauth as your single sign on, you are restricted to Open ID connect. However, in this case, the GraphDB Security API is disabled and only the UI access via the Workbench remains. For automated access to the database, this gives you two approaches:

• Log in via the workbench and intercept the JWT from your “Authorization” header by using the developer console, or a more sophisticated automated tool. This is obviously not scalable, but might be the best solution for manual testing and exploration.
• Log in via your SSO of choice’s API and using the JWT it has provided for further authentication requests.

Alternatively, if you really want to use GraphDB’s security API for your scripts, you can switch to using the Local or LDAP authorization providers.