Skip to main content

Securing MarkLogic Server

Example: Using the Security Database in Different Servers

The security database typically is used for the entire system, including all of the HTTP, WebDAV, ODBC, and XDBC servers configured. You can create distinct privileges to control access to each server. If each server accesses a different document database, these privileges can effectively control access to each database (because the database is associated with the server). Users must have the appropriate login privileges to log into the server, and therefore they have no way of accessing either the applications or the content stored in the database accessed through that server without possessing the appropriate privilege. This example describes such a scenario.

Consider an example with two databases—DocumentsA and DocumentsB:

Diagram illustrating different servers sharing the Security database

DocumentsA and DocumentsB share a single security database, Security. Security is the default security database managed by the Admin Interface on port 8001. There are two HTTP servers, ApplicationA and ApplicationB, connected to DocumentsA and DocumentsB respectively.

ExecutePrivilegeA controls login access to ApplicationA, and ExecutePrivilegeB to ApplicationB. RoleA is granted ExecutePrivilegeA and RoleB is granted ExecutePrivilegeB.

With this configuration, users who are assigned RoleA can access documents in DocumentsA and users of RoleB can access documents in DocumentsB. Assuming that ExecutePrivilegeA or ExecutePrivilegeB are appropriately configured as login privileges on every HTTP and XDBC server that accesses either DocumentsA or DocumentsB, user access to these databases can conveniently be managed by assigning users the role(s) RoleA and/or RoleB as required.

Note

The Admin Interface at port 8001 is also used to configure all databases, HTTP servers, hosts, and so on. The connection between the Admin Interface and the Security database in the diagram simply indicates that the Admin Interface is storing all security objects—users, roles, and privileges—in Security database.

The steps below outline the process to create the configuration in the above example.

  1. Create two document databases: DocumentsA and DocumentsB. Leave the security database for the document databases as Security (the default setting).

  2. Create two execute privileges: ExecutePrivilegeA and ExecutePrivilegeB. They represent the privilege to access ApplicationA and ApplicationB respectively. ApplicationA and ApplicationB are two HTTP servers that are created later in this procedure.

    Note

    The new execute privileges created using the Admin Interface are stored in the Security database. The new roles and users created below are also stored in the Security database.

  3. Create two new roles. These roles are used to organize users into groups and to facilitate granting access to users as a group.

    1. Create a new role. Name it RoleA.

    2. Scroll down to the Execute Privileges section and select ExecutePrivilegeA. This associates ExecutePrivilegeA with RoleA. Any user assigned RoleA is granted ExecutePrivilegeA.

    3. Repeat the steps for RoleB, selecting ExecutePrivilegeB instead.

  4. Create two new HTTP servers:

    1. Create a new HTTP server. Name it ApplicationA.

    2. Select DocumentsA as the database. ApplicationA is now attached to DocumentsA which in turn uses Security as its security database.

    3. Select basic, digest or digest-basic authentication scheme.

    4. Select ExecutePrivilegeA in the privilege drop down menu. This indicates that ExecutePrivilegeA is required to access ApplicationA.

    5. Repeat the steps for ApplicationB, selecting ExecutePrivilegeB instead.

  5. Create new users.

    1. Create a new user named UserA1.

    2. Scroll down to the Roles section and select RoleA.

    3. Repeat the steps for UserB1, selecting RoleB in the roles section.

    UserA1 is granted ExecutePrivilegeA by virtue of its role (RoleA) and has login access to ApplicationA. Because ApplicationA is connected to DocumentsA, UserA1 is able to access documents in DocumentsA assuming no additional security requirements are implemented in ApplicationA or added to documents in DocumentsA. The corresponding is true for UserB1.

The configuration process is now complete. Additional users can be created by simply repeating step 5 and selecting the appropriate role. All users assigned RoleA have login access to ApplicationA and all users assigned RoleB have login access to ApplicationB.

This approach can also be easily extended to handle additional discrete databases and user groups by creating additional document databases, roles and execute privileges as necessary.

In this section: