diff --git a/nifi-docs/src/main/asciidoc/administration-guide.adoc b/nifi-docs/src/main/asciidoc/administration-guide.adoc index 8136ab993c267..7ba2053b91ace 100644 --- a/nifi-docs/src/main/asciidoc/administration-guide.adoc +++ b/nifi-docs/src/main/asciidoc/administration-guide.adoc @@ -425,6 +425,8 @@ The 'authorizers.xml' file is used to define and configure available authorizers and a AccessPolicyProvider. The users, group, and access policies will be loaded and optionally configured through these providers. The managed authorizer will make all access decisions based on these provided users, groups, and access policies. +During startup there is a check to ensure that there are no two users/groups with the same identity/name. This check is executed regardless of configured implementation. This is necessary because this is how users/groups are identified and authorized during access decisions. + The default UserGroupProvider is the FileUserGroupProvider, however, you can develop additional UserGroupProviders as extensions. The FileUserGroupProvider has the following properties: * Users File - The file where the FileUserGroupProvider stores users and groups. By default, the 'users.xml' in the 'conf' directory is chosen. @@ -464,13 +466,13 @@ Another option for the UserGroupProvider is the LdapUserGroupProvider. By defaul * Group Name Attribute - Attribute to use to extract group name (i.e. cn). Optional. If not set, the entire DN is used. * Group Member Attribute - Attribute to use to define group membership (i.e. member). Optional. If not set group membership will not be calculated through the groups. Will rely on group member being defined through 'User Group Name Attribute' if set. -Another option for the UserGroupProvider are composite implementations. This means that multiple sources/implementations can be configured and composed. For instance, an admin can configure users/groups to be loaded from a file and an directory server. There are two composite implementations, one that supports multiple UserGroupProviders and one that supports multiple UserGroupProviders and a single configurable UserGroupProvider. +Another option for the UserGroupProvider are composite implementations. This means that multiple sources/implementations can be configured and composed. For instance, an admin can configure users/groups to be loaded from a file and a directory server. There are two composite implementations, one that supports multiple UserGroupProviders and one that supports multiple UserGroupProviders and a single configurable UserGroupProvider. -The CompositeUserGroupProvider will provide support for retrieving users and groups from multiple sources. +The CompositeUserGroupProvider will provide support for retrieving users and groups from multiple sources. The CompositeUserGroupProvider has the following properties: * User Group Provider - The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3" -The CompositeConfigurableUserGroupProvider will provide support for retrieving users and groups from multiple sources. Additionally, a single configurable user group provider is required. Users from the configurable user group provider are configurable, however users loaded from one of the User Group Provider [unique key] will not be. +The CompositeConfigurableUserGroupProvider will provide support for retrieving users and groups from multiple sources. Additionally, a single configurable user group provider is required. Users from the configurable user group provider are configurable, however users loaded from one of the User Group Provider [unique key] will not be. The CompositeConfigurableUserGroupProvider has the following properties: * Configurable User Group Provider - A configurable user group provider. * User Group Provider - The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3" @@ -632,6 +634,85 @@ Here is an example loading users and groups from LDAP but still using file based The 'Initial Admin Identity' value would have loaded from the cn from John Smith's entry based on the 'User Identity Attribute' value. +Here is an example composite implementation loading users from LDAP and a local file. The users from LDAP will be read only while the users loaded from the file will be configurable in UI. + +---- + + + file-user-group-provider + org.apache.nifi.authorization.FileUserGroupProvider + ./conf/users.xml + + + cn=nifi-node1,ou=servers,dc=example,dc=com + cn=nifi-node2,ou=servers,dc=example,dc=com + + + ldap-user-group-provider + org.apache.nifi.ldap.tenants.LdapUserGroupProvider + ANONYMOUS + + + + + + + + + + + + + + + FOLLOW + 10 secs + 10 secs + + ldap://localhost:10389 + + 30 mins + + ou=users,o=nifi + person + ONE_LEVEL + + cn + + + ou=groups,o=nifi + groupOfNames + ONE_LEVEL + + cn + member + + + composite-user-group-provider + org.apache.nifi.authorization.CompositeConfigurableUserGroupProvider + file-user-group-provider + ldap-user-group-provider + + + file-access-policy-provider + org.apache.nifi.authorization.FileAccessPolicyProvider + composite-user-group-provider + ./conf/authorizations.xml + John Smith + + + cn=nifi-node1,ou=servers,dc=example,dc=com + cn=nifi-node2,ou=servers,dc=example,dc=com + + + managed-authorizer + org.apache.nifi.authorization.StandardManagedAuthorizer + file-access-policy-provider + + +---- + +In this example, the users and groups are loaded from LDAP but the servers are managed in a local file. The 'Initial Admin Identity' value came from an attribute in a LDAP entry based on the 'User Identity Attribute'. The 'Node Identity' values are established in the local file using the 'Initial User Identity' properties. [[legacy-authorized-users]] Legacy Authorized Users (NiFi Instance Upgrade)