- Native, which uses Managed Fusion itself to manage users and passwords.
- LDAP, which uses an LDAP server as the source of truth for usernames and passwords.
- Kerberos, where Managed Fusion can be configured to use Kerberos for authentication.
- SAML, which uses the SAML 2.0 protocol to provide single sign-on.
- SSO Trusted HTTP, which can be configured to return a list of group names, and then map the groups to Managed Fusion roles in the security realm definition.
- JSON Web Token (JWT), where you can configure Managed Fusion to use a shared secret key to encrypt the JWT payload.
- OpenID Connect, which is an identity authorization layer that supplements the OAuth 2.0 protocol.
See Security Realms for more information about each realm type.
Create, Update, Delete or List Realms
The path for this request is:/api/realm-configs/<id>
where <id>
is the ID of a realm. The ID is optional for a GET request and omitted from a POST request.
A GET request returns the configured realms. If ID is omitted, all realms will be returned.
A POST request creates a new realm. If the request is successful, a new ID will be generated.
A PUT request updates a realm.
A DELETE request removes the realm.
Input
Parameter | Description |
---|---|
name Required | The name of the realm. This name will appear on the login screen of the UI, and will appear in user records to identify the realm they belong to. |
realmType Required | String value for realm type. |
enabled Required | If true, the realm is available for users to use with system authentication. |
ephemeralUsers | Prevents ephemeral users from being created in ZooKeeper during login. Enabling this property negates config.autoCreateUsers . |
config.autoCreateUsers | Enables/disables the auto-creation of Managed Fusion user accounts after users successfully authenticate for the first time. |
roleNames | Indicates which roles are dynamically applied to users in the realm. |
Additional Properties per Realm Type
Each realm type requires additional properties for configuration, which should be specified within theconfig
object field.
See the following documentation for each realm type:
- Native. Native is a preconfigured security realm and Fusion manages all authentication and permissions information directly.
- LDAP. Configure Managed Fusion for LDAP
- Kerberos. Configure Managed Fusion for Kerberos in Unix, Configure Managed Fusion for Kerberos in Windows
- SAML. Configure Managed Fusion for SAML
- SSO Trusted HTTP. Configure Managed Fusion for SSO
- JWT. Configure Fusion for JWT
- OpenID Connect. Configure OpenID Connect authentication
Configure Managed Fusion for LDAP
Configure Managed Fusion for LDAP
You can create security realms that use external LDAP servers for authentication. Optionally, Managed Fusion can search in the LDAP for groups to which a user belongs, and then map those groups to roles. Managed Fusion performs authorization using permissions stored in Managed Fusion users and roles.To configure Managed Fusion to use an external LDAP as an authentication provider, you’ll need to get information about the LDAP server(s) running on your system, either from your system or your sysadmin.







The person entry in this tree has the DN: “uid=babs, ou=people, dc=example, dc=com”.Attribute names include many short strings based on English words and abbreviations, e.g.:
LDAP entry attributes can refer to other LDAP entries by using the DN of the entry as value of that attribute. The following example of a directory which contains user and groups information shows how this works:
This tree contains two organizational units: “ou=people” and “ou=groups”. The children of the “group” organizational unit are specific named groups, just as the child nodes of organization unit “people” are specific users. There are three user entries with RDNs “uid=bob”, “uid=alice”, “uid=bill” and two groups with RDNs “cn=user” and “cn=admin”. The dotted lines and group labels around the person nodes indicate group membership. This relationship is declared on the groups nodes by adding an attribute named “member” whose value is a users DN. In the LDAP data interchange format (LDIF), this is written:See the Wikipedia’s LDAP entry for details.
Managed Fusion does not use permissions from the LDAP for authorization of UI access or API requests. It only obtains group names (optionally), which 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.
Add an LDAP Security Realm
- Log in to the Managed Fusion UI as the user admin, or as a different user with corresponding permissions.
- Navigate to System > Access Control.
- Click Security Realms.
-
Click Add Security Realm.
-
Specify info for the new realm:
-
name
– Name of the security realm. It must be unique. It should be descriptive but short. -
type
– Select ldap from the pulldown menu. When you select ldap, Managed Fusion displays additional, LDAP-specific configuration options. -
enabled
checkbox – Whether Managed Fusion allows user logins for this security realm. The default is yes (checked). -
auto-create users
checkbox – Whether a user account is created automatically upon initial authentication. The default is yes (checked). If the checkbox is unchecked, then a Managed Fusion user with admin permissions must create Managed Fusion users.
-
- Scroll down and specify additional options as explained in detail below.
Specify Static Roles (Optional)
Specify one or more Managed Fusion roles for the security realm. These roles are always considered. They do not depend on searching for LDAP groups and mapping group names to Fusion role names.In a security realm, you can specify these static roles, add to the list of roles dynamically through an LDAP search, or both. If you do neither, Managed Fusion uses only the role(s) and permissions defined for the user.
Specify LDAP Connection Details
Specify the hostname and port of the LDAP server. Check the checkbox if the server is running over SSL.
Specify the Authentication Method
Specify the authentication method:- Bind. LDAP authentication is carried out via a single “Bind” operation. See Bind below.
- Search. LDAP authentication is carried out indirectly via a Search operation followed by a Bind operation. See Search below.
- Kerberos. Kerberos authenticates Managed Fusion and an LDAP Search operation is carried out to find group-level authorizations. See Kerberos below.
Bind
Use the Bind authentication method when the Managed Fusion login username matches a part of the LDAP distinguished name (DN). Specify the remainder of the LDAP DN in the “DN Template” configuration entry, which uses a single pair of curly braces ({}
) as a placeholder for the value of the Managed Fusion username.
Search
Use the Search authentication method when the username used for Managed Fusion login doesn’t match a part of the LDAP DN. The search request returns a valid user DN, which is then used together with the user password for authentication via a Bind request.-
Construct a search request.
The Search authentication method is generally required when working with Microsoft Active Directory servers. In this case, you need to know the username and password of some user who has sufficient privileges to query the LDAP server for user and group memberships; this user doesn’t have to be the superuser.
In addition to a privileged user DN and password, the Search authentication method requires constructing a search request. There are two parts to the request. The first part is the base DN of the LDAP directory tree that contains user account objects. The second part of the request is a Search Filter object that restricts the results to a matching subset of the information.
-
Provide the administrator bind DN:
Kerberos
Use the Kerberos authentication method when Kerberos is the authentication provider.
Search for LDAP Groups (Optional)
A Managed Fusion role is a bundle of permissions tailored to the access needs of different kinds of users. Access to services and data for LDAP-managed users is controlled by mappings from LDAP users and groups to Managed Fusion roles.Roles can be assigned globally or restricted to specific LDAP groups. The security realm configuration panel contains a list of all Managed Fusion roles with a checkbox for each, used to assign that role to all users in that realm. LDAP group names can be mapped directly to specific Managed Fusion roles and LDAP group search and filter queries can also be used to map kinds of LDAP users to specific Managed Fusion roles.
Map LDAP Groups to Managed Fusion Roles (Optional)
If LDAP group names returned by the search for groups match Managed Fusion role names, you do not need to map the group names to role names. You must map any LDAP group names that do not match to Managed Fusion role names (if you do not, they will not be used).
Save the Security Realm Configuration
Click Save.Managed Fusion reports whether or not authentication was successful:
Basic LDAP Concepts and Terminology
The LDAP protocol is used to share information about users, systems, networks, and services between servers on the internet. LDAP servers are used as a central store for usernames, passwords, and user and group permissions. Applications and services use the LDAP protocol to send user login and password information to the LDAP server. The server performs name lookup and password validation. LDAP servers also store Access Control Lists (ACLs) for file and directory objects which specify the users and groups and kinds of access allowed for those objects.LDAP is an open standard protocol and there are many commercial and open source LDAP servers available. Microsoft environments generally use Active Directory. Unix servers use AD or other LDAP systems such as OpenLDAP, although many Unix systems do not use LDAP at all. To configure Managed Fusion for LDAP, you’ll need to get information about the LDAP server(s) running on your system either from your sysadmin or via system utilities.Directories and Distinguished Names
An LDAP information store is a Directory Information Tree (DIT). The tree is composed of entry nodes; each node has a single parent and zero or more child nodes. Every node must have at least one attribute which uniquely distinguishes it from its siblings which is used as the node’s Relative Distinguished Name (RDN). A node’s Distinguished Name (DN) is a globally unique identifier.The string representation of a DN is specified in RFC 4514. It consists of the node’s RDN followed by a comma, followed by the parent node’s DN. The string representation of the RDN is the attribute-value pair name, connected by an equals (”=”) sign. This recursive definition means that the DN of a node is composed by working from the node back through its parent and ancestor nodes up to the root node.Here is a small example of a DIT:
Name | Description |
---|---|
cn | commonName |
dc | domainComponent |
email address | |
ou | organizationalUnitName |
sn | surname |
uid | userId |

LDAP Protocol Operations
For authentication purposes, Managed Fusion sends Bind operation requests to the LDAP server. The Bind operation authenticates clients (and the users or applications behind them) to the directory server, establishes authorization identity used for subsequent operations on that connection, and specifies the LDAP protocol version that the client will use.Depending on the way that the host system uses LDAP to store login information about users and groups, it may be necessary to send Search operation requests to the LDAP server as well. The Search operation retrieves partial or complete copies of entries matching a given set of criteria.LDAP filters specify which entries should be returned. These are specified using prefix notation. Boolean operators are ”&” for logical AND, ”|” for logical OR, e.g., “A AND B” is written ”(&(A)(B))”. To tune and test search filters for a Unix-based LDAP system, see the ldapsearch command line utility documentation. For Active Directory systems, see AD Syntax Filters.Configure Managed Fusion for Kerberos in Unix
Configure Managed Fusion for Kerberos in Unix
To configure the Managed Fusion UI service to use Kerberos for user authentication, you must create a Kerberos security realm.Kerberos is a system that provides authenticated access for users and services on a network.
Instead of sending passwords in plaintext over the network, encrypted passwords are used to generate time-sensitive tickets that are used for authentication. SPNEGO provides a mechanism for extending Kerberos to Web applications through the standard HTTP protocol.Kerberos uses symmetric-key cryptography and a trusted third party called a Key Distribution Center (KDC) to authenticate users to a suite of network services. (By users we mean both end users and client programs).
The computers managed by that KDC and any secondary KDCs constitute a realm. When a user authenticates to the KDC, the KDC sends a set of credentials (a ticket) specific to that session back to the user’s machine.
Kerberos-aware services use the ticket on the user’s machine for authentication instead of requiring sign-on with a password. Because tickets are used rather than passwords, this provides the convenience of Single Sign-On (SSO) in addition to security.A Kerberized process is one that has been configured so it can get tickets from a KDC and negotiate with Kerberos-aware services. When a user sends an HTTP request, Managed Fusion tries to authenticate using the Kerberos/SPNEGO protocol.
If the request was sent from a browser, Managed Fusion does not display the initial sign-on panel; instead on login, the user sees the main Managed Fusion collections panel.To Kerberize Managed Fusion, you must:The second entry is For example, for realm LUCIDWORKS.IO, the krb5.conf file is just like the above example, except that instead of “myorg.org” we specify “lucidworks.io”.The Output should be in this form, but with your data:The -k argument specifies the name of the keytab file which will be created or updated. The command “add” takes the following argument flags:Use the keytab to login as the service principal, without being prompted for a password:Examine your credentials via the command Logout again with Configuring Web Browsers and
The To run Chrome on a Mac:To run Chrome on Windows:For more information, see Using a Web Browser to Access an URL Protected by Kerberos HTTP SPNEGO and Authentication + Authorization.To get around this, the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File will need to be downloaded and installed. It can be downloaded here:Place the jars in your JAVA_HOME/jre/lib/security/ directory, then restart Managed Fusion.Clicking on the “logout” icon on the top nav bar (rightmost icon or a padlock) takes you back to the main Managed Fusion panel. If you destroy your Kerberos credentials cache via the “kdestroy” command, the next time you logout of Managed Fusion, you will be logged out and the browser will display the Managed Fusion login panel.
Kerberos support requires Managed Fusion 5.9.5.
This article focuses on configuring Managed Fusion for Kerberos in Unix.
- Configure the Kerberos client on the server that the Managed Fusion UI service will be running on so that it can talk to the KDC (section Configuring the Kerberos client below).
- Configure the security realm of the Managed Fusion UI (section Configuring Managed Fusion Authentication for Kerberos Realm below).
- Depending on the encryption used by the KDC, you may also need to install additional Java security libraries into the Managed Fusion distribution. These are freely available from Oracle, see download and installation instructions below.
- Kerberos realm name. In most cases, this is your domain name in upper case.
- KDC name. This is usually a combination of
kerberos.
and your domain name. For example,kerberos.example.com
- Kerberos principal name and password. A principal is a unique identity to which Kerberos can assign tickets. When the entity is a client program, this is called the Service Principal name.
- A keytab file. This holds the encrypted credentials.
kinit
. Obtain and cache a ticket from the KDC (domain login)kdestroy
. Destroys credentials (domain logout)klist
. Lists cached credentialsktutil
. Create or add credentials to a keytab file
Configuring the Kerberos client
Step 1: Edit the Kerberos configuration file.
To configure your local Kerberos client so that it can talk to the Kerberized server, you must edit Kerberos configuration file namedkrb5.conf
.
On most Unix systems, this file is located at /etc/krb5.conf
.This file contains Kerberos configuration information, including the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms.If your organization realm name is “MYORG.ORG”, and your KDC server is named “kerberos.myorg.org”, then you edit two entries.
The first entry is libdefaults
. Set MYORG.ORG as the default realm:realms
. Add MYORG.ORG as a realm:Step 2: Authenticate to Kerberos
The commandkinit
is the Kerberos authentication command.
To get started, you authenticate to Kerberos using the Kerberos principal name and password (which you may need to obtain from your sysadmin).
For this example, the principal name is “prince.”kinit
command prompts for a password. Successful authentication is silent. Unsuccessful authentication results in an error message.The command klist
shows all cached Kerberos credentials. To check that you have successfully authenticated, run this command:The Service Principal Keytab file
The usual scenario in an enterprise organization is to have a Kerberos admin create a service principal with a random key password. Then, the admin generates a keytab, which is then used for Managed Fusion service principal authentication. If you are your own Kerberos admin, then you will need to create this file for yourself.Step 3. Create a Keytab file
The commandktutil
creates the service principal keytab file
which holds the encrypted credentials that the Managed Fusion UI Proxy will use for Kerberos authentication.
In order to generate the keytab file, you must have a set of cached credentials, therefore, first run the kinit
command (step 2).From the command line, run the command ktutil
.
You must enter your password twice.- “-p” : service principal, format <service>/<fully.qualified.domain>@REALM
-
“-e” : encryption type. Depending on the encryption type, you may need to download additional Java security libraries for strong encryption.
The following encryption types are not supported by Fusion: * DES-CBC-CRC * DES_CBC_MD5 * Microsoft Windows 2000 RC4-HMAC
- “-V” : key version number (kvno). Key version numbers are used in the Kerberos V5 protocol to distinguish between different keys in the same domain.
Step 4. Test the Keytab file
The location of this keytab file will be used to configure UI Proxy configuration. Before configuring the Managed Fusion UI Proxy, you should check that the keytab file is valid. Testing the keytab requires the following sequence of steps:- Clear any existing credentials via command
kdestroy
. - Log in using the keytab as an argument to the command
kinit -kt <keytab file> <principal>
, where<principal>
is the name of a principal within the keytab file. - Examine your credentials via command
klist
. - Clear credentials via command
kdestroy
, which removes any existing credentials, effectively logging you out of Kerberos.
kdestroy
command. This command succeeds silently.
To check that credentials have been removed, re-run the klist command:klist
. The output should be similar to this:kdestroy
.Configuring Managed Fusion Authentication for Kerberos Realm
Once you have tested both the user and service principal logins, you must create the service principal realm-config in the Managed Fusion Authentication Proxy. This allows the Proxy to authenticate to Kerberos as the service principal, without a password.Step 5. Configure the Managed Fusion Realm
Managed Fusion security realms can be configured either via the Managed Fusion UI Admin tool or the Managed Fusion REST API. The advantage of using the Managed Fusion UI Admin Tool is that a single panel’s worth of configuration requires a series of calls to the REST API. It is important to understand the set of configuration properties collected by the Managed Fusion UI and how they are used by the REST API.A security realm for Kerberos has the following properties:- name : unique string identifier
- realmType : “kerberos”
- enabled : whether or not the realm is available for users to use with system authentication
- config : this property is required for the realm type “kerberos”. It takes two key-value pairs:
- principal : the principal service name
- keytab : this must be the full path to the keytab file.
- Log in to Managed Fusion as “admin” or as a user who has super-admin privileges.
- In the left-hand side navigation bar, click System > Access control.
- Click the Security Realms tab, then Add Security Realm.
- On the New Security Realm form, choose type “kerberos” from the pulldown menu so that there are input boxes for the Kerberos realm properties “Service Principal” and “Keytab path”.
- Choose a realm name, and make sure the “enabled” box is checked.
- If the auto-created box is unchecked, a user with admin privileges needs to create Managed Fusion user accounts.
-
Select default roles. The default roles are assigned to a user the first time they access Managed Fusion via this realm, using the Kerberos/SPNEGO protocol. For example, once you have defined a Kerberos realm “my-kerberos-realm” for domain “MYORG.ORG”, when user “any.user” in domain “MYORG.ORG” authenticates to Managed Fusion for the first time via this realm, they are added to the set of Managed Fusion users as username “any.user@MYORG.ORG” and they have all default roles.
It is prudent to allow the minimum set of default roles, as all users will have these permissions. Some users require admin privileges and a few users require super-admin privileges. There should always be a user with super-admin privileges that can authenticate to Managed Fusion using the native security realm and can then grant permissions to individual users as needed.
The Managed Fusion proxy Kerberos realm works only with one Managed Fusion host. For a multi-node Managed Fusion cluster where each node resides on a different host, configure a separate realm for each host with a dedicated service/principal.
- Enter the service principal and the full path to the keytab file.
- Click Save. Managed Fusion displays a confirmation message.
Kerberos/SPNEGO HTTP Authentication
SPNEGO provides a mechanism for extending Kerberos to applications that use the HTTP protocol including web browsers and thecurl
command-line utility.Step 6. Configure the HTTP client
When a user sends a request to the Kerberized Managed Fusion UI, a SPNEGO request (http[s]) is made. If the user is not already authenticated, the Managed Fusion authentication proxy yields a 401 status code and a Negotiate header. This status/header response triggers compatible clients to fetch a local ticket from their Kerberos “ticket tray.” This ticket is then encoded and sent back to the Managed Fusion. The Managed Fusion authentication proxy will then decode the ticket, and perform a SPN.doAs(user) authentication request to the KDC/Authentication Service. Depending on the results, the proxy then successfully executes the original request (along with a session cookie) or a 401 (without the Negotiate). Clients can either choose to use the session cookie or continue authenticating on every request.Configuring Web Browsers and curl
for SPNEGO
The --negotiate
option enables SPNEGO in curl
.IE and Safari require no additional configuration to use SPNEGO.To configure Firefox, access the low level configuration page by loading the about:config page. Then go to the network.negotiate-auth.trusted-uris preference and add the hostname or the domain of the web server that is HTTP Kerberos SPNEGO protected (if using multiple domains and hostname use comma to separate them).The Chrome browser must be launched from the command line with several added parameters.To run Chrome on linux:Session cookies
A successful Kerberos/SPNEGO login will yield a session cookie, this cookie is identical to the cookie yielded by the Managed Fusion authentication proxy’s current POST-login-mechanism.The expiration policy on the cookie is currently fixed at 8 hours. But has a 1 hour “idle” max, which means if you do not make a request for 1 hour, the cookie is invalidated. Otherwise the lifetime is pushed ahead until the 8 hour max is met.The name of the cookie is “id” and the value is a UUID. This UUID is a key that maps to an in-memory value containing the real user ID.Testing and Troubleshooting
Once you have configured the Kerberos security realm, you can test it by logging out of Managed Fusion and shutting down the browser.Check that you have a valid Kerberos authentication ticket via the klist command.Now open a new browser session and access the Managed Fusion installation, <domain>:<UI port>.This should take you directly to the main Managed Fusion panel, bypassing the Managed Fusion “Welcome” login panel. To view your login profile, click on the profile icon at the top right. Your user name should be your login name + ”@” + your domain name.If instead, you see the Managed Fusion login panel, your browser is not configured for SPNEGO.If the Managed Fusion display consists only of an empty top nav bar, this indicates an authentication failure. Check that the path to your keytab file is correct. Then check the Managed Fusion logs.If your KDC uses “AES256 CTS mode with HMAC SHA1-96” for key encryption, the proxy will log this error when attempting to authenticate:References and Tutorials
- https://en.wikipedia.org/wiki/Kerberos_%28protocol%29
- http://www.roguelynn.com/words/explain-like-im-5-kerberos/
- https://en.wikipedia.org/wiki/SPNEGO
- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Using_Kerberos.html#about-kerberos
- http://www.oracle.com/technetwork/articles/idm/weblogic-sso-kerberos-1619890.html - section “Install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files”
- http://www.cisco.com/c/en/us/support/docs/security-vpn/kerberos/16087-1.html
Configure Managed Fusion for Kerberos in Windows
Configure Managed Fusion for Kerberos in Windows
To configure the Fusion UI service to use Kerberos for user authentication, you must create a Kerberos security realm.Kerberos is a system that provides authenticated access for users and services on a network.
Instead of sending passwords in plaintext over the network, encrypted passwords are used to generate time-sensitive tickets that are used for authentication. SPNEGO provides a mechanism for extending Kerberos to Web applications through the standard HTTP protocol.Kerberos uses symmetric-key cryptography and a trusted third party called a Key Distribution Center (KDC) to authenticate users to a suite of network services. (By users we mean both end users and client programs).
The computers managed by that KDC and any secondary KDCs constitute a realm. When a user authenticates to the KDC, the KDC sends a set of credentials (a ticket) specific to that session back to the user’s machine.
Kerberos-aware services use the ticket on the user’s machine for authentication instead of requiring sign-on with a password. Because tickets are used rather than passwords, this provides the convenience of Single Sign-On (SSO) in addition to security.A Kerberized process is one that has been configured so it can get tickets from a KDC and negotiate with Kerberos-aware services. When a user sends an HTTP request, Fusion tries to authenticate using the Kerberos/SPNEGO protocol.
If the request was sent from a browser, Fusion does not display the initial sign-on panel; instead on login, the user sees the main Fusion collections panel.
These instructions use the following user name throughout this example:
Establish the desired delegation rules for the new user in the “Delegation” tab.
The output will be similar to:This process will create the Log into Fusion as a native admin and navigate to System > Access Control > Security Realms > New Realm. Use the following parameters:
You can specify the default rule, which should work for most situations:You can also add custom rules. See Mapping Kerberos Principals to Short Names for more information on creating custom rules.Save your new realm before continuing. You should now be able to test with Negotiate authentication.Linux users may also need to run a Navigate your web browser to Adjust your Kerberos name mapping rules to resolve this issue.
Kerberos support requires Fusion 5.9.5.
Kerberos support requires Managed Fusion 5.9.5.
This article focuses on configuring Managed Fusion for Kerberos in Windows.
Set up and Configure the Active Directory Domain Service
Install the Active Directory Domain Service
To begin, follow Microsoft’s instructions on how to install Active Directory Domain Services.This topic uses the following domain throughout this example:NETBIOS Domain | FUSIONIS |
Fully qualified domain name | fusionis.life |
Create a New User
Launch the Server Manager. Navigate to Tools > Active Directory Users and Computers. Within thefusionis.life
server, locate the “Users” folder, right-click on the folder and select New > User.When creating a user for this purpose, ensure the
First name
and Display name
fields both hold the exact same value.User name | Notes |
---|---|
Distinguished name (DN) |
|
User Principal Name (UPN) | kerberos500@fusionis.life |
NETBIOS Domain\samAccountName | FUSIONIS\kerberos500 |

Create a Keytab for the New User
Enter the following command into the command prompt to create a keytab for the user you just created:The following weak encryption types are not supported by Fusion:
- DES-CBC-CRC * DES_CBC_MD5
- Microsoft Windows 2000 RC4-HMAC
kerberos500.keytab
file required to set up the Kerberos realm in Fusion. The command will also set the service principal to HTTP/fusionis.life@FUSIONIS.LIFE
.If you see the following, the user was not created correctly:
DsCrackNames returned 0x2 in the name entry for kerberos500. Ktpass:failed getting target domain for specified user.
Delete the user, and repeat the steps above.Set up Kerberos on Managed Fusion
Set up the Kerberos Realm
Get the keytab file copied to the server.The keytab file must be installed on each Fusion node.
Type | Kerberos |
Keytab file | The path to the keytab file you saved on the server |
Service principal | The service principal you generated in the previous step |
Kerberos name mapping | The field that specifies the mapping from a Kerberos Principal name to a short name |
Verify Kerberos is Working
You will test to verify that Kerberos is working in the following sections. You must log into Windows as a user in the protected realm, meaning that the service principal name you are using has access to generate a ticket for your user.Verify with cURL
Windows users can log in as a user within the domain, launch the command prompt, and run the cURL command below:kinit
to login as a user prior to running.Navigate your web browser to http://fusionis.life:8764
. If you are automatically logged in, Kerberos is working.Verify with Google Chrome
To verify Kerberos is working with Google Chrome, run Chrome with the following command parameters:http://fusionis.life:8764
. If you are automatically logged in, Kerberos is working.Verify with Firefox
To verify Kerberos is working with Firefox, navigate toabout:config
in your browser’s URL bar. If a message appears stating “This might void your warranty!”, click “I accept the risk!”.Search for the string network.negotiate-auth.trusted-uris
, double-click the field, and enter fusionis.life
into the field that appears. Click “Ok”.Navigate your web browser to http://fusionis.life:8764
. If you are automatically logged in, Kerberos is working.Troubleshooting
Defective token detected
If you encounter this issue, check thevar/log/proxy/proxy.log
after attempting to make a request.See Stack Overflow for additional steps to resolve this issue.Kerberos Name mapping rules
You may see the following error if you did not specify a mapping rule and the Proxy could not figure out how to map the Kerberos Principal name to a short name:Configure Managed Fusion for SAML
Configure Managed Fusion for SAML
SAML 2.0 is a standard for exchanging authentication and authorization data between security domains.The SAML protocol allows web-browser single sign-on (SSO) through a sequence of messages sent to and from the browser, which is the intermediary between Managed Fusion and the SAML authority acting as the Identity Provider (IdP).To configure Managed Fusion to use SAML 2.0 for user authentication and authorization you must create a SAML security realm. In addition to configuring the Managed Fusion security realm, you must configure the SAML identity provider to recognize the Managed Fusion application.Once Managed Fusion is configured for a SAML realm, this realm is added to the list of available realms on the initial Managed Fusion sign-on panel. When the SAML realm is chosen from the list of available realms, the browser then redirects to the IdP which handles user authentication. Upon successful authentication, the IdP sends a response back to the browser which contains authentication and authorization information as well as the URL of the Managed Fusion application. The browser redirects back to the Managed Fusion URL, passing along the SAML message with the user authentication and authorization information. Managed Fusion then issues as session cookie which is used for subsequent user access.
Add a Security Realm
- Sign in to Managed Fusion and click your application.
- Click System > Access Control > Security Realms > Add Security Realm.
- In the Name field, enter a unique name for the security realm.
- Click Type and select saml.
-
In the additional configuration options, review the default values and determine if you want to change them:
- The default value for Enabled is true. This setting controls whether or not Managed Fusion allows user logins for this security realm.
- The default value for Ephemeral Users is false. When disabled, this setting prevents ephemeral users from being created in ZooKeeper during login. If enabled, this property negates Auto Create Users.
- The default value for Auto Create Users is true. If enabled, a user account is created automatically upon initial authentication. If disabled, a Managed Fusion user with admin permissions must create Managed Fusion users.
-
In the SAML Realm section, complete the following fields:
-
In the Identity Provider URL field, enter the URL used by the SAML authority for single sign-on. For example:
https://www.my-idp.com/<my-app-path>/sso/saml
.The URL format may differ depending on the SAML identity provider. -
In the IdP Issuer field, enter the URL for the SAML identity provider. The IdP Issuer must match the
<saml:Issuer>
in the SAML payload. For example:http://www.my-idp.com/exk686w2xi5KTuSXz0h7
. -
In the App Issuer field, enter the URL for the application source. This field is only required if there is an
audienceRestriction
in the SAML assertion, in which case, the field must match<saml:Audience>
in the SAML payload. - In the Certificate Fingerprint field, paste the contents of the SAML authority certificate without the certificate header and footer.
- In the User ID Attribute field, enter the username or identifier. By default, the Managed Fusion username is the same as the login name known to the Identity Provider. When another field or attribute in the user record stored by the IdP should be used as the Managed Fusion username, that attribute name is the value of the User ID Attribute.
- In the Post Login Redirect URL field, enter a URL to display after the user signs in. If not set, the Managed Fusion URL is used.
- In the Logout URL field, enter a URL that displays when the user signs out. This field is optional.
- In the Groups Mapping section, enter a value in Group Name Attribute and add group mappings.
-
In the Identity Provider URL field, enter the URL used by the SAML authority for single sign-on. For example:
- Click Save.
Configure SAML identity provider
To finish setup, register Managed Fusion with your SAML identity provider. The amount of information required to register varies depending on the SAML authority.Required information
Managed Fusion URL. This displays when the user successfully signs in. The information includes the:- Protocol
- Server
- Managed Fusion application port
- Path format of
api/saml
.
https://EXAMPLE_COMPANY.b.lucidworks.cloud:6764/api/saml
.If the Managed Fusion application is running behind a load-balancer, this URL is the load-balancer URL plus path api/saml
. The load-balancer must be session-sticky so the sequence of messages that comprise the SAML protocol successfully run to completion.Additional information
Some authorities may require additional information. In particular, the SAML 2.0AudienceRestriction
tag may be part of the SAML message. This tag specifies the domain where the SAML trust conditions are valid. This domain is usually where the Managed Fusion app is running. For example, https://EXAMPLE_COMPANY.b.lucidworks.cloud
.Example SAML Realm configuration
The Managed Fusion endpointapi/realm-configs
returns a JSON list of all the configuration objects for all realms. After configuring a SAML realm named "saml-test"
using the okta.com
developer preview tool, the configuration object for this realm is:References
Configure Managed Fusion for SSO
Configure Managed Fusion for SSO
The “SSO Trusted HTTP” realm type (Below is a sample configuration:
trusted-http
in the REST API) is useful in single sign-on (SSO) environments.If SSO is already set up in your environment, user identities and group information can be sent to Fusion through HTTP headers (REMOTE_USER, for example). The SSO Trusted HTTP realm type provides the configuration options for integrating this into Fusion’s authentication systems. It also supports allowing access to only a set of known client IPs, and mapping groups to Fusion roles.Use the Realms API to configure this realm type:identityKey | The name of an HTTP header. If this key is found in the request headers, its value is used as the identity of the client (username, for example). |
groups | Configuration keys for auth groups:
|
allowedIps | Allow access to only a set of known client IPs. When this property is defined and the client IP is not included in it, the realm logic return a 401. Leaving this field empty makes the realm nonoperational. To accept traffic from all destinations for development, you can use an IP such as 0.0.0.0/0. In production the concrete IP should be specified. |
Configure OpenID Connect authentication
Configure OpenID Connect authentication
OpenID Connect is an identity authorization layer which supplements the OAuth 2.0 protocol.Below is a sample configuration:
Configuration
Use the Realms API to configure this realm type:Required fields
Field | Description | Example |
---|---|---|
name | Name of the OIDC realm. | oidc |
clientSecret | A secret value shared between the application and the authentication server. | N/A |
redirectUri | The URI that displays after the user signs in. | https://EXAMPLE_COMPANY.b.lucidworks.cloud:6764/admin |
authorizationUri | The authorization server URI. | https://$\{yourOktaDomain}/oauth2/default/v1/authorize |
tokenUri | The URI where the access token is obtained. | https://$\{yourOktaDomain}/oauth2/default/v1/token |
clientId | A unique value which identifies the client. | N/A |
jwkSetUri | The URL of the authorization server’s JSON Web Key Set (JWKS). | https://$\{yourOktaDomain}/oauth2/default/v1/keys |
Google authentication
For authenticating with Google, use Google’s OpenID Configuration to retrieve the required values forauthorizationUri
, tokenUri
, jwkSetUri
, and issuer
.Okta authentication
OpenID Connect authentication with Okta involves mapping Okta groups to Managed Fusion roles. The Okta group information can be retrieved from Okta’s admin view:- Navigate to API > Authorization Server.
- Select the server to configure for mapping.
- In the Scope menu, add the authentication groups.
- In the Claims menu, add new claim groups with ID token and set regexp to
.*
, which exposes all groups.