Security realms
Managed Fusion uses security realms to authenticate users of the Managed 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 Managed Fusion roles and/or get groups to which the user belongs from an external directory service that is the authentication provider. Managed Fusion maps the group names to role names and adds these roles to the user’s list of roles.
| Managed Fusion does not use permissions from the LDAP to authorize UI access or API requests. It only obtains group names (optionally), which are used as role names or are mapped to role names. If an Active Directory Security Query Trimming Stage is used, then directory-service permissions are used for trimming. If a connector supports security trimming, then connector permissions are used for trimming. |
Requests to the Managed 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).
Managed Fusion authorizes requested operations based on API permissions specified for the user and for the user’s role(s). Managed Fusion considers the role(s) specified in the user definition and in the security realm. Managed 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 Managed Fusion instance. This lets you give different sets of users different levels of access to specific Managed Fusion collections.
| The directory service that you use to return group information must be the same one that is used for authentication. |
Security Realm Types
When you create a security realm, you can choose among the following security realm types:
OpenID Connect
OpenID Connect is an identity authorization layer which supplements the OAuth 2.0 protocol.
For more information, see Configure Managed Fusion for OpenID Connect.
Native
Managed Fusion has a single preconfigured security realm named native. The admin user is in the native realm. The native realm also provides a fallback mechanism in case of LDAP server or communication failure.
This realm is required to bootstrap Managed Fusion. Because all requests to Managed Fusion require authentication and authorization, on initial startup you must access the Managed Fusion UI to set the admin password. After Managed Fusion has a valid admin password, it creates the admin account in the Managed Fusion native realm.
For the native realm, Managed Fusion manages all authentication and permissions information directly.
You can create Managed Fusion user accounts and manage them using either the Managed Fusion UI or the User API.
Passwords are not stored, but are hashed using bcrypt.
SSO Trusted HTTP
The "SSO Trusted HTTP" realm type (trusted-http in the REST API) is useful in single sign-on (SSO) environments.
If the SSO environment contains groups that make sense regarding partitioning Managed Fusion functionality for Managed Fusion users (that is, giving Managed Fusion users different UI and API permissions based on the SSO groups), then you can configure an SSO Trusted HTTP security realm to return a list of group names, and then map the groups to Managed Fusion roles in the security realm definition.
JWT
The JSON Web Token (JWT) realm uses an “Authorization” header in the request to authenticate the user and the data inside the JWT token for the authorization. Lucidworks configures JWT for Managed Fusion clients.
Kerberos
In the case where a host domain uses Kerberos for authentication and LDAP for authorization, Managed Fusion can be configured to do the same, by configuring a realm of type "LDAP" and then specifying Kerberos as the authentication mechanism.
Managed Fusion stores a local user record in ZooKeeper and a mapping to the Kerberos principal.
SPNEGO is used for authentication via Kerberos.
LDAP
You can use LDAP as an authentication provider for Managed Fusion. If the LDAP contains groups that make sense regarding partitioning Managed Fusion functionality for Managed Fusion users (that is, giving Managed 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 Managed Fusion roles.
Managed Fusion stores a local user record in ZooKeeper, and authentication is performed by the LDAP server. User accounts can be managed by Managed Fusion, or created automatically, in which case the Managed Fusion user ID maps directly to the LDAP Distinguished Name (DN). Managed Fusion permissions can be assigned automatically based on LDAP group membership.
SAML
Managed Fusion stores a local user record in ZooKeeper and the URL and information about the SAML Identity Provider. The SAML 2.0 protocol is used to provide web browser single sign-on.
Manage Security Realms
Only Managed Fusion users with admin privileges can manage security realms. There are two ways to manage security realms:
Navigate to System > Access Control > Security Realms.
Use the http://EXAMPLE_COMPANY.lucidworks.cloud/api/realm-configs/ endpoint to manage security realms. See the
Realms API
reference for details.
Replace EXAMPLE_COMPANY with the name provided by your Lucidworks representative.
|