Fusion uses security realms to authenticate users of the Fusion UI. Each user has an assigned security realm, which the user must choose when logging in. Choosing a different realm results in an authentication failure.
A security realm also provides a list of roles:
The list always includes the role(s) that are specified in the security realm.
(Optional) The security realm can reference one or more Fusion roles and/or get groups to which the user belongs from an external directory service that is the authentication provider. Fusion maps the group names to role names and adds these roles to the user’s list of roles.
Note: Fusion doesn’t use permissions from the LDAP for authorization of UI access or API requests. Fusion only obtains group names from the LDAP (optionally), which you can configure the security realm to map to role names.
Requests to the Fusion REST API must specify a security realm for per-request authentication, unless a session cookie is used (which contains information about the security realm).
Fusion authorizes requested operations based on API permissions specified for the user and for the user’s role(s). Fusion considers the role(s) specified in the user definition and in the security realm. Fusion creates a list of roles when a session is created, that is, when a user logs in or when the Sessions REST API creates a session. Authorization based on permissions is at request time.
You can define multiple security realms for a Fusion instance. This lets you give different sets of users different levels of access to specific Fusion collections.
Security Realm Types
When you create a security realm, you can choose among the following security realm types:
Fusion has a single preconfigured security realm named native. The admin user is in the native realm. and is the default realm. The native realm also provides a fallback mechanism in case of LDAP server or communication failure.
This realm is required to bootstrap Fusion. Because all requests to Fusion require authentication and authorization, on initial startup you must access the Fusion UI to set the admin password. After Fusion has a valid admin password, it creates the admin account in the Fusion native realm.
For the native realm, Fusion manages all authentication and permissions information directly.
You can create Fusion user accounts and manage them using either the Fusion UI or the User API.
Stored passwords are encrypted using bcrypt, the strongest possible encryption algorithm available to all JDKs.
In the case where a host domain uses Kerberos for authentication and LDAP for authorization, Fusion can be configured to do the same, by configuring a realm of type "LDAP" and then specifying Kerberos as the authentication mechanism.
Fusion stores a local user record in ZooKeeper and a mapping to the Kerberos principal.
SPNEGO is used for authentication via Kerberos.
You can use an LDAP as an authentication provider for Fusion. If the LDAP contains groups that make sense regarding partitioning Fusion functionality for Fusion users (that is, giving Fusion users different UI and API permissions based on the LDAP-group memberships of LDAP users), then you can configure an LDAP security realm to search for LDAP groups and to map the LDAP groups to Fusion roles.
Fusion stores a local user record in ZooKeeper, and authentication is performed by the LDAP server. User accounts can be managed by Fusion, or created automatically, in which case the Fusion user ID maps directly to the LDAP Distinguished Name (DN). Fusion permissions can be assigned automatically based on LDAP group membership.
Manage Security Realms
Only Fusion users with admin privileges can manage security realms. There are two ways to manage security realms:
Navigate to Applications > Access Control > Security Realms.
http://localhost:8764/api/realm-configs/ endpoint to manage security realms. See the
reference for details. In production environments, use port 8765.