Skip to content

Commit ea7f533

Browse files
phil198Hunternessrenetapopova
committed
User Auth Providers (neo4j#1745)
This PR is for the examples and general description of the User Auth Providers feature. Its currently applicable to native auth, LDAP and OIDC. --------- Co-authored-by: Therese Magnusson <[email protected]> Co-authored-by: Reneta Popova <[email protected]>
1 parent 1100792 commit ea7f533

13 files changed

+1002
-199
lines changed

modules/ROOT/content-nav.adoc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -184,6 +184,7 @@
184184
*** xref:authentication-authorization/manage-execute-permissions.adoc[]
185185
** xref:authentication-authorization/built-in-roles.adoc[]
186186
** Integration with auth systems
187+
*** xref:authentication-authorization/auth-providers.adoc[]
187188
*** xref:authentication-authorization/ldap-integration.adoc[]
188189
*** xref:authentication-authorization/sso-integration.adoc[]
189190

modules/ROOT/images/privileges_grant_and_deny_syntax_dbms_privileges.svg

Lines changed: 1 addition & 9 deletions
Loading

modules/ROOT/images/privileges_hierarchy_dbms.svg

Lines changed: 1 addition & 10 deletions
Loading
Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
:description: This section explains how to use Cypher to manage authentication and authorization at the user level using Cypher.
2+
:page-role: enterprise-edition new-5.24
3+
4+
[[access-control-auth-providers]]
5+
= User auth providers
6+
7+
Authentication and authorization can be controlled on a user level using Cypher by setting auth providers on users.
8+
9+
To use auth providers, you need to set the xref:configuration/configuration-settings.adoc#config_dbms.security.require_local_user[`dbms.security.require_local_user`] configuration setting to `true`.
10+
This setting mandates that users with the relevant auth provider attached to them must exist in the database before they can authenticate and authorize with that auth provider.
11+
12+
User auth providers allow you to link externally-defined users (e.g., in a third-party ID provider like OIDC or LDAP) to the Neo4j internal user model.
13+
The internal model can define roles (authorization), `SUSPENDED` status, `HOME DATABASE`, and metadata such as the unique displayed name of the user.
14+
For consistency, you can also define `native` (password-based) auth using the auth provider syntax, including native-only users (i.e., users who can only authenticate with a password).
15+
16+
== Use cases
17+
18+
User auth providers can be used for a variety of use cases, including:
19+
20+
* Provisioning different auth providers (including native username/password auth) for different users.
21+
* Setting an arbitrary easy username for a user while using an external unique identifier (like `sub` for OIDC auths, which itself is not a user-friendly value).
22+
* Setting `HOME DATABASE` for externally authenticated users.
23+
* Setting `SUSPENDED` status for an externally authenticated user.
24+
* Using native authorization to manage roles for externally authenticated users.
25+
* Retaining full control of which users can authenticate from within the database.
26+
27+
== How it works
28+
29+
When a user authenticates, their identifying attributes are checked against the relevant property of the auth providers in the database.
30+
If there is a match, then the user is linked to the Neo4j user and authorized according to the DBMS security configuration settings that match the name of the matching auth provider.
31+
32+
How the matching lookup is done depends on the type of provider.
33+
For example:
34+
35+
* For an OIDC provider, the claim configured by xref:configuration/configuration-settings.adoc#config_dbms.security.oidc.-provider-.claims.username[`dbms.security.oidc.mysso.claims.username`] (default `sub`) is taken from the token and is used to look up an auth provider whose `ID` and `provider` properties match the `sub` and provider respectively of the OIDC provider.
36+
* For an LDAP provider, the `dn` is used to look up an auth provider with a `provider` property of `ldap` and an `ID` property that matches the supplied `dn`.
37+
* For the `native` (username/password) provider, the supplied username itself is used to look up the auth provider.
38+
39+
== Enabling user auth providers mode
40+
41+
To enable user auth providers mode, set the configuration setting xref:configuration/configuration-settings.adoc#config_dbms.security.require_local_user[`dbms.security.require_local_user`] to `true`.
42+
This setting mandates that users with the relevant auth provider attached to them must exist in the database before they can authenticate and authorize with that auth provider.
43+
44+
When the user authenticates, Neo4j searches for a user with a matching authentication provider.
45+
If a match is found, the user can log in and be authorized successfully.
46+
47+
== Migrating to auth providers mode
48+
49+
If you have existing users in the database and want to migrate to auth providers mode, you can use the `ALTER USER ... SET AUTH` command to attach an auth provider to each of them.
50+
Until you change `dbms.security.require_local_user` to `true`, this will not impact the users' ability to authenticate and authorize as they always have done.
51+
52+
Once the process of adding auth providers to your users finishes, you can set `dbms.security.require_local_user` to `true` and restart the DBMS to complete the migration.
53+
After this time, only users with a corresponding auth provider in the database will be able to authenticate and authorize.
54+
55+
[NOTE]
56+
====
57+
Existing users created using the original `CREATE USER ... SET PASSWORD` command implicitly have the native (username/password) auth provider, so you do not need to add it explicitly using `SET AUTH`.
58+
59+
To verify which auth providers are attached to a user, use the xref:authentication-authorization/manage-users.adoc#access-control-list-users[`SHOW USERS WITH AUTH`] command.
60+
====
61+
62+
== Examples
63+
64+
For examples of how to use auth providers with different authentication providers, see the following sections:
65+
66+
- xref:authentication-authorization/sso-integration.adoc#auth-sso-auth-providers[Configure SSO at the user level using auth providers]
67+
- xref:authentication-authorization/manage-users.adoc#access-control-create-users[Creating users]
68+
- xref:authentication-authorization/ldap-integration.adoc#auth-ldap-auth-providers[Configure authentication/authorization at the user level using LDAP as an auth provider]
69+

modules/ROOT/pages/authentication-authorization/dbms-administration.adoc

Lines changed: 18 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -68,9 +68,9 @@ All DBMS privileges are relevant system-wide.
6868
Like user management, they do not belong to one specific database or graph.
6969
For more details on the differences between graphs, databases, and the DBMS, refer to link:{neo4j-docs-base-uri}/cypher-manual/{page-version}/introduction/cypher_neo4j/[Cypher Manual -> Cypher and Neo4j].
7070

71-
image::privileges_grant_and_deny_syntax_dbms_privileges.svg[title="Syntax of GRANT and DENY DBMS Privileges"]
71+
image::privileges_grant_and_deny_syntax_dbms_privileges.svg[width="800", title="Syntax of GRANT and DENY DBMS Privileges"]
7272

73-
image::privileges_hierarchy_dbms.svg[title="DBMS privileges hierarchy"]
73+
image::privileges_hierarchy_dbms.svg[width="800", title="DBMS privileges hierarchy"]
7474

7575
The xref:authentication-authorization/built-in-roles.adoc#access-control-built-in-roles-admin[`admin` role] has a number of built-in privileges.
7676
These include:
@@ -466,6 +466,12 @@ GRANT [IMMUTABLE] SET PASSWORD[S]
466466
TO role[, ...]
467467
| Enables the specified roles to modify users' passwords and whether those passwords must be changed upon first login.
468468

469+
| [source, syntax, role=noheader]
470+
GRANT [IMMUTABLE] SET AUTH
471+
ON DBMS
472+
TO role[, ...]
473+
| label:new[Introduced in 5.24] Enables the specified roles to `SET` or `REMOVE` users' xref:authentication-authorization/auth-providers.adoc[auth providers].
474+
469475
| [source, syntax, role=noheader]
470476
GRANT [IMMUTABLE] SET USER HOME DATABASE
471477
ON DBMS
@@ -571,7 +577,7 @@ SHOW ROLE userModifier PRIVILEGES AS COMMANDS
571577
a|Rows: 1
572578
|===
573579

574-
A user that is granted the `ALTER USER` privilege is allowed to run the `ALTER USER` administration command with one or several of the `SET PASSWORD`, `SET PASSWORD CHANGE [NOT] REQUIRED` and `SET STATUS` parts:
580+
A user that is granted the `ALTER USER` privilege is allowed to run the `ALTER USER` administration command with one or several of the `SET PASSWORD`, `SET PASSWORD CHANGE [NOT] REQUIRED`, `SET AUTH`, `REMOVE AUTH` and `SET STATUS` parts:
575581

576582
[source, cypher, role=noplay]
577583
----
@@ -609,6 +615,14 @@ A user that is granted the `SET PASSWORDS` privilege is allowed to run the `ALTE
609615
ALTER USER jake SET PASSWORD 'abcd5678' CHANGE NOT REQUIRED
610616
----
611617

618+
label:new[Introduced in 5.24] A user that is granted the `SET AUTH` privilege is allowed to run the `ALTER USER` administration command with one or both of the `SET AUTH` and `REMOVE AUTH` parts:
619+
620+
[source, cypher, role=noplay]
621+
----
622+
ALTER USER jake REMOVE AUTH 'native SET AUTH 'oidc-okta' { SET id 'jakesUniqueOktaUserId' }
623+
----
624+
625+
612626
The ability to modify the account status of users can be granted via the `SET USER STATUS` privilege.
613627
See an example:
614628

@@ -679,7 +693,7 @@ ALTER USER jake REMOVE HOME DATABASE
679693

680694
[NOTE]
681695
====
682-
Note that the combination of the `SET PASSWORDS`, `SET USER STATUS`, and the `SET USER HOME DATABASE` privilege actions is equivalent to the `ALTER USER` privilege action.
696+
Note that the combination of the `SET PASSWORDS`, `SET AUTH`, `SET USER STATUS`, and the `SET USER HOME DATABASE` privilege actions is equivalent to the `ALTER USER` privilege action.
683697
====
684698

685699
The ability to delete users can be granted via the `DROP USER` privilege.

modules/ROOT/pages/authentication-authorization/index.adoc

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,10 @@ When triggered, Neo4j logs an error containing a timestamp and the message `fail
3131
For the relevant Cypher commands, see xref:authentication-authorization/manage-users.adoc#access-control-user-syntax[Manage users syntax], xref:authentication-authorization/manage-roles.adoc#access-control-role-syntax[Manage roles syntax], and xref:authentication-authorization/manage-privileges.adoc#access-control-privileges-syntax[Manage privileges syntax].
3232
Various scenarios that illustrate the use of the native auth provider are available in xref:tutorial/access-control.adoc[].
3333

34+
*User auth providers*::
35+
User auth providers allow you to link externally-defined users (e.g., in a third-party ID provider like OIDC or LDAP) to the Neo4j internal user model.
36+
For more information, see xref:authentication-authorization/auth-providers.adoc[User auth providers].
37+
3438
*LDAP auth provider*::
3539
Controls authentication and authorization through external security software such as Active Directory or OpenLDAP, which is accessed via the built-in LDAP connector.
3640
A description of the LDAP plugin using Active Directory is available in xref:authentication-authorization/ldap-integration.adoc[Integration with LDAP directory services].
@@ -93,6 +97,15 @@ This is in contrast to a suspended user.
9397
[[term-administrator]]administrator::
9498
This is a user who has been assigned the admin role.
9599

100+
[[term-auth-provider]]auth provider::
101+
Properties attached to a user which define which authentication and authorization config to use for that user.
102+
103+
[[term-authentication]]authentication::
104+
The process of verifying the identity of a user, typically using credentials like a username and password or a cryptographic token like a JWT.
105+
106+
[[term-authorization]]authorization::
107+
The process of determining a user's access rights and privileges within Neo4j, based on their verified identity.
108+
96109
[[term-current-user]]current user::
97110
This is the currently logged-in user invoking the commands.
98111

modules/ROOT/pages/authentication-authorization/ldap-integration.adoc

Lines changed: 131 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -3,30 +3,6 @@
33
= LDAP integration
44
:description: This page describes Neo4j support for integrating with LDAP systems.
55

6-
This page describes Neo4j support for integrating with LDAP systems.
7-
The following topics are covered:
8-
9-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-introduction[Introduction]
10-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-parameters[LDAP configuration parameters]
11-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider[Set Neo4j to use LDAP]
12-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-map-ldap-roles[Map the LDAP groups to the Neo4j roles]
13-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider-ad[Configure Neo4j to use Active Directory]
14-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider-ad-uid[Configure Neo4j to support LDAP user ID authentication]
15-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider-ad-sysaccount[Configure Neo4j to support attribute authentication]
16-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider-ad-nosysaccount[Configure Neo4j to support `sAMAccountName` authentication by setting `user_dn_template`]
17-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-nested-groups[Configure Neo4j to perform nested group lookup]
18-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-configure-provider-openldap[Configure Neo4j to use OpenLDAP]
19-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-search[Verify the LDAP configuration]
20-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-clear-auth-cache[The auth cache]
21-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-ad-encrypted[Available methods of encryption]
22-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-encrypted-starttls[Use LDAP with encryption via StartTLS]
23-
** xref:authentication-authorization/ldap-integration.adoc#auth-ldap-encrypted-ldaps[Use LDAP with encrypted LDAPS]
24-
* xref:authentication-authorization/ldap-integration.adoc#auth-ldap-self-signed-certificate[Use a self-signed certificate (SSL) in a test environment]
25-
26-
27-
[[auth-ldap-introduction]]
28-
== Introduction
29-
306
Neo4j supports LDAP, which allows for integration with Active Directory (AD), OpenLDAP, or other LDAP-compatible authentication services.
317
This means that you use the LDAP service for managing federated users, while the native Neo4j user and role administration are completely turned off.
328

@@ -104,7 +80,7 @@ This way, the LDAP connector is used as a security provider for both authenticat
10480
If you want, you can still use the `native` provider for mixed-mode authentication and authorization.
10581
The values are comma-separated and queried in the declared order.
10682
+
107-
.Configure Neo4j to use LDAP and the native authentication and authorization provider.
83+
.Configure Neo4j to use LDAP and the native authentication and authorization provider
10884
======
10985
[source,configuration,role="noheader"]
11086
----
@@ -358,6 +334,136 @@ dbms.security.ldap.authorization.access_permitted_group=501
358334
. Map the groups in the LDAP system to the Neo4j built-in and custom roles.
359335
For more information, see xref:authentication-authorization/ldap-integration.adoc#auth-ldap-map-ldap-roles[Map the LDAP groups to the Neo4j roles].
360336

337+
[role=label--new-5.24]
338+
[[auth-ldap-auth-providers]]
339+
== Configure authentication/authorization at the user level using auth providers
340+
xref:authentication-authorization/auth-providers.adoc[User auth providers] can be used to determine which users can authenticate and authorize using the configured providers, including LDAP.
341+
342+
You must change the xref:configuration/configuration-settings.adoc#config_dbms.security.require_local_user[`dbms.security.require_local_user`] configuration setting to `true` to use auth providers.
343+
This means that a user with a matching auth provider *must* exist in order to be able to authenticate and authorize.
344+
This applies to all providers.
345+
346+
Conversely, when xref:configuration/configuration-settings.adoc#config_dbms.security.require_local_user[`dbms.security.require_local_user`] is set to `false`, users' auth providers have no bearing on the way that they are authenticated and authorized, instead authentication and authorization is controlled centrally (for all users) by the database configuration.
347+
348+
The following examples show how to configure users with auth provider `ldap` using Cypher.
349+
350+
.Create a user with an auth provider who can authenticate and authorize using `LDAP`
351+
======
352+
[source,cypher,role=noplay]
353+
----
354+
CREATE USER alice
355+
SET AUTH PROVIDER 'ldap' { SET ID 'cn=alice,ou=engineering,dc=example,dc=com' }
356+
----
357+
358+
The command creates the user `alice` who can authenticate and authorize using LDAP provided their LDAP `dn` is `cn=alice,ou=engineering,dc=example,dc=com`.
359+
======
360+
361+
.Create a user with two auth providers allowing the user to authenticate and authorize with either LDAP or the `mysso` provider
362+
======
363+
364+
[source,cypher,role=noplay]
365+
----
366+
CREATE USER alice
367+
SET HOME DATABASE anotherDb
368+
SET AUTH PROVIDER 'ldap' { SET ID 'cn=alice,ou=engineering,dc=example,dc=com' }
369+
SET AUTH 'oidc-mysso' {SET ID 'alicesUniqueMySsoId'}
370+
----
371+
372+
The command creates the user `alice` who can authenticate and authorize using `ldap` or `mysso`.
373+
See xref:authentication-authorization/sso-integration.adoc#auth-sso-auth-providers[Configure SSO at the user level using auth providers] for more information on setting up an OIDC provider.
374+
The example also illustrates that the user can have their home database set even when using only external auth providers.
375+
======
376+
377+
.Alter a user to remove one of their auth providers
378+
======
379+
380+
[source,cypher,role=noplay]
381+
----
382+
ALTER USER alice
383+
REMOVE AUTH 'ldap'
384+
----
385+
386+
The command prevents the user `alice` from being able to authenticate and authorize using `ldap`.
387+
======
388+
389+
.Alter a user to allow them to authenticate and authorize using username and password
390+
======
391+
392+
[source,cypher,role=noplay]
393+
----
394+
ALTER USER alice
395+
SET AUTH 'native' {SET PASSWORD 'changeme' SET PASSWORD CHANGE REQUIRED}
396+
----
397+
398+
The command allows the user `alice` to authenticate and authorize using the specified username and password (in addition to what they are already configured to use).
399+
======
400+
401+
402+
.Configure the database to allow authentication via `ldap` and authorization via the `native` provider
403+
======
404+
405+
. Set the following database config:
406+
+
407+
[source, properties]
408+
----
409+
dbms.security.authentication_providers=ldap
410+
dbms.security.authorization_providers=native
411+
----
412+
413+
. Create a user with an `ldap` auth provider:
414+
+
415+
[source,cypher,role=noplay]
416+
----
417+
CREATE USER alice
418+
SET AUTH PROVIDER 'ldap' { SET ID 'cn=alice,ou=engineering,dc=example,dc=com' }
419+
----
420+
421+
. Natively grant the `READER` role to the user:
422+
+
423+
[source,cypher,role=noplay]
424+
----
425+
GRANT ROLE READER TO alice
426+
----
427+
+
428+
The command allows the user `alice` to authenticate using `ldap` and receive the `READER` role from the `native` provider.
429+
430+
. You can also give the user the union of roles from `ldap` *and* `native` roles by setting `ldap` as an authorization provider too:
431+
+
432+
[source, properties]
433+
----
434+
dbms.security.authentication_providers=ldap
435+
dbms.security.authorization_providers=native,ldap
436+
----
437+
======
438+
439+
.Suspend a user
440+
======
441+
[source,cypher,role=noplay]
442+
----
443+
ALTER USER alice
444+
SET STATUS SUSPENDED
445+
446+
----
447+
The command completely prevents the user from being able to authenticate/authorize by any means.
448+
======
449+
450+
.Disambiguate users with the same name in different LDAP trees
451+
======
452+
453+
Suppose there are two users both with the name `alice`, one is part of the `engineering` tree (`cn=alice,ou=engineering,dc=example,dc=com`) and the other is part of the `sales` tree (`cn=alice,ou=sales,dc=example,dc=com`).
454+
455+
To disambiguate these users, you can create two users in the database, each with a different `ID` that corresponds to the `dn` of the user in the LDAP tree.
456+
457+
[source,cypher,role=noplay]
458+
----
459+
CREATE USER aliceEngineering
460+
SET AUTH 'ldap' { SET ID 'cn=alice,ou=engineering,dc=example,dc=com' }
461+
462+
CREATE USER aliceSales
463+
SET AUTH 'ldap' { SET ID 'cn=alice,ou=sales,dc=example,dc=com' }
464+
----
465+
======
466+
361467
[[auth-ldap-search]]
362468
== Verify the LDAP configuration
363469

modules/ROOT/pages/authentication-authorization/manage-roles.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -597,7 +597,7 @@ Users can be given access rights by assigning them roles using `GRANT ROLE`:
597597
GRANT ROLE myrole TO bob
598598
----
599599

600-
The roles assigned to each user can be seen on the list provided by `SHOW USERS`:
600+
The roles assigned to each user can be seen on the list provided by xref:authentication-authorization/manage-users.adoc#access-control-list-users[`SHOW USERS`]:
601601

602602
[source, cypher, role=noplay]
603603
----

0 commit comments

Comments
 (0)