StarDog, OIDC authorization and Defence-in-depth

Support
1

Hello - I would like achieve end-to-end authorization for an application, StarDog and virtual graphs - all based on the credentials obtained from an OIDC Identity Provider.

Something like the following

  1. The user logs into the application, they obtain a JWT from the OIDC identity provider.
  2. The application uses the credentials in the JWT to allow /deny the user features.
  3. The application issues a SPARQL query to StarDog - it passes the JWT in the query header
  4. StarDog calls the OIDC IDP with the JWT and receives temporary credentials. The credentials allow /deny the user access to Named Graphs
  5. StarDog calls a virtual graph to run a SQL query to obtain data from an external source. It includes the JWT in the SQL query.
  6. I assume the the external SQL engine calls the ODIC IDP with the JWT and receives temporary credentials. The credentials allow or deny access to tables or columns.

Is there a design pattern for this?

2

Yes, this pattern is well-supported in Stardog as follows:

App -> Stardog (JWT auth + named graph access control) Stardog accepts JWTs from any OIDC-compliant IdP in the Authorization: Bearer header. Configure Stardog to trust your IdP via its JWKS endpoint, map JWT role/group claims to Stardog roles, and enable named graph security. Users will automatically be allowed or denied access to specific named graphs based on their JWT-derived roles. This works with any standards-compliant IdP.

Stardog -> Virtual Graph (credential pass-through) Stardog does support passing user credentials through to the underlying SQL engine so that the engine can enforce its own table/column-level policies. Currently this is implemented specifically for Microsoft Entra ID + Databricks, using the OAuth On-Behalf-Of flow. For other IdP/database combinations, virtual graph queries run under shared service credentials. In that case, you'd enforce data-level restrictions at the Stardog layer instead, using named graph security and fine-grained / sensitive property masking.

Relevant docs:

If end-to-end per-user identity propagation to the SQL engine is a hard requirement and you're not using Entra ID, that's worth raising directly with Stardog. It's an area of active development.

3

While having options not based on Entra ID would be great, what if you are using Entra ID but not Databricks or Snowflake?

4

Thanks for responding and for the links to the documentation.

Ideally StarDog would operate using Entra IDs. I see support for these in the documentation.

The Entra IDs are synced to create equivalent AWS IAM users. AWS Lake Formation grants IAM users access to Athena's resources - S3 and Glue.

I would like to StarDog's Virtual Graphs to resolve to AWS data resources - especially Athena. If StarDog could exchange its Entra ID to obtain an IAM Access token (a call an AWS Identity center API) then StarDog could make JDBC calls to Athena under that IAM user (same individual).

Is this token exchange with IAM available or on StarDog's roadmap?