This chapter describes the basic steps to administer security in MarkLogic Server. It does not provide the detailed procedures for creating users, roles, privileges, and so on. For those procedures, see the 'Security Administration' chapter of the Administrator's Guide. This chapter includes the following sections:
Authentication in MarkLogic Server occurs via the security database. The security database contains security objects such as privileges, roles, and users. A security database is associated with each HTTP, WebDAV, ODBC, or XDBC server. Typically, a single security database services all of the servers configured in a system. Actions against the server are authorized based on the security database. The security database works the same way for clustered systems as it does for single-node systems; there is always a single security database associated with each HTTP, WebDAV, ODBC, or XDBC server.
The configuration that associates the security database with the database and servers is at the database level. HTTP, WebDAV, ODBC, and XDBC servers each access a single documents database, and each database in turn accesses a single security database. Multiple documents databases can access the same security database. The following figure shows many servers accessing some shared and some different documents databases, but all accessing the same security database.
Sharing the security database across multiple servers provides a common security configuration. You can set up different privileges for different databases if that makes sense, but they are all stored in a common security database. For an example of this type of configuration, see Example: Using the Security Database in Different Servers.
In addition to storing users, roles, and privileges that you create, the security database also stores pre-defined privileges and pre-defined roles. These objects control access to privileged activities in MarkLogic Server. Examples of privileged activities include loading data and accessing URIs. The security database is initialized during the installation process. For a list of all of the pre-defined privileges and roles, see the corresponding appendixes in the Administrator's Guide.
When you configure a database, you must specify which database is its security database. You can associate the security database to another database in the database configuration screen of the Admin Interface. This configuration specifies which database the server will use to authenticate users and authorize requests. By default, the security database is named Security. The following screen shot shows the server configuration screen drop-list that specifies the security database.
There are two mechanisms available to add, change, delete, and use objects in the security database: the Admin Interface and the XQuery functions. provided by the
security.xqy library module. This section describes what you can do with each of these mechanisms and includes the following topics:
The Admin Interface is an application installed with MarkLogic Server for administering databases, servers, clusters, and security objects. The Admin Interface is designed to manage the objects in the security database, although it manages other things, such as configuration information, too. You use the Admin Interface to create, change, or delete objects in the security database. Activities such as creating users, creating roles, assigning privileges to roles, and so on, are all done in the Admin Interface. By default, the Admin Interface application runs on port 8001.
For the procedures for creating, deleting, and modifying security objects, see the Administrator's Guide.
The installation process installs an XQuery library to help you use security objects in your XQuery code. The
security.xqy library module includes functions to access user and privilege information, as well as functions to create, modify, and delete objects in the security database.
The functions in
security.xqy must be executed against the security database. You can use these functions to do a wide variety of things. For example, you can write code to test which collections a user has access to, and use that information in your code.
For the signatures and descriptions of the functions in
security.xqy, see the MarkLogic XQuery and XSLT Function Reference.
The security database is the central entry point to all of your MarkLogic Server applications. If the security database becomes unavailable, no users can access any applications. Therefore, it is important to create a backup of the security database. Use the database backup utility in the Admin Interface to back up the security database. For details, see the 'Backing Up and Restoring a Database' chapter of the Administrator's Guide.
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--
DocumentsB share a single security database,
Security is the default security database managed by the Admin Interface on port 8001. There are two HTTP servers,
ApplicationB, connected to
With this configuration, users who are assigned
RoleA can access documents in
DocumentsA and users of
RoleB can access documents in
DocumentsB. Assuming that
ExecutePrivilegeB are appropriately configured as login privileges on every HTTP and XDBC server that accesses either
DocumentsB, user access to these databases can conveniently be managed by assigning users the role(s)
RoleB as required.
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
DocumentsB. Leave the security database for the document databases as
Security(the default setting).
ExecutePrivilegeB. They represent the privilege to access
ApplicationBare two HTTP servers that are created later in this procedure.
DocumentsAas the database.
ApplicationAis now attached to
DocumentsAwhich in turn uses
Securityas its security database.
ExecutePrivilegeAin the privilege drop down menu. This indicates that
ExecutePrivilegeAis required to access
RoleBin the roles section.
UserA1 is granted
ExecutePrivilegeA by virtue of its role (
RoleA) and has login access to
ApplicationA is connected to
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
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