Skip to main content

Securing MarkLogic Server

Using Custom Login Pages

Digest and basic authentication use the browser’s username and password prompt to obtain user credentials. The server then authenticates the credentials against the security database. There is no good way to create a custom login page using digest and basic authentication. To create custom login pages, you need to use application-level authentication.

To configure MarkLogic Server to use a custom login page for an app server, perform the following steps using the Admin Interface:

  1. Go to the Configuration tab for the HTTP app server for which you want to create a custom login page.

  2. Scroll down to the authentication field and select application-level.

  3. Choose nobody as the default user. The nobody user is automatically created when MarkLogic Server is installed. It is created with the following roles: rest-reader, rest-extension-user, app-user, harmonized-reader and is given a password which is randomly generated.

  4. Create a custom login page that meets your needs. We refer to this page as login.xqy.

  5. Make login.xqy the default page displayed by the application server. Do not require any privilege to access login.xqy (that is, do not place xdmp:security-assert() in the beginning of the code for login.xqy. This makes login.xqy accessible by nobody, the default user specified above, until the actual user logs in with his credentials.

    The login.xqy page likely contains a snippet of code as shown below:

    ...return
if xdmp:login($username, $password) then
  ... protected page goes here...
else
  ... redirect to login page or display error page...

    The rest of this example assumes that all valid users can access all the pages and functions within the application.

    Note

    If you are using a modules database to store your code, the login.xqy file still needs to have an execute permission that allows the nobody (or whichever is the default) user to access the module. For example, you can put an execute permission paired with the app-user role on the login.xqy module document, and make sure the nobody user has the app-user role (which it does by default).

  6. Create a role called application-user-role.

  7. Create an execute privilege called application-privilege. Add this privilege to the application-user-role.

  8. Add the application-user-role to all users who are allowed to access the application.

  9. Add this snippet of code before the code that displays each of the pages in the application, except for login.xqy:

    try 
{
  xdmp:security-assert("application-privilege","execute")
}
catch($e)
{
  xdmp:redirect-response("login.xqy")
}

    or

    if(not(xdmp:has-privilege("application-privilege","execute")))
then
(
  xdmp:redirect-response("login.xqy")
)
else ()

This ensures that only a user who has the application-privilege by virtue of his role can access these protected pages.

Similar to the previous approach, this method of authentication requires the appropriate security configuration for users and documents. See Introduction to Security for background on the security model.

In this section: