Storage area security

This topic describes how to create and configure the security on the shared directory location under which file storage areas and content cache areas will be created. See Content Storage for information about how to create and administer these storage locations in Enterprise Manager. See also "Create a File Storage Area" in the IBM FileNet P8 Platform Installation and Upgrade Guide.

General

FileNet P8 objects, including document objects, are stored in the object store's database. This is handled automatically when you successfully complete the Object Store wizard, and no additional set up is required. However, the files referenced by the content element property of a document object must be stored in one of the following content storage areas:

NOTE  Content cache areas are configured and secured exactly like file storage areas.

File storage area security

Content Engine operating system account

The Content Engine operating system user (referred to here as ce_os_user) who logs on to the Content Engine server and starts the local application server process is the account that must be used to secure the folders and files in a file storage area. From a practical standpoint, the account that is used to install the application server should be the same account that is used to start the application server process. As an administrator, you will always log on using the same OS account to secure the folders and files in the file system that Content Engine will use for a file storage area.

Optionally, you can use an OS group account. All ce_os_user accounts would be members of the group account. If you do not set up such a group, then that single user account ce_os_user must be used to log on to each Content Engine and file storage server instance.

NOTE  When we speak of Content Engine running under an OS user account, we are referring to a specific instance of the JVM that is executing as a process on the host operating system. This particular JVM is hosting the application server that starts Content Engine. The JVM executes with a set of credentials associated with a specific account known to the OS on which the process is started. This account might or might not be defined as a user or group in the directory service that Content Engine uses to authenticate users. It is not relevant whether or not Content Engine knows about the account. What is relevant is that the OS must know about it.

Shared root directory - Windows and UNIX

A Content Engine file storage area is always created under a shared root directory that has been created by the OS user account, ce_os_user. The ce_os_user is responsible for securing the root directory in a way that grants full control access to the Content Engine server (represented either by the ce_os_user or group account) and preventing all other users from obtaining unauthorized access to files in the area.

The Create a Storage Area Wizard creates the storage area folder structures below the root directory, but does not directly set permissions on any of these folders. Instead, the folders are secured via inherited security. The inheritance scheme differs between Windows and UNIX and is discussed in detail below. Note that when Content Engine creates content element files within a storage area, it does not directly set permissions on the files; it always allows permissions to be inherited.

NOTE  When properly configured using the instructions in this topic, content files are completely safe from unauthorized users.

Inherited Security - Windows file system

Under Windows, file and folder permissions can be inherited via true inheritance. Folders and files can receive inherited permissions from their parent folder, without an application setting permissions on the newly created file or folder. The Content Engine file security scheme under Windows requires the system administrator (who is logged on as ce_os_user) to create the root directory in a way that provides proper inheritance and provides proper access control.

Secure the root directory of a file storage area as follows:

Sharing the root folder - Windows

Once it is secured, you must share the root folder so it can be accessed across the network. Permissions on a share cannot define access that is any less restrictive than the permissions of the folder that is shared. The recommended scheme is to grant full control access on the share to the same set of users and groups that have been granted full control access on the shared folder.

NOTE  Do not confuse security on the share with security on the shared folder. These are two different Windows security features. Consult Windows operating system online help documentation for definitions and procedures.

Inherited Security - UNIX file system

Under UNIX, file and folder permissions are inherited via the file creation mask (called the umask) of the user that creates the file or folder. Files and folders do not inherit the access rights of the parent folder. The Content Engine file security scheme under UNIX is to require the system administrator to properly configure the creation mask of the Content Engine OS account (ce_os_user) to grant the proper permissions on newly created files and folders. The root folder must be created with the same permissions as those granted by the ce_os_user creation mask, which should grant the following permissions:

Creation mask example:

umask u=rwx,g=rwx,o=
or
umask 0007

NFS Sharing

The root folder must be exported via NFS on the server side (meaning the computer that hosts the file system) and mounted (via NFS) on the client side. Once the root folder has been properly shared via NFS, security is enforced via the user and group identifiers of the client (as if the client logged on locally to the server computer). The client in this case is the Content Engine server running on a remote computer.

Root Account access to the NFS Share

Make sure you prevent non-local root access to a folder that has been exported via NFS, as allowing non-local root access has serious implications for security. For example, in Linux the no_root_squash option must not be included in the export options.

Content Engine on UNIX, file storage on Windows

You can make a Windows-based file storage area available to a UNIX-based Content Engine by using a Windows NFS server product. For information on supported NFS products, refer to the IBM FileNet P8 Hardware and Software Requirements. To download this document from the IBM Information Management support page, see Accessing IBM FileNet documentation.

Another possible option if your operating system is Windows 2003 Server R2 is to use the Windows NFS server that is included in that operating system. This Windows NFS server must reside on the same machine as the Windows file shares. Consult your operating system documentation for details.

Once your NFS Server product has been installed on your Windows machine containing your file stores, you must mount it on the UNIX machines where Content Engine is running. If you have a cluster of Content Engine servers on different UNIX boxes, the mount point on each UNIX box must be the same.

Content cache area security

Security for content cache areas is the same as for file storage areas. Create the shared root directory for the content cache area using the same procedures and principles as for file storage areas before running Enterprise Manager Create a Content Cache wizard.

Content cache areas can be on UNIX or Windows. They can be remote from the Content Engine server, although they are intended to be on a network that is geographically close. It must be on a network-accessible path that all Content Engine servers in the FileNet P8 domain can access.