docs: updated and added OIDC credential forwarding #2692
Conversation
|
Maybe we should have a figure showing the OIDC flow as well... Something like the one bellow. As of now, the added documentation is written as if there is a figure included. |
| ---- | ||
|
|
||
|
|
||
| [[alias-management-create-remote-database-alias]] |
There was a problem hiding this comment.
This page begins with a table for SHOW ALIAS, do we want to update that in this PR or do we want to leave the SHOW update as a separate PR?
There was a problem hiding this comment.
Might add this into this PR, but Therese mentioned if we wanted to have the column behind the feature flag or not... Have to think about that one, do you have any preferences? We would return STORED NATIVE CREDENTIALS for remote aliases and null otherwise. We have started to describe OIDC in other places in the documentation so we might just keep it as is and don't have it behind the feature flag
| When creating a remote database alias, the credentials used to target to the remote DBMS need to be specified. This can be done by providing the credentials of a native user, or | ||
| by forwarding the OIDC credentials of the user logged in to the local DBMS. |
There was a problem hiding this comment.
We probably need to have one of these version tags somewhere indicating that CREDENTIAL FORWARDING is new.
I believe we would want that to show the version in which we set internal.cypher.enable_oidc_credential_forwarding to default to true. Before we set that flag to true I think we would want the SHOW updates to be done and also have done our manual testing.
Question for the docs reviewer: Do we ever document features that aren't released yet, e.g. "This feature is in beta and you need to set config x.y.z=true to access it"
There was a problem hiding this comment.
I've added a few labels now
| +-----------------------------------------------------------------------------------------------------------------------------+ | ||
| ---- | ||
|
|
||
| The `OIDC CREDENTIAL FORWARDING` clause is used to configure a remote database alias to use the logged-in user's OIDC credentials to authenticate to the remote DBMS. |
There was a problem hiding this comment.
We should be very clear that this feature only works with OIDC, maybe link to the OIDC docs even? https://neo4j.com/docs/operations-manual/current/authentication-authorization/sso-integration/
Unrelated to the docs:
We should test what happens if you create a credential forwarding alias on a DBMS that doesn't have any OIDC providers. Maybe that should also return the "this has no effect" notification?
We should also test what happens if you attempt to access a credential forwarding alias with native/LDAP auth.
There was a problem hiding this comment.
I'v added a note under the Connect to remote database aliases section
| dbms.ssl.policy.bolt.client_auth=NONE | ||
| # enforcing ssl connection | ||
| server.bolt.tls_level=REQUIRED |
There was a problem hiding this comment.
We may want the OIDC settings here as well, to show that they should be the same on both DBMSs
dbms.security.oidc.<provider>.config=
dbms.security.oidc.<provider>.token_endpoint=
dbms.security.oidc.<provider>.issuer=
dbms.security.oidc.<provider>.params=
dbms.security.oidc.<provider>.audience=
dbms.security.oidc.<provider>.display_name=
dbms.security.oidc.<provider>.well_known_discovery_uri=
dbms.security.oidc.<provider>.claims.groups=
There was a problem hiding this comment.
Although it adds a lot of noise as well, maybe something like this is more useful?
# OIDC settings - these should be the same on both DBMSs
dbms.security.oidc.<provider>.well_known_discovery_uri=http://example.com/.well-known/discovery
<...>
dbms.security.oidc.<provider>.claims.groups=groups
dbms.security.oidc.<provider>.authorization.group_to_role_mapping= "engineers" = admin; \
"collaborators" = reader
There was a problem hiding this comment.
Went for the second option here
| . Set up SSO and support for the identity provider. | ||
| . Map the identity provider groups to the Neo4j roles. This is where the permission to use the remote database alias is set. |
There was a problem hiding this comment.
I think we might want more details here. I.e. the same OIDC config as for B, and maybe the command to create the alias and the commands to give Carol a role with access on the alias.
There was a problem hiding this comment.
Duplicated and moved the Manage remote database aliases section to be included under both setup examples. A bit of duplicate information but might be a better way of having it, the Connect to remote database aliases still lies outside the two setup examples.
evelinadanielsson
force-pushed
the
dev-update-create-show-remote-database-alias-docs
branch
from
1d858a2 to
8d95871
Compare
|
This PR includes documentation updates Updated pages: |
| When using `OIDC CREDENTIAL FORWARDING` the actual end-user's credentials and permissions will be used, this will result in per-user audit trails being logged on the remote DBMS. | ||
| ==== | ||
|
|
||
| [NOTE] |
There was a problem hiding this comment.
A lot of [NOTE] containers after each other, is this ok or should we structure it in a different way?
3 participants
We have added OIDC credential forwarding as an additional way to configure a remote database alias. We need to update and add documentation to describe how it is supposed to be used and how it works.