IBM FileNet P8

Version 5.1.0

Security Extract



GC19-3234-03

IBM FileNet P8
Version 5.1.0

Security Extract



GC19-3234-03

Note
Before using this information and the product it supports, read the information in Notices on page 261.

This edition applies to version 5.1.0 of IBM FileNet Content Manager (product number 5724-R81), version 5.1.0 of
IBM FileNet Business Process Manager (product number 5724-R76), and to all subsequent releases and
modifications until otherwise indicated in new editions.
Copyright IBM Corporation 2006, 2011.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.

Contents
ibm.com and related resources . . . . vii
How to send your comments . . . . . . . . vii
Contacting IBM. . . . . . . . . . . . . viii

Security overview . . . . . . . . . . 1
How does IBM FileNet P8 secure its objects?
How is security applied? . . . . . . .
User authentication . . . . . . . . .
Configuring authentication and authorization
Security cache . . . . . . . . . . .
Security administrators and security tools .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

1
4
4
5
6
6

Authentication . . . . . . . . . . . . 9
Authentication overview . . . . . . . . . . 9
Supported authentication standards. . . . . . 9
FileNet P8 Platform server authentication
architecture . . . . . . . . . . . . . 13
JAVA-based client authentication (JAAS). . . . . 14
Browser-based clients of J2EE application servers 15
J2EE thick Java client . . . . . . . . . . 17
Support for Content Engine 3.5 Java API clients 18
Support for Java applets . . . . . . . . . 18
Single sign-on integrations via JAAS . . . . . . 19
Web-Services-based client authentication via
Ws-Security . . . . . . . . . . . . . . 23
Username token credentials . . . . . . . . 24
Kerberos Credentials . . . . . . . . . . 25
Web Service extensible authentication framework 27
SAML credentials . . . . . . . . . . . 29
Java-based clients over the Web service transport 29
Process Engine authentication . . . . . . . . 29
Application Engine and Workplace authentication
33
Workplace application . . . . . . . . . . 33
Workplace applets . . . . . . . . . . . 34
Application Integration clients . . . . . . . 35
IBM FileNet P8 Portlets clients . . . . . . . 35
WebDAV clients . . . . . . . . . . . . 36
Kerberos for Content Engine. . . . . . . . . 36
Introduction to Kerberos . . . . . . . . . 37
Kerberos prerequisites . . . . . . . . . . 38
Creating the Kerberos Service Principal Name
(SPN) identity . . . . . . . . . . . . 41
Choosing the SPNs . . . . . . . . . . 42
Creating an Active Directory user account . . 42
Mapping the Active Directory user account to
the SPN . . . . . . . . . . . . . 43
Creating a Kerberos keytab entry for the SPN
on the Content Engine system . . . . . . 44
Enabling Kerberos on the application server . . 45
Enabling Kerberos on the application server
(WebLogic 9.1 and later) . . . . . . . . 45
Enabling Kerberos on the application server
(WebSphere 6.0) . . . . . . . . . . . 46
Enabling Kerberos on the application server
(WebSphere 6.1 and 7.0) . . . . . . . . 47
Copyright IBM Corp. 2006, 2011

Enabling Kerberos on the application server

(JBoss) . . . . . . . . . . . . . .
Using RC4-HMAC Security . . . . . . . .
KrbServiceLoginModule options . . . . . .
Using Kerberos on the client. . . . . . . .
Using Kerberos with a cluster of Content Engine
servers . . . . . . . . . . . . . . .
Cross-realm Kerberos authentication . . . . .
Implementation on Windows 2008 R2 . . . .
Troubleshooting Kerberos. . . . . . . . .
Recovering from .NET client or Enterprise
Manager problems . . . . . . . . . .
Unable to connect to the remote server .Net client . . . . . . . . . . . .
The network path was not found . . . .
There are currently no login servers
available to service the login request . . .
A specified login session does not exist. . .
Recovering from Content Engine server
problems . . . . . . . . . . . . .
null key (9) . . . . . . . . . . .
Encryption errors . . . . . . . . .
Password has expired - change password
to reset (23) . . . . . . . . . . .
Identity errors . . . . . . . . . .
Request is a replay (34) . . . . . . .
Clock skew too great (37). . . . . . .
Identity user is not found in the keytab . .
Could not create default
AuthorizationToken during propagation
login . . . . . . . . . . . . .
Principal [email protected]
not found . . . . . . . . . . . .
JAAS configuration
FileNetP8KerberosService not found . . .
Cannot get kdc for realm
MYDOM.EXAMPLE.COM . . . . . .
Null key . . . . . . . . . . . .
Null name . . . . . . . . . . . .
Failure to obtain initial naming context . .

47
48
49
50
50
51
52
53
53
53
54
55
55
55
56
56
57
57
58
58
58

59
59
60
60
60
61
61

Authorization . . . . . . . . . . . . 63
About access rights . . . . . . . . . . .
What are access rights? . . . . . . . .
ACE source: Default, Direct, Inherited, Template
ACE security levels . . . . . . . . . .
Allow or Deny and order of evaluation . . .
Default security . . . . . . . . . . . .
Security for integrated components and third-party
products . . . . . . . . . . . . . .
Browsers . . . . . . . . . . . . .
Database security . . . . . . . . . .
Security for IBM Legacy Content Search Engine
Security for IBM Content Search Services . .
Security for FileNet P8 eForms . . . . . .

. 63
. 64
67
. 67
. 68
. 68
. 69
. 70
. 70
70
. 70
. 71

iii

Security for IBM Enterprise Records . . . . . 71

Mapping security levels to individual access rights 71
FileNet P8 domain root security levels . . . . 72
Object store security levels . . . . . . . . 73
Class definition security levels . . . . . . . 74
Folder security levels . . . . . . . . . . 75
Document security levels . . . . . . . . . 76
Custom object security levels . . . . . . . 77
Other object security levels . . . . . . . . 79
Markings . . . . . . . . . . . . . . . 79
Markings overview . . . . . . . . . . . 80
Marking security: Add, Remove, Use . . . . . 81
Effect of Copy to reservation . . . . . . . 82
Constraint Mask . . . . . . . . . . . . 82
Allow, Deny permissions . . . . . . . . . 83
Hierarchical and Non-hierarchical . . . . . . 84
Marking administration (create, modify, remove) 85
Object access rights and security . . . . . . . 86
Securable objects . . . . . . . . . . . 86
Access rights required to take actions. . . . . 87
Object store access rights . . . . . . . . . 90
Class access rights . . . . . . . . . . . 91
Folder access rights. . . . . . . . . . . 93
Document access rights . . . . . . . . . 94
Compound document security . . . . . . . 97
Document lifecycle policies and lifecycle actions
access rights . . . . . . . . . . . . . 98
Annotation access rights . . . . . . . . . 98
Custom object access rights . . . . . . . . 99
Workflow definition access rights . . . . . . 99
Event and subscription access rights. . . . . 100
Script access rights . . . . . . . . . . 100
Publishing access rights . . . . . . . . . 100
Search access rights . . . . . . . . . . 102
Document entry template access rights . . . . 103
Workflow rosters and queues . . . . . . . 105
Object ownership . . . . . . . . . . . . 105
Property modification access . . . . . . . . 107
Required minimum access rights by operation . . 112
Security policies . . . . . . . . . . . . 112
About security policies . . . . . . . . . 113
About templates . . . . . . . . . . . 113
Assigning security policies . . . . . . . . 114
Preserve Direct ACEs . . . . . . . . . . 115
Effects of changes . . . . . . . . . . . 115
Rules of association . . . . . . . . . . 116
Support in Workplace and Workplace XT . . . 117
Custom objects and folders . . . . . . . . 117
Storage area security . . . . . . . . . . . 117
File storage area security . . . . . . . . 118
Content Engine on UNIX, file storage on
Windows . . . . . . . . . . . . . . 121
Content cache area security. . . . . . . . 121
Target access required . . . . . . . . . . 121
Understanding security inheritance . . . . . . 125

Directory service providers . . . . . 127

CA Directory . . . . . . .
Overview (CA Directory) . .
Support matrix (CA Directory)

iv

Security Extract

.
.
.

.
.
.

.
.
.

.
.
.

.
.
.

. 129
. 129
. 130

Directory Configuration Properties (CA

Directory) . . . . . . . . . . . . .
Get and search operations (CA Directory) . . .
IBM Tivoli Directory Server . . . . . . . .
Overview (IBM Tivoli Directory Server) . . .
Support matrix (IBM Tivoli Directory Server)
Directory Configuration Properties (IBM Tivoli
Directory Server) . . . . . . . . . . .
Get and search operations (IBM Tivoli Directory
Server) . . . . . . . . . . . . . .
Novell eDirectory . . . . . . . . . . . .
Overview (Novell eDirectory) . . . . . . .
Support matrix (Novell eDirectory) . . . . .
Directory Configuration Properties (Novell
eDirectory) . . . . . . . . . . . . .
Get and search operations (Novell eDirectory)
Oracle Internet Directory . . . . . . . . .
Overview (Oracle Internet Directory) . . . .
Support matrix (Oracle Internet Directory) . .
Directory Configuration Properties (Oracle
Internet Directory). . . . . . . . . . .
Get and search operations (Oracle Internet
Directory) . . . . . . . . . . . . .
Oracle Directory Server Enterprise Edition . . .
Overview (Oracle Directory Server Enterprise
Edition) . . . . . . . . . . . . . .
Support matrix (Oracle Directory Server
Enterprise Edition) . . . . . . . . . .
Directory Configuration Properties (Oracle
Directory Server Enterprise Edition) . . . . .
Get and search operations (Oracle Directory
Server Enterprise Edition) . . . . . . . .
Windows Active Directory . . . . . . . . .
Support matrix (Active Directory) . . . . .
Directory Configuration Properties (Active
Directory) . . . . . . . . . . . . .
Realm Configuration (Active Directory) . . .
Failover Support (Active Directory) . . . . .
Get and search operations (Active Directory)
Windows Active Directory Lightweight Directory
Services (AD LDS). . . . . . . . . . . .
Overview (Active Directory Lightweight
Directory Services) . . . . . . . . . .
Support matrix (Active Directory Lightweight
Directory Services) . . . . . . . . . .
Directory Configuration Properties (Active
Directory Lightweight Directory Services) . . .
Get and search operations (Active Directory
Lightweight Directory Services) . . . . . .
Directory service performance . . . . . . . .
Configuring sorting for Oracle Directory Server
Enterprise Edition . . . . . . . . . . .
Configuring sorting for Novell eDirectory . . .

131
133
133
133
134
135
137
138
138
138
140
141
142
142
142
143
145
146
146
146
148
149
150
150
152
154
155
158
160
160
162
163
165
166
166
174

Users and groups required by FileNet

P8 . . . . . . . . . . . . . . . . 177
Operating system accounts . . . . . . . .
Application Engine or Workplace XT installer
account . . . . . . . . . . . . .
Application Engine or Workplace XT deploy
account . . . . . . . . . . . . .

. 177
. 178
. 180

Content Engine application server installation

administrator . . . . . . . . . . . .
Content Engine application server installation
group . . . . . . . . . . . . . . .
Content Engine installer account . . . . . .
Content Engine operating system user account
Content Engine installer account . . . . . .
Configuration Manager user . . . . . . .
Content Engine user account for DB2 for Linux,
UNIX and Windows . . . . . . . . . .
Content Engine user account for DB2 for z/OS
Content Engine instance accounts for DB2 for
z/OS . . . . . . . . . . . . . . .
Process Engine installer account . . . . . .
Process Engine database user for DB2 for Linux,
UNIX and Windows . . . . . . . . . .
Process Engine database user for DB2 for z/OS
IBM Legacy Content Search Engine operating
system user . . . . . . . . . . . . .
IBM Legacy Content Search Engine security
group . . . . . . . . . . . . . . .
IBM Legacy Content Search Engine security
user . . . . . . . . . . . . . . .
IBM Content Search Services operating system
account . . . . . . . . . . . . . .
IBM Content Search Services installer account
Directory server accounts . . . . . . . . .
Creating the application server administrative
console user (WebSphere Application Server) . .
Application Engine or Workplace XT
administrator account . . . . . . . . .
Content Engine upgrade user . . . . . . .
Content Engine bootstrap account . . . . .
GCD administrator . . . . . . . . . .
Object store administrator . . . . . . . .
Content Engine Service user (Active Directory)
Content Engine Service user (AD LDS) . . . .
Content Engine Service user (Oracle Directory
Server Enterprise Edition) . . . . . . . .
Content Engine Service user (Novell eDirectory)
Content Engine Service user (IBM Tivoli) . . .
Content Engine Service user (Oracle Internet
Directory) . . . . . . . . . . . . .
Content Engine Service user (CA Directory) . .
Process Engine service user. . . . . . . .
Process Engine administrator group . . . . .
Process Engine configuration group . . . . .
Process Engine region administrator . . . . .
Publishing user account . . . . . . . . .
CFS for IS User. . . . . . . . . . . .
Database accounts . . . . . . . . . . . .
Content Engine SQL Server account . . . . .
Content Engine Oracle account . . . . . .
Content Engine DB2 for Linux, UNIX and
Windows account . . . . . . . . . . .
Content Engine DB2 for z/OS account . . . .
Process Engine database user for DB2 for Linux,
UNIX and Windows . . . . . . . . . .
Process Engine database user for DB2 for z/OS
Process Engine database user for Oracle . . .
Process Engine database user for SQL Server

Application server accounts . .

Application server administrator
FileNet P8 internal accounts . .
PSConsole . . . . . . .
PSDesigner . . . . . . .
PWAdministrator . . . . .
PWConfiguration . . . . .
PWDesigner . . . . . . .
PWDiagram . . . . . . .
#AUTHENTICATED-USERS .
#CREATOR-OWNER . . . .

181
181
182
182
183
184
184
185
185
185

187
188
189

190
191
191
192
193
193
194
195
196
197
197
198
199
199
200
200
200
201
201
201
202
203
203
204
205
205
206
207

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

207
207
209
209
209
210
210
210
211
211
212

Security tools and procedures . . . . 215

186
187

189
189
190

.
.
.
.
.
.
.
.
.
.
.

Content Engine bootstrap properties. . . . .

Digital signing . . . . . . . . . . . .
Displaying security . . . . . . . . . .
Enterprise Manager security editor . . . .
Enterprise Manager's Select Users and Groups
dialog box . . . . . . . . . . . .
Workplace and Workplace XT security editor
Site and user preferences . . . . . . .
Logging on and using Enterprise Manager . .
Network security . . . . . . . . . . .
Encryption . . . . . . . . . . . . .
Content Engine credential encryption . . .
Encrypting Credentials . . . . . . . .
Resetting keys . . . . . . . . . . .
Content encryption . . . . . . . . .
TLS, SSL, and data privacy . . . . . . . .

.
.
.
.

217
219
219
220

. 221
221
. 222
. 223
. 223
. 224
. 224
. 224
. 226
. 227
. 227

How to... . . . . . . . . . . . . . 229

Add users and groups to a class . . . . .
Add users and groups to a single object . .
Add or remove a GCD administrator . . .
Add or remove an object store administrator .
Allow or disallow security inheritance . . .
Allow users to add items to a folder. . . .
Change Bootstrap admin password . . . .
Configure a folder's security inheritance . .
Configure security inheritance . . . . . .
Designating a folder as a security parent by
using Security Parent . . . . . . . .
Designating a folder as a security parent by
using Security Folder . . . . . . . .
Configuring security inheritance by using a
custom object-valued property. . . . .
Configure Content Engine to use email or UPN
login . . . . . . . . . . . . . .
Configure inheritable depth (Apply to) . . .
Configure multiple authenticating attributes .
Configure multiple realms . . . . . . .
Configure multiple realms (WebSphere and
WebLogic) . . . . . . . . . . .
Configure multiple realms (JBoss 4.x) . .
Configure multiple realms (JBoss 5.x) . .
Deny an object store administrator access to a
document . . . . . . . . . . . .
Modify an object's security . . . . . . .
Restrict access to the root folder . . . . .
Set security on workflow queues and rosters .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

. 236

. 237

. .
for
. .
. .
. .
. .

229
230
231
231
232
232
232
235
236

238
242
243
243
245

.
.
.

. 245
. 246
. 246

.
.
.
.

.
.
.
.

248
250
250
250

Contents

. 251
251

Notices . . . . . . . . . . . . . . 261

Security example . . . . . . . . . . 253

Index . . . . . . . . . . . . . . . 265

Take or change ownership . . . . . . . .

Update object store with new users and groups

Analysis .
Setup . .

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

. 255
. 257

Frequently asked questions about

FileNet P8 Platform security . . . . . 259

vi

Security Extract

Trademarks .

. 263

ibm.com and related resources

Product support and documentation are available from ibm.com.

Support and assistance

Product support is available on the Web. Click Support from the product Web site
at:
FileNet Content Manager Support
http://www.ibm.com/software/data/content-management/filenet-contentmanager/support.html

Information center
You can view the product documentation in an Eclipse-based information center
that you can install when you install the product. By default, the information
center runs in a Web server mode that other Web browsers can access. You can also
run it locally on your workstation. See the information center at
http://publib.boulder.ibm.com/infocenter/p8docs/v5r1m0/index.jsp.

PDF publications
You can view the PDF files online using the Adobe Acrobat Reader for your
operating system. If you do not have the Acrobat Reader installed, you can
download it from the Adobe Web site at http://www.adobe.com.
See the following PDF publications Web sites:
Product

Web site

Product Documentation for FileNet http://www.ibm.com/support/docview.wss?rs=86

P8 Platform
&uid=swg27021611

How to send your comments

Contacting IBM on page viii

How to send your comments

Your feedback is important in helping to provide the most accurate and highest
quality information.
Send your comments by using the online reader comment form at
https://www14.software.ibm.com/webapp/iwm/web/signup.do?lang=en_US
&source=swg-rcf.

Consumability survey
You are invited to tell IBM how to improve the consumability of software
products. If you want to help IBM make IBM FileNet P8 easier to use, take the
Consumability Survey at http://www.ibm.com/software/data/info/
consumability-survey/.
Copyright IBM Corp. 2006, 2011

vii

Contacting IBM
To contact IBM customer service in the United States or Canada, call
1-800-IBM-SERV (1-800-426-7378).
To learn about available service options, call one of the following numbers:
v In the United States: 1-888-426-4343
v In Canada: 1-800-465-9600
For more information about how to contact IBM, see the Contact IBM Web site at
http://www.ibm.com/contact/us/.

viii

Security Extract

Security overview
This section presents a quick overview of IBM FileNet P8's security features and
design.
How does IBM FileNet P8 secure its objects?
How is security applied? on page 4
User authentication on page 4
Configuring authentication and authorization on page 5
Security cache on page 6
Security administrators and security tools on page 6

How does IBM FileNet P8 secure its objects?

Object security depends on several inter-related security features.
In FileNet P8, you secure data by specifying the directory service user context that
controls who logs on to the system, setting access rights for those users, creating
and applying security policies, and setting site preferences for user actions.
Optionally, you can use technologies such as firewalls and proxy servers to control
access to your network and Secure Sockets Layer (SSL) to provide data privacy.
FileNet P8 domain
Similar to other domain architectures, the FileNet P8 domain is a defined security
context: only those users, groups, machine accounts (such as services), applications,
processes, and scripts, that have been explicitly granted access to the FileNet P8
domain can access its resources (such as objects, documents, workflows).
How Access Control Works
After a user has been authenticated, but before he or she is allowed to perform any
operations in an object store, a security token is generated specifically for that
user's account that serves as a sort of internal passport. Like a passport, the
security token is presented to an object at the time access is requested and it is
used by the object to determine who the user is and whether or not the user is
authorized for the type of access that is requested.
The security token contains the current and historical security identifiers (SIDs) for
the user and for the groups that the user belongs to (recursively), and the SID for
#AUTHENTICATED-USERS.
Each securable Content Engine object has an associated security descriptor, part of
which is the Access Control List (ACL). The ACL consists of a set of Access Control
Entries (ACEs), also called permissions. Each permission specifies one security
principal (user or group, via a SID), and an access mask for that SID. The access
mask defines the specific operations that the grantee identified by the SID is
allowed to perform. Each bit in the mask corresponds to a specific operation. If the
bit is set, the security principal is authorized to perform that operation.
The above describes "normal" authorization, where markings have not been
implemented. Markings provide another layer of authorization, described below.
Independently and dependently securable objects
Copyright IBM Corp. 2006, 2011

Most Content Engine object classes are independently securable, meaning they are
secured by their own ACL. Some are dependently securable, meaning that their
security depends on some other object that they are associated with. A good
example is the Content Element object, which can only exist in relationship to a
Document object. The Document object is independently securable, while its
various Content Elements take their security from the Document they are assigned
to.
ACL and ACE model
Securable objects are secured by ACLs comprised of ACEs. Understanding the
ACL/ACE model, and how security principals are determined and permissions
granted is central to understanding how to design a secure FileNet P8 system.
First comes authentication, then comes authorization. Users are first authenticated
to the FileNet P8 domain, which corresponds to a particular user context in the
associated authentication provider. This determines that users are who they say
they are, by validating their login user name and password. Thereafter,
authenticated users are authorized to do certain things by the security of
individual objects. For example, once the authentication process determines that
you are in fact the user Bob who is known to the authentication provider, then the
ACL on each securable object will determine what actions Bob can perform on the
object (including nothing at all!)
Users and groups that are authenticated to access a FileNet P8 system arrive into
the FileNet P8 security context with no inherent permissions of any sort. It is up to
the object store administrator to assign FileNet P8-specific permissions to these
accounts. For example, a user who is a Windows domain administrator is just like
any user to FileNet P8. The user could be granted FileNet P8 object store
administrative permissions while the Windows domain administrator could be
granted nothing more than view or read-content permissions. In other words, the
security context of the directory service or other software applications has no
applicability to the FileNet P8 security model (and vice versa).
If your operating system is Microsoft Windows, do not use Windows service
accounts for any user or group accounts required by FileNet P8.
Some other security features applied to ACEs and secured objects are:
Allow and deny
Each ACE that is present on an object's ACL is either allowed or denied
the right to do certain things. For example, a particular class of documents
could allow Alice to delete a document but deny Bob the same right.
Following standard practice, deny always takes precedence over allow,
which means you must set up ACLs carefully. If Alice is allowed access to
a document as a user but belongs to a group that is denied access, then she
will not have access to the object.
Inheritable depth
Certain rights are inheritable. FileNet P8 lets you configure whether they
should not be inherited, or inherited only by objects that are immediate
children (first generation only), or by all children.
Ownership
Most objects have an owner, who is usually the user who created the
object. Similar to the Windows "built in" accounts, FileNet P8 automatically
applies an internal "special" user account called the Creator-Owner,

Security Extract

obviously suggesting that the creator of an object is its owner. System

administrators can take ownership when necessary to change the object's
security.
Authenticated users
The other "special" account, internally maintained by Content Engine, is
the logical group #AUTHENTICATED-USERS. All users and groups who
can potentially log in to FileNet P8 are automatically considered members
of #AUTHENTICATED-USERS. This makes it the FileNet P8 equivalent of
the Windows "Everyone" group, and makes it easy to allow permissions to
everyone who can log in, irrespective of exactly who those users are at any
given time. You should never assign the DENY permission to
#AUTHENTICATED-USERS because this denies access to all accounts,
even to administrators (because deny always takes precedence over allow).
To correct a lockout of this type might require IBM assistance.
Importance of installation and configuration
As you would expect, important security decisions are made during Content
Engine installation and configuration. Among these are:
v Which directory server will be used, where it is located, and how FileNet P8 will
integrate with it. During configuration, you will select your directory service and
then provide values for integration parameters. For example, for non-Windows
Active Directory authentication you would instruct FileNet P8 whether or not to
chase any referrals that FileNet P8 might find. (A referral is an attribute that
specifies the URL that should be returned for an entry not belonging to the local
tree.) You would provide this value based on your knowledge of your directory
service topology and your specific authentication requirements.
v Whether you will plug in an SSO solution.
v Which users and groups in your directory service should be FileNet P8
administrators (there are several different administrative roles required by
FileNet P8.) and which should be FileNet P8 users. Both types receive initial,
default permissions (documented in Object Access) which you can later modify
if necessary.
v How and where will SSL be used (if at all) between FileNet P8 components,
associated applications, and supported platforms. It is a best practice to use SSL
in production environments.
Markings
Markings provide an additional, optional layer of security that is primarily
designed for the records management marketplace, but which can also be applied
by non-records management applications.
Auditing
FileNet P8's audit logging capabilities, while not being a security feature itself, is
closely related to the topic of making sure your systems are properly secured and
monitored. Content Engine also provides configurable trace logging.
Modification access required
If your installation requires finer-grained security, you can configure a modification
access mask that specifies access rights needed to view or modify custom
properties. These access rights take precedence over those applied to the object
itself. Like markings, this security feature is designed for records management
applications, but can be used by any application.
Security overview

Access to content - querying and exporting

All files that represent document content and that have been stored in a FileNet P8
storage area (file storage area, fixed storage area, or database storage area) are
completely protected by the FileNet P8 security model. Only those users who have
been granted access to the content by a FileNet P8 application will have access,
whether through content-based retrieval (CBR) queries, direct SQL queries,
navigation of the network file structure containing a file storage area, etc.
Related information:
Audit concepts
Concepts: Trace logging
Content storage

How is security applied?

FileNet P8 provides several ways to apply security to objects.
Normally, an object's security is controlled or determined in four ways. (Markings,
if they are used, would be a fifth way.) The following are brief descriptions.
Default instance security
As an integral part of the class and instance design, objects such as
documents, folders, and events are instances of their class. The class
includes, among other things, a property containing the default security
permissions that will be applied to all instances of the class. This is the
simplest method of applying security: the security design sets up the
default security that all instances of a class should have, and then all
objects based on that class will have the same default security.
Security parent and inheritance
Permissions can also be inherited from a parent object. Inheritance can take
place between a class and its subclass, and between a folder and its
containable objects (documents, custom objects, and other folders).
Security policies and security templates
Security policies contain security templates which let you automatically
apply security to documents, folders, and custom objects. In the case of
documents, security templates can be associated with one of the several
versioning states that documents pass through (Released, Superseded, In
Process, or Reservation). This powerful feature provides efficient
application of fine-tuned security across many objects.
Directly applied security
Users who have sufficient permission can edit an object's security by
directly adding or removing security principals, or by changing the
existing permissions already granted.

User authentication
All logins to FileNet P8 are done through the Java Authentication and
Authorization Service (JAAS).
Authentication is a process that occurs between a J2EE client application (for
example, Workplace), a J2EE application server (either WebLogic, WebSphere or
JBoss, hosting an instance of Content Engine), and one or more JAAS login
modules. This process does not involve any FileNet P8 code. Content Engine's

Security Extract

ability to leverage JAAS for authentication means that if a single sign-on (SSO)
provider writes a JAAS Login Module for a supported application server, then
clients of FileNet P8 applications hosted in that application server can leverage that
SSO solution. See the Authentication section for full information on FileNet P8
authentication architecture.
As a result, and unlike earlier releases of FileNet P8, the Content Engine
installation process configures authentication and authorization separately even
though these two configurations will often use the same information.
Authorization takes place by means of a direct connection between Content Engine
and one of the supported directory services. See the Directory service providers
section for details. The IBM FileNet P8 Hardware and Software Requirements contains
the supported versions of these third-party products.
Process Engine delegates authentication tasks to Content Engine. A client of the
Process Engine authenticates with the Content Engine server, and then sends the
credentials obtained from the Content Engine to the Process Engine server with
each request. See Process Engine Authentication for details.

Configuring authentication and authorization

Authentication and authorization require different kinds of configuration.
Two objects are required to map a directory service's naming context or namespace
(a set of names accessible at a given node in the directory server's tree of accounts),
to a FileNet P8 realm:
v On the J2EE application server, you set up authentication by configuring the
application server's LDAP/authentication parameters that point to a naming
context in one of the supported directory servers. (These could optionally point
to an SSO solution.)
v Using Enterprise Manager's Directory Configuration Wizard, you then configure
authorization by creating a directory configuration object that points to the
directory service.
The following graphic shows the different configurations for authorization and
authentication, for a single FileNet P8 domain:
Login
Application server
IBM FileNet Content Engine
GCD directory
configuration objects

Application server
authentication
configuration

Authorization

SSO

Authentication
Directory server

FileNet P8 supports multi-realm authentication provided the application server

supports it. See Configure multiple realms for instructions on how to add
additional realms following initial Content Engine installation.

Security overview

Security cache
For performance reasons, both Process Engine and Content Engine cache
information on users, groups, and realms returned by the directory service.
Cached security information can become stale as a result of changes made to the
directory server. Each collection of users, groups and realms is subject to a time to
live (TTL). From the time that a collection is first retrieved until the TTL interval
has elapsed, requests for the same collection will return the cached information.
Once the TTL has elapsed, the cached information will be discarded and fresh data
will be obtained from the directory server.
Cache staleness can have the following effects:
v Recently added users, groups, or realms will not be visible in the relevant
collections.
v Recently deleted users, groups, or realms will appear to be still present until the
credentials cache refreshes.
v Updates to user or group information (for example, changed display name) will
not be visible.
Staleness does not affect the ability to use a recently added user or group name in
programmatic calls, nor to log in as a recently added user. Also, staleness does not
compromise the security of objects. The default TTL for Process Engine security
cache is four hours. Content Engine has several default TTL settings. For
information on how to set the Content Engine server caches, see FileNet P8
domain properties (Server Cache tab). For information on managing the Process
Engine security cache, see Manage the Process Engine user cache.
Related information:
FileNet P8 domain properties (Server Cache tab)
Manage the Process Engine user cache

Security administrators and security tools

Working with security requires several administrative accounts and a number of
different tools.
FileNet P8 provides several important security roles:
v GCD administrators create FileNet P8 domain resources like object stores and
fixed content devices.
v Object store administrators create file storage areas, classes, folders, security
policies and other object store resources. The GCD administrator is not
automatically also an object store administrator, although GCD administrators
can grant themselves this additional role.
v Application Engine administrator sets up Workplace and Workplace XT site
preferences.
v Process Engine administration and configuration groups perform a variety of
workflow configuration tasks.
The Users and groups topic provides full reference information.
FileNet P8 provides the following tools for configuring security:

Security Extract

Enterprise Manager
This is the tool that system administrators will use in their daily work.
Like similarly named tools provided by Microsoft SQL Server and Oracle,
Enterprise Manager gives system administrators easy access to most of the
administrative and security features needed for Content Engine security
configuration tasks.
Process Engine
Using the Process Engine Configuration Console, the Process Engine
administrator can assign access rights to workflow rosters, work queues,
and user queues. You will use another Process Engine tool, the Process
Task Manager, to configure how the Process Engine integrates with the
directory service.
Workplace and Workplace XT, and related applications (Application Integration,
IBM InfoSphere Enterprise Records, eForms)
The security context for applications is defined and maintained by a
combination of Content Engine, Process Engine, and Workplace or
Workplace XT. Consider the following examples:
v Object security (documents, folders, custom objects, events) is maintained by
Content EngineContent Engine.
v Workplace and Workplace XT maintain their own configuration settings in its
Site Preferences, which can be considered a security feature because they
determine such things as whether a user can see certain types of documents. Site
preference for Default Access Roles determines the members of such roles as
Application Engine Administrators, PSConsole, PSDesigner, PWAdministrator,
PWConfiguration and PWDesigner.
v Workplace and Workplace XT also makes use of rosters, queues, and other
workflow-related objects that are created and maintained as a part of Process
Engine security.
v The Process Configuration Console is available in Workplace and Workplace XT.
Some security tasks can be completed by duly authorized users logged on to these
applications, while others, including most of the more advanced tasks, are
completed by an object store administrator running Enterprise Manager. Consult
documentation provided for Workplace, Workplace XT, and other applications to
see how much security-related functionality can be carried out by Application
Engine administrators and advanced users.

Security overview

Security Extract

Authentication
Authentication is the act of verifying users' identities based on credentials that
those users present.
Authentication overview
JAVA-based client authentication (JAAS) on page 14
Single sign-on integrations via JAAS on page 19
Web-Services-based client authentication via Ws-Security on page 23
Process Engine authentication on page 29
Application Engine and Workplace authentication on page 33
Kerberos for Content Engine on page 36

Authentication overview
Authentication depends on several components.
Supported authentication standards
FileNet P8 Platform server authentication architecture on page 13

Supported authentication standards

The two standards at the core of the FileNet P8 authentication process are the Java
Authentication and Authorization Service (JAAS) standard and the Web Services
Security standard (WS-Security).
The JAAS standard forms the framework for security interoperability in a J2EE
environment, while the WS-Security standard forms the framework for security
interoperability in the heterogeneous environment of clients and servers that
communicate through Web services interfaces.
JAAS overview
Content Engine leverages JAAS for authentication (but not for
authorization and it does not support the Java Security Manager). See the
Directory Service Provider section for information about how Content
Engine handles authorization.
JAAS provides a policy-based framework for reliably and securely
determining who is invoking a Java application. Using this pluggable
framework, applications like Content Engine can remain independent of
the underlying authentication technologies. Likewise, application server
vendors, authentication providers, and single sign-on (SSO) providers can
package solutions that can be leveraged by all J2EE applications and
clients. Customers can plug in new or updated SSO solutions without
modifying already deployed client and server applications.
The Content Engine Enterprise Java Bean (EJB) resides within the J2EE
Application Server's EJB container. The Content Engine EJB is therefore
accessible only by authenticated callers, those who can pass any
authorization checks that the administrator has placed on the EJB.

Copyright IBM Corp. 2006, 2011

J2EE client application

JAAS subject

Credentials

JAAS principal

JAAS credentials

End user
JAAS LoginContext

JAAS configuration

JAAS
login

Login
results

JAAS framework

JAAS LoginModule

JAAS LoginModule

JAAS authentication
The client application obtains a JAAS Subject prior to calling the Content
Engine Java API. Interactions with the Content Engine Java API then result
in the Content Engine EJB being invoked. The client's JAAS subject is
transparently sent to the J2EE application server with each EJB call. The
application server validates the JAAS subject, and confirms the caller's
identity before executing any code in the Content Engine EJB.
Tip: For information about the authentication process used for a Web
service-based client, see Web-Services-Based Client Authentication Via
Ws-Security.
JAAS configurations
To use a J2EE-based application, a client must first perform a JAAS login.
To do this, the client must specify a JAAS configuration (typically through
a configuration file). The JAAS configuration specifies the authentication
technologies (Login Modules) that will be used to verify the client's
credentials.
A JAAS configuration file lists one entry for each configured application.
Within an application's entry is a list of Login Modules for that application.
Based on the contents of the configuration file, the JAAS framework
dynamically determines which set of authentication technologies to invoke
when a client application attempts to authenticate.
Each entry in a JAAS configuration is marked as Required, Requisite,
Sufficient, or Optional. The authentication process for the client succeeds
only if all Login Modules marked either Required or Requisite succeed. If
no Required or Requisite Login Modules succeed, then at least one
Sufficient or Optional Login Module must succeed.
JAAS login contexts
A J2EE client application must specify a JAAS configuration and a
mechanism through which credentials can be obtained from a user at
runtime. These two items constitute a JAAS Login Context. J2EE client
applications use the Login Context to interact with JAAS and to
authenticate themselves to a J2EE server.
JAAS login modules
JAAS-compliant Login Modules are implemented by authentication
technology providers. J2EE application server vendors, such as BEA, IBM,

10

Security Extract

and JBOSS, typically provide Login Modules for standard types of

credentials, such as user name and password or X.509 certificate. SSO
solution providers, such as CA Netegrity's SiteMinder, IBM's Tivoli Access
Manager, and Oracle's CoreID, provide login modules for most of the
market-leading J2EE application servers.
The JAAS Login Module is also the extensibility mechanism through which
custom authentication solutions can be integrated with the FileNet P8
platform. A customer with a custom, non-standard authentication
framework can integrate with FileNet P8 platform, by providing
JAAS-compliant Login Modules that work with the J2EE application server
that hosts the Content Engine application.
JAAS subjects
When a JAAS login has successfully completed, a JAAS Subject is returned
to the caller. The Subject is a key J2EE class, which is transparently sent
between J2EE clients and J2EE servers any time an EJB is invoked.
A JAAS Subject contains the set of JAAS principals (authenticated
identities) and JAAS credentials (authentication data such as cryptographic
keys) that result from the login process. Each Login Module that
successfully authenticates the user updates the Subject with information
about the user. A J2EE server application can examine the principals in the
Subject to establish the caller's identity.
JAAS trust mechanisms
Trust mechanisms vary significantly from J2EE application server to J2EE
application server and from Login Module to Login Module.
The JAAS Subject must either be signed by a party whom the application
server trusts, or whom a configured server-side Login Module trusts (and a
mechanism for configuring and verifying this trust relationship must exist),
or credentials must be included in the JAAS Subject that a server-side
Login Module can verify.
Each J2EE application server vendor has invented their own proprietary
trust mechanisms. This is one factor that prevents interoperability of Login
Modules between different J2EE implementations.
JAAS login module interoperability
JAAS Login Modules are generally not interoperable between different
J2EE application server vendors. For this reason, FileNet P8 platform
supports only homogeneous application server configurations: all Content
Engine servers, as well as all Application Engine servers, or other J2EE
presentation tier servers, must use the same J2EE application server as a
host.
Using JAAS from a stand-alone Java client
For applications that reside in a J2EE container, the containers provide a set
of JAAS integration capabilities that ease some of the interoperability
issues discussed above.
For thick-client Java applications, however, the application must create a
JAAS CallbackHandler to pass its credentials into a JAAS LoginContext. If
the application relies on a user name and password paradigm, then the
mechanism for doing this is well defined, and interoperability options are
well known. For any other type of credential, the standard is not clear on
what type of callbacks the application must use, nor how those callbacks
Authentication

11

should respond. In all cases, a stand-alone Java client must use Login
Modules compatible with the J2EE application server it wishes to call.
Once a JAAS Subject has been obtained by the application, there are
differences in how it indicates to the Java environment that the obtained
Subject should be used when executing a given set of code, such as
invoking an EJB. This is an area where the J2EE application server vendors
had to improvise, and, as a result, different runtime calls are required for
accessing different J2EE application servers.
WS-Security overview
A Web service is an XML-based interface to a system that is in
conformance with the key Web services standards. Through standards
compliance, Web services enable the development of service-oriented
architectures, and allow heterogeneous systems to discover one another
and interact. FileNet P8 has developed Web service interfaces to the
FileNet P8 Process Engine and Content Engine services, and supports the
use of Business Process Execution Language (BPEL)-compliant Web
services within a business process.
One of the key standards that defines a Web service is the WS-Security
standard, developed by the OASIS standards body. WS-Security defines
three main security mechanisms for Web services: security token
propagation, message integrity, and message confidentiality. In this topic,
we are only concerned with the first of these: security token propagation.
WS-Security provides profiles that define how different types of security
credentials are formatted and inserted into a Web service message.
Like JAAS, WS-Security is an extensible standard which supports multiple
security token formats. The WS-Security specification describes how to
encode a set of standard tokens as well as defining a general mechanism
for encoding any binary token. However, the specifics of the standard
tokens (the actual XML elements and attributes) are not defined in the
WS-Security specification. They are defined in separate profiles, including
the Username Token Profile, the X.509 Certificate Token Profile, the
Security Assertion Markup Language (SAML) profile, the Kerberos profile,
etc. It is these profiles that ensure interoperability between different
implementations using the same token type. Later subtopics will describe
how these profile types are used, or might be used, in the context of
FileNet P8.
Unlike JAAS, WS-Security does not provide an execution environment that
defines how to configure authentication on the client and server, or how a
client can become authenticated, or how a security provider can implement
and package a standards-compliant Login Module. WS-Security defines
only the encoding of security tokens within the SOAP XML header. The
sender of the token can perform an actual authentication, and send some
proof of identity with a reference to a security authority who vouches for
that identity (as in the Kerberos and X.509 certificate cases), or the sender
can send raw credentials, which must be verified by the server (as in the
username token case). The receiver of the token can process it in whatever
way it sees fit.
When the Content Engine server receives a Web service request, the
Content Engine Web service listener extracts the WS-Security header and
performs a JAAS login based on its contents. If this JAAS login is
successful, then the Web service listener passes the request onto the
Content Engine EJB layer within the EJB container.

12

Security Extract

FileNet P8 Platform server authentication architecture

The two primary servers in the FileNet P8 Platform are Content Engine and
Process Engine.
The following subtopics describe how these servers perform authentication.
Content Engine authentication architecture
The next figure shows a high-level view of a FileNet P8 Content Engine
server and some of the types of client applications that access it. Content
Engine is packaged as a J2EE application, deployed on one or more J2EE
application server instances. The key components of this application are:
v The Content Engine Web Service listener. This listener is packaged as a
servlet-based application that resides in the Web container of the
application server. The listener implements the Content Engine Web
service and supports FileNet P8 Web service clients. The listener exposes
the full functionality of the Content Engine server through a standard
Web services API. Requests that arrive at this Web service are
authenticated based on the credentials in their WS-Security headers, and
then passed on to the Content Engine EJB layer.
v The Content Engine EJBs. These J2EE session beans reside in the EJB tier
of the application server and implement the same Web services API as
the Content Engine Web Service, exposing them through an Enterprise
Java Bean interface, rather than a Web services interface. All clients of
this EJB layer must perform a JAAS login prior to sending a request to
one of the EJBs.
v The core content management logic resides in the resource adapter tier
of the application server.
The Web Service Listener and EJB layers are referred to as the two
transport layers of Content Engine. All client requests enter Content Engine
through one of these two transport layers.

Authentication

13

IBM FileNet Content Engine applications

Web Services
3.5 client
Web Services
4.0 client

3.X COM
compatibility layer
(CCL)

3.x Java
compatibility
layer

.NET API

JAVA API

IIOP/T3/JNP

SOAP
J2EE application server
- IBM FileNet Content Engine application
Web Container
Web Services listener layer

EJB Container
EJB layer

Resource Adapter
IBM FileNet Content Engine Core

Directory
server

GCD DB

Object store 1
DB

Object store 2
DB

Content Engine and some types of client applications.

Process Engine authentication architecture
Process Engine delegates authentication operations to Content Engine. This
arrangement is discussed in further detail in Process Engine
Authentication.

JAVA-based client authentication (JAAS)

Content Engine accepts requests either through a standard Java 2 Enterprise
Edition (J2EE) EJB or through the Content Engine Web service. Clients of the
Content Engine Java API have the option of choosing to use either of these
transport layers.
One of the advantages inherent to the EJB transport layer is the ability to leverage
Java Authentication and Authorization Service (JAAS)-based authentication. The
JAAS standard provides a mechanism that allows third-party authentication or
single sign-on (SSO) solutions to be integrated with any J2EE-compliant application
such as Content Engine. If an SSO provider writes a JAAS Login Module for a
given application server, then clients of applications hosted in that application
server can leverage that SSO solution.

14

Security Extract

The way that JAAS-based authentication is used can differ in different client and
server scenarios.
Browser-based clients of J2EE application servers
J2EE thick Java client on page 17
Support for Content Engine 3.5 Java API clients on page 18
Support for Java applets on page 18

Browser-based clients of J2EE application servers

Browser-based clients of J2EE-based application servers interact with servlets and
JavaServer Pages (JSPs). To access a IBM FileNet P8 server, J2EE servlet-based
applications must obtain a JAAS Subject that is valid in the J2EE EJB container that
hosts the Content Engine EJB. There are two paradigms that can be used to obtain
this JAAS Subject: application-managed authentication and container-managed
authentication.
Application-managed authentication
A servlet can make JAAS calls to perform its own JAAS login
programmatically (see JAAS Overview). This approach can involve
application-server-specific idiosyncrasies and configuration issues, but it is
fairly standardized for the common user name and password case. To use
application-managed authentication, each servlet deployed in the container
must include logic that determines whether the user is authenticated. If the
caller is authenticated, then its identity is determined by examining
information in the user's session. Each servlet must perform some action
(such as redirecting an unauthenticated user to a login page) that collects
and verifies the user's credentials, handles errors, and manages the
encoding of the authenticated identity into the user's session.
Container-managed authentication
One of a standard set of servlet authentication options can be specified in
the Web application's deployment descriptor. In this case, the servlet
container performs the JAAS login, based on the credentials that are
supplied, relieving the application of this burden.
Each Web application deployed in a servlet container can specify one of
the following options, as defined in the servlet specification, that the
container should use to authenticate users:
v HTTP Basic Authentication (BASIC): The container requests the client
browser to prompt the user for a user name and password, using a
browser-specific dialog box. This option is defined by the HTTP
specification. The user-supplied credentials are sent to the server for
authentication. A secure transport must be used, as credentials are
unencrypted. Few applications use this method, since the application's
look and feel are not preserved, and the login prompt cannot be
integrated into the application in a cohesive presentation.
v HTTP Digest Authentication (DIGEST): Like HTTP Basic, but a digest (a
one-way hash) of the password is sent instead of the password. This
option is somewhat more secure, as the actual password is not
compromised, but requires that the authentication mechanism that
manages identities accept the password hash in a particular form, rather
than the actual password. This is not possible in most real-world cases.
v Forms-Based Authentication (FORM): Instead of asking the client
browser to prompt for user name and password, the caller is redirected
to an application-specific form to provide this information. This option
Authentication

15

allows customization of the look and feel of the login page and any
error pages. It also requires a secure transport to protect the password.
This option is the default for both Workplace and Workplace XT logins.
v HTTPS Client Authentication (CLIENT-CERT): This option requires each
user to have a unique Public Key Certificate (PKC), and requires the use
of an HTTPS (SSL) connection between the client and the server.
Note that while all four of the options above can be executed over an
HTTPS connection (and, in fact that is a recommended best practice), only
CLIENT-CERT actually requires an HTTPS connection. SSL is engaged
through the configuration in the servlet descriptor of <transportguarantee> as CONFIDENTIAL or INTEGRAL.
All of these technologies are forms of container-managed authentication,
where the J2EE servlet container performs the JAAS authentication based
on credentials obtained by a standard mechanism. The specification of one
of these authentication mechanisms is a standard part of a servlet
deployment descriptor. The specification and configuration of how the
J2EE application server validates these credentials, however, is
application-server-dependent. In an enterprise environment, an
authentication mechanism must be provided to validate credentials against
the enterprise identity management solution (either a directory service or
SSO solution).
Once a caller has been authenticated by a J2EE servlet container, if the
servlet subsequently calls an EJB, the Servlet Container is required to
propagate the caller's identity (JAAS Subject) to the EJB. The diagram
below illustrates the container-managed authentication case, using
forms-based authentication to authenticate the caller against Active
Directory:
IBM FileNet
Content Engine
Server

J2EE web container

Web application WAR

Servlet descriptor (web.xml)

1
7

Client
User session

Servlet
implementation

JAAS login
module

Directory service

Container-managed authentication, using a forms-based authentication

option.
The following steps occur in this graphic:
1. A user attempts to access a servlet-based application.
2. The J2EE application server redirects the user to a page that challenges
for credentials.
3. The user enters credentials and submits them to the server.
4. The J2EE server validates the user's credentials via JAAS.

16

Security Extract

5. The J2EE server creates JAAS Principal and Subject objects using the
Active Directory JAAS Login Module, and places them in the user's
session.
6. The J2EE server redirects the user back to the application page that was
originally requested.
7. The servlet container looks for a user principal value available on the
incoming request.
8. Once invoked, the servlet makes a call to Content Engine, and the
user's JAAS Subject is propagated to Content Engine's EJB container.
Perimeter authentication
In perimeter mode, the authentication process occurs outside of the Web
container. An entity outside of the application server collects the users'
credentials, validates them through proprietary mechanisms, and sends
them onto the server in the form of an HTTP cookie. This is the
mechanism used by SSO solutions to integrate with a J2EE Web
application. Several examples of this mode are discussed in Single sign-on
via JAAS.
The basic pattern is that a third-party proxy server intercepts the Web
server requests and authenticates them using proprietary technology. A
proprietary HTTP header is then added to the request (an SM-Session
token in the Netegrity case, or an LTPA token in the Tivoli Access Manager
case). When the request arrives at the Web server, the servlet container
intercepts it, detects that it contains an SSO cookie, extracts the cookie, and
invokes the SSO provider logic to perform a JAAS login, using SSO specific
Login Modules, converting the contents of the cookie into a valid JAAS
subject.
Perimeter authentication is considered as a form of container-managed
authentication, even though authentication occurs outside of the container.
Perimeter authentication is configured by selecting CLIENT-CERT as the
container-managed authentication mechanism, and then performing some
additional SSO provider-specific steps. The Web container extracts
whatever data was present in the CLIENT-CERT cookie of the incoming
request and passes it into the JAAS Login Modules that are configured for
the Web application. A JAAS Login Module for a third-party SSO vendor
can pass a proprietary token in this CLIENT-CERT field and then process
that token in a Login Module the vendor provides.
Integration with Kerberos-based authentication environments via the
Simple and Protected GSS API Negotiation Mechanism (SPNEGO)
standard is one type of perimeter authentication used by many J2EE Web
container implementations.

J2EE thick Java client

Additional challenges exist when using JAAS in a stand-alone Java client
environment. In particular, integration options with third-party SSO providers can
be limited or unavailable. In many cases, third-party JAAS Login Modules might
be provided that work well when executing within a J2EE container, but cease to
work when running in a stand-alone Java environment. The stand-alone Java
environment might not support the application-server-specific trust mechanisms
needed to produce valid JAAS subjects for the target application server.
Login Modules that allow the use of user name and password credentials from a
stand-alone client are available from the individual application server vendors. In
Authentication

17

some cases, a Login Module that allows the use of PKI certificates with two-way
SSL might also be available. Support for other authentication options in a thick
Java client environment will most likely require a custom integration. Clients of the
FileNet P8 Content EngineJava API can use a JAAS Subject that they have obtained
themselves, or pass in user name and password credentials to the API, which will
then attempt to obtain a JAAS Subject for them, using Login Modules specified in
the operative JAAS configuration.

Support for Content Engine 3.5 Java API clients

Clients using the Java Compatibility Layer can continue to provide user name and
password credentials as for the Content Engine 3.5.x Java API.
In this case, the Java Compatibility Layer will perform a JAAS login on each user's
behalf, using the Login Modules specified in the operative JAAS configuration.
Alternatively, a client can perform its own JAAS Login prior to calling the Java
Compatibility Layer. New configuration options are provided in the Java
Compatibility Layer configuration file for controlling these authentication options.

Support for Java applets

A Java applet is a utility that conforms to the interfaces defined in the java.applet
package and is designed to run as an embedded part of another application,
typically a Web browser. An applet is opened in a separate window, and can
execute independently from the parent application that opened it. Applets are
typically created to host graphically complex interactive user interfaces that would
be difficult to implement in a browser.
In the common case where an authenticated client running in a browser takes
some action that causes an applet to be opened, the applet might be able to inherit
the parent's credentials. If the applet communicates via HTTP to servlets in the
same J2EE Web container that the parent browser was communicating with, then
authentication credentials that are stored in HTTP headers received by the parent
should be accessible to the applet, and the applet should not require further
authentication.
If, however, the applet uses other APIs to connect to the server, or if the applet
communicates with different servers than the parent application, propagating the
caller's identity might require custom development, or a second authentication
might be required for the applet.
Workplace application on page 33 discussed the use of reverse proxy servers in
perimeter authentication scenarios. The reverse proxy server acts as an
intermediary between the browser-based client and the HTTP server. It appears to
the browser that the reverse proxy is the server. The browser does not know that
the reverse proxy is actually translating the requests and forwarding them on to
another server, and then translating the responses that are sent back.
To make it appear that the reverse proxy is the actual server, the reverse proxy
must translate the responses from the server so that any references to the target
server are converted to references to the reverse proxy server. This primarily affects
embedded URL's. Web pages often contain many links to other pages hosted in the
same Web site. The reverse proxy must translate these references so that they
appear to reference the same resource, when in fact they are hosted on the reverse
proxy server rather than the target server.

18

Security Extract

Reverse proxy servers are designed to handle traffic from browser-based clients,
and typically translate any references that appear in HTML data correctly. There
are a number of special considerations that come into play when applet traffic is
sent through a reverse proxy server:
Handling Cookies
Cookies are data sent between a client and a server via HTTP headers. In a
reverse proxy scenario, the reverse proxy can interject its own cookies into
the data sent to the server, as well as adding to and translating the set of
cookies that are returned from the server to the client. The applet must not
cache cookies in memory; it must obtain them from the HTTP connection
every time it needs to access them so that it can obtain the latest set of
translated cookies sent by the reverse proxy.
Handling Redirects
If a reverse proxy detects stale or invalid authentication tokens in the
cookies sent from a client, it can use an HTTP re-direct to cause the client
to refresh its cookies. The applet must handle HTTP re-directs properly.
Translating URL's embedded in XML or other non-HTML data
Applets typically send non-HTML data back and forth with the server. If
the data returned from the server contains embedded URL's, the reverse
proxy server must translate these. Causing this to happen might require
changes in the proxy server, to have it translate data in fields which it
would not normally examine.

Single sign-on integrations via JAAS

The implementation of the FileNet P8 Content Engine server as a Java 2
Enterprise Edition (J2EE) application allows it to take advantage of integrations
between the J2EE application-server vendors and the leading single sign-on (SSO)
solution providers such as IBM's Tivoli Access Manager and CA/Netegrity's
SiteMinder. These are the two solutions that are currently qualified for end-to-end
FileNet P8 deployments.
If an SSO vendor has provided Java Authentication and Authorization Service
(JAAS) Login Modules that work with a given application server, then the FileNet
P8 Content Engine can support that single sign-on solution for custom Java-based
applications. Support for SSO solutions in end-to-end environments using the P8
Application Engine is only supported for combinations that have been qualified by
IBM. See the IBM Filenet P8 Hardware and Software Requirements for a list of
qualified solutions. Also see Single Sign-On Solutions for IBM FileNet p8 at
ibm.com/redbooks for SSO configuration information.
Note the following limitations to integrating with SSO providers:
v JAAS-based SSO integration is available only to J2EE-based clients (clients who
are able to perform a JAAS login). This type of client includes most of those that
are browser-based and work with a J2EE-based presentation-tier server.
v JAAS-based SSO integration generally does not extend to .NET-based clients or
pure Web-services-based clients.
v JAAS-based SSO integration is generally available only if the client's J2EE
environment is supplied by the same application-server vendor hosting the
Content Engine application.
v The configuration of SSO solutions generally requires a high level of
product-specific expertise. Before installing a FileNet P8 solution, customers
must work with their SSO and J2EE application server vendors to correctly
Authentication

19

configure the single sign-on environment. The industry-leading SSO products

have been designed to be highly flexible, supporting a wide range of credential
types and configuration options. FileNet is only able to test a limited number of
the infinite possible combinations of SSO vendor product configurations and
application servers.
v In all cases, the third-party SSO product must be configured to work with the
same underlying directory service (for example, Microsoft Active Directory and
Novell e-Directory) used to resolve user and group credentials within FileNet
P8.
The topics below discuss two leading single sign-on products with which IBM
FileNet P8 has done proof-of-concept integrations. Each of these products has
configuration manuals that are literally thousands of pages in length, supporting
many different credential types and authentication scenarios. The configurations
presented below are intended to represent mere samples of what can be done.
CA/Netegrity SiteMinder Web Agent
The example presented in this topic focuses on one common Netegrity
integration scenario. A browser-based client can authenticate through
SiteMinder when HTTP requests are intercepted by a reverse proxy server
running Netegrity's Site Minder Web Agent. In this scenario, a presentation
layer application is hosted in a J2EE servlet or JavaServer Pages (JSP)
environment. The clients think that they are accessing this application
directly, but network access has actually been configured to flow through a
reverse proxy server, which performs the authentication using a custom
login page or some other mechanism.
Once the client is authenticated, all further requests will carry a SiteMinder
SMSession token as an HTTP cookie. A SiteMinder Application Server
Agent on the Web server extracts the SMSession token and performs a
JAAS login on the client's behalf. The Web server can then make calls to
Content Engine. The JAAS Subject is propagated with each call. The
diagram below illustrates the steps that occur in this scenario.
Remember: This example uses Netegrity products (for example,
SiteMinder Application Server Agent Identity Asserter) which are specific
to the WebLogic platform. Different components and product names would
apply and the steps would be different if a different J2EE application
server were in use.

20

Security Extract

IBM FileNet Application

Engine/Web Server

Proxy Server
Request with
session

Web Container

Client Response

Proxy Server

18

14

Response

17

Request
10
with
2
session Login with
Prompt for
session
credentials
Netegrity
3
Credentials SiteMinder
Web Agent
11 Validate
7
session
Session cookie

JSP/Servlet
16

Request

13

Validate credentials

Subject

EJB
return

SiteMinder ASA
Identity Asserter

SMS Session token

6

EJB
call

12

SiteMinder
Policy Server

IBM FileNet
Content Engine
Server
EJB Container
Content
Engine
EJBs

Content
Engine
Core

Credentials
5

Validate user

15

Enterprise
Directory

Group
membership

HTTP requests intercepted by a reverse proxy server running Netegrity.

The following steps occur in this example:

1. The user issues a request for a Web page to the reverse proxy server. The first
component to process this request is the SiteMinder Web Agent.
2. If the request does not contain a session token, the user is redirected to a
custom login page, and prompted for credentials.
3. The user enters credentials, which are received by the Web Agent.
4. The SiteMinder Web Agent forwards the credentials to the SiteMinder Policy
Server.
5. The SiteMinder Policy Server validates the credentials by retrieving user
information from the user directory.
6. After the user is authenticated, the SiteMinder Policy Server returns a session
token to the SiteMinder Web Agent.
7. The SiteMinder Web Agent saves the session token as a cookie on the user's
machine.
8. The SiteMinder Web Agent adds to the request an HTTP header holding the
session token and forwards the request to the reverse proxy server.
9. The reverse proxy server forwards the request to the JSP/servlet running on
the application server.
10. The J2EE Web container hosting the JSP/servlet extracts the session token
from the HTTP header and performs a JAAS login. JAAS authenticates the
user by passing the session token to the SiteMinder ASA (Application Server
Agent) Identity Asserter configured on the P8 Application Engine server.
11. The SiteMinder ASA Identity Asserter forwards the session token to the
SiteMinder Policy Server.
12. If the SiteMinder Policy Server determines the session token is valid, it returns
user information to the SiteMinder Identity Asserter.
13. The SiteMinder Identity Asserter adds principals to a JAAS Subject and
returns it to the Web server.
14. The JSP/servlet calls the P8 Content Engine EJB on the P8 Content Engine
server. The Web container propagates the JAAS Subject to the EJB container.

Authentication

21

The EJB container hosting the P8 Content Engine trusts this JAAS subject,
because it has a trust relationship established with the J2EE application server
hosting the P8 Application Engine.
15. To perform authorization, Content Engine retrieves user and group
information from the user directory.
16. The Content Engine EJB returns to the JSP/servlet.
17. The JSP or servlet builds an HTTP response and returns it to the proxy server.
18. The proxy server returns the response to the client.
When applets are used as a part of the client application, then the considerations
in Support for Java applets on page 18 must be taken into account to ensure that
the applet behaves properly in the Netegrity environment.
WebSeal from IBM Tivoli Access Manager (TAM)
In the example presented in this topic, a browser-based client that has
performed a login to a Windows domain in an Active Directory
environment, uses an Internet Explorer (IE) browser to access a servlet or
JSP page through an IBM WebSeal proxy. The JSP page calls Content
Engine through the Content Engine Java API, over the EJB transport. This
use case describes the use of Kerberos credentials and Windows integrated
login to authenticate to WebSeal. Note, however, that any other
browser-based authentication mechanism supported by WebSeal (for
example, HTTP Basic or Forms-based authentication) will work just as
well. The Windows Integrated Logon case below requires the use of Active
Directory and the Microsoft Internet Explorer browser. Other
browser-based scenarios, such as a forms-based authentication scenario,
will work with other browsers and other directory services.
Request
for JSP page

Client
3

WebSeal
Proxy Server
2

Reply: Denied
- Use SPNEGO

Request for JSP

page with SPNEGO
credentials

Customer JSP
Application

Web Container
IBM FileNet
Content Engine
WS Listener

9
7

Return
TAM credential

Obtain Kerberos
Ticket For Server 1

Web Container

Perform JAAS
Logon Against TAM

Validate
ticket 6

Logon to
Windows Domain

Request for
JSP page
8
(forwarded with
TAM cookie)

10

Call to
customer EJB
Call to IBM FileNet
Content Engine 11

EJB Container
IBM FileNet
Content Engine
EJB(s)

EJB Container
Active
Directory
(KDC)

6a

Validate Ticket

Customer EJB

IBM FileNet
Content Engine

Tivoli Access Manager

Proxy Server

IE-based client in a Windows domain accesses a servlet or JSP page through an IBM WebSeal proxy.

The following steps occur in this graphic:

1. The client logs on to a Windows machine via an integrated login. The
client provides user name and password credentials which are
validated against Active Directory. The Microsoft Active Directory
server also serves as a Kerberos Key Distribution Center (KDC). A
Kerberos ticket granting ticket is issued.
2. The client uses a Microsoft Internet Explorer browser to access a JSP
page.
3. Transparently to the client, the JSP request goes through a WebSeal
proxy. WebSeal detects that the target Web site or Web page is a

22

Security Extract

protected resource, and that the client is unauthenticated. WebSeal

returns an HTTP Error response, with an HTTP header indicating that
SPNEGO credentials are accepted. (Integrations with Kerberos-based
authentication environments via the Simple and Protected GSS API
Negotiation Mechanism (SPNEGO) standard are one type of perimeter
authentication that is supported by many J2EE Web container
implementations.)
4. Internet Explorer makes Kerberos calls to the KDC on the client's
behalf, to obtain a Kerberos service ticket for the target resource.
5. The Kerberos ticket is placed into an HTTP header, per the SPNEGO
specification, and the original request is resent with this header.
6. The WebSeal proxy again intercepts the request. This time it makes a
call to Tivoli Access Manager (TAM) to validate the client's credentials.
7. TAM validates the Kerberos ticket and authenticates the caller. A TAM
credential (an LTPA token) is returned to WebSeal.
8. WebSeal modifies the original HTTP request header to include a
trusted server credential together with the TAM credential of the client
and forwards the request to the target server.
9. On the WebSphere server hosting the JSP page, the request is
intercepted by a TAM module: a Trust Association Interceptor (TAI).
The trusted server is verified, the TAM credential is extracted from the
request, and a JAAS login is performed on the client's behalf, using
the TAM credential. A JAAS Subject is obtained for the client.
10. The JSP page calls a custom EJB in the same J2EE application (this
step is not necessary in this scenario, and could be omitted.)
11. The custom EJB calls Content Engine, through the Content Engine
Java API, and over the EJB transport. The client's JAAS Subject is
automatically propagated to the Content Engine server.
In this case, there is no client application code (the client is simply a
browser accessing a Web page), nor is there any explicit authentication
logic in the customer's JSP or EJB layers. WebSeal takes care of verifying
the user's Kerberos credentials and generating a TAM credential based on
them. TAM authentication modules on the WebSphere application server
perform the JAAS login.
For more information about Tivoli Access Manager and related products,
and how they might be used in a given customer environment, contact
your service representative.
When applets are used as a part of the client application, then the
considerations in Applets and reverse proxy servers must be taken into
account, to ensure that the applet behaves properly in the WebSeal
environment.

Web-Services-based client authentication via Ws-Security

Two WS-Security profiles, the Username Token profile and the Kerberos profile, are
supported by FileNet P8. Support for additional standard profiles, as well as
non-standard WS-Security compliant approaches, can be integrated with FileNet P8
Web services, using the FileNet P8 Web Service Extensible Authentication
Framework.

Authentication

23

Clients of a Web service must produce WS-Security compliant headers to use any
of the FileNet P8 Web services. Most Web service-based applications are created
using a toolkit, such as Microsoft's Visual Studio, which handles the creation of
WS-Security compliant headers.
Username token credentials
Kerberos Credentials on page 25
Web Service extensible authentication framework on page 27
SAML credentials on page 29
Java-based clients over the Web service transport on page 29

Username token credentials

User name and password-based credentials can be passed in a WS-Security header
The Web Services Security Username Token Profile (available from
http://docs.oasis-open.org) specifies how user name and password-based
credentials can be passed in a WS-Security header. All Web service clients that
adhere to this profile should be able to interact with any Web service that
implements the profile. The XML <wsse:UsernameToken> and <wsse:PasswordToken>
elements are defined, along with rules for how these fields must be used.
When Username tokens are sent in a WS-Security header, a secure, private channel,
such as an HTTPS connection, must be used between the client and the server to
prevent compromising the client's password. Two types of passwords are defined
by this standard: a text password and a password digest. FileNet P8 supports only
the text password option.
There are two optional elements that can be included in a Username token as
counter measures against replay attacks: the nonce and creation timestamp fields.
v A nonce is a random value that the sender creates with each request. The server
maintains a cache of recent nonces, and will reject any request that arrives with
a nonce that has already been seen.
v The creation timestamp is used by the server to reject requests that are older
than some configured time period.
Use of both of these fields is recommended, but not required, for all Web service
implementations.
An example of a WS-Security header containing a Username token is shown below
(some of the namespace values have been truncated, for the sake of brevity):
<wsse:Security
soap:mustUnderstand="1">
<wsu:Timestamp
wsu:Id="Timestamp-3290b465-8a4a-4e34-b5da-1e35d80d613b">
<wsu:Created>2005-11-17T19:24:15Z</wsu:Created>
<wsu:Expires>2005-11-17T19:29:15Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken xmlns:wsu="..."
Id="SecurityToken-84353116-ed06-4a1a-b896-19337481c488">
<wsse:Username> MyUsername
</wsse:Username>
<wsse:Password
Type="...#PasswordText"> MyPassword
</wsse:Password>

24

Security Extract

<wsse:Nonce>QkzWRIL2COP9D4ELX4LyZQ==</wsse:Nonce>
<wsu:Created>2005-11-17T19:24:15Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>

When a Web service request containing a Username token arrives at a Content

Engine Web service, the Web service listener extracts the credentials from the
WS-Security header, and uses them to perform a Java Authentication and
Authorization Service (JAAS) login using an application-server-specific user name
and password Login Module. Once the JAAS login has successfully completed, the
FileNet P8 Web service listener is now in possession of a JAAS Subject, and can
pass the call along to Content Engine via the Enterprise Java Beans (EJB) transport.

Kerberos Credentials
In a Kerberos environment, clients obtain tickets that grant them access to interact
with a particular server for a particular period of time. Servers are able to verify
the validity of these tickets and of the user's identity. Symmetric encryption is used
to secure the tickets and keys that are exchanged in a Kerberos environment.
The Web Services Security Kerberos Token Profile (available from http://www.oasisopen.org) specifies how Kerberos-based credentials can be passed in a WS-Security
header.
Kerberos overview
A Kerberos environment requires the presence of one or more Kerberos
Key Distribution Centers (KDCs). A KDC generates the encryption keys
and tickets that are used in the environment. The next graphic illustrates
the exchanges that occur in a typical Windows Kerberos-based
client/server interaction (a UNIX Kerberos interaction would be
conceptually identical):
IBM FileNet Content Engine Server 1
Client

Web Container

Send IBM FileNet

Content Engine Web
Service Request
Logon to
Windows Domain
Return Ticket
Granting Ticket
Request Service
Ticket For Server1
Return Service
Ticket For Server1

Directory
Services

IBM FileNet
Content Engine
WS Listener

6
1

Perform JAAS logon

with Kerberos LoginModule
7

Kerberos JAAS
LoginModule

Return
JAAS
Subject

Call EJB with JAAS Subject 8

4

Kerberos
KDC

EJB container
IBM FileNet Content Engine EJB(s)

IBM FileNet Content Engine Core

Kerberos KDC generates encryption keys and tickets that are passed to the Web services listener

The following steps occur in this graphic:

1. For authentication purposes, the client logs in to the Windows domain.
The operating system collects the user's name and password and sends
them to a KDC.
2. The KDC works with a directory service to validate the user's
credentials and returns a ticket-granting ticket (TGT) to the caller.
Authentication

25

3. Because the client wishes to access a particular server, a ticket-granting

exchange must occur. The client sends a second request to the KDC,
specifying the service that it wishes to access. (Note that if the client
had previously been granted a service ticket and it has not yet expired,
then steps 3 and 4 would be skipped).
4. The KDC issues a service ticket, which grants the caller access to that
service.
5. The client sends its request with the service ticket encoded in a
WS-Security Kerberos token to the server.
6. The Web service listener on the Content Engine server performs a JAAS
login using credentials supplied in the incoming WS-Security header.
7. The JAAS LoginModule validates the client's ticket. No roundtrip to the
KDC is necessary. The server is able to use its own key (obtained from
the KDC at startup time) to validate service tickets. The LoginModule
produces a valid JAAS subject, based on the successful validation of the
ticket. This JAAS subject is returned to the Content Engine Web service
listener.
8. The Content Engine Web service listener passes the call along (with
valid JAAS subject) to the Content Engine EJB layer.
When Kerberos tokens are sent in a WS-Security header, a secure, private
channel, such as an HTTPS (SSL) connection, is not required between the
client and the server, as the tickets sent in a Kerberos request are already
encrypted. (Customers can use an HTTPS connection anyway to ensure
privacy for information contained in the request and response bodies.)
Microsoft's use of Kerberos
Starting with Windows 2000, Microsoft embraced the Kerberos standard,
and based the Windows authentication process on it. A Windows domain
controller acts as a Kerberos KDC, and a Windows domain is equivalent to
a Kerberos realm. Microsoft's use of Kerberos to authenticate Windows
clients improved Windows scalability, and allowed interoperability with
other non-Windows clients.
However, Microsoft's Kerberos implementation is not entirely compatible
with the MIT implementations. Microsoft has made minor changes to the
protocol that have introduced compatibility issues. With some work and
some caveats, however, Windows and UNIX Kerberos clients can be made
to interact.
Kerberos forms the basis for the "Windows Integrated Logon" capability
that allows a Windows client to log in to the network and access network
resources across the Windows domain (and in some cases, in other
Windows domains).
Microsoft provides a Web services development toolkit called Web Services
Extensions (WSE) for creating Web service-enabled client and server
applications. WSE supports the use of Kerberos credentials, obtained from
the client's environment, to generate WS-Security-compliant Kerberos
tickets. FileNet P8 supports the use of these tickets in FileNet P8 Web
services, allowing Windows clients who have logged onto the domain to
access FileNet P8 Web services without providing any additional
credentials.
Through use of Kerberos tokens, Web service client applications can be
developed allowing single sign-on with FileNet P8 Web services in a
Windows Integrated Logon environment.

26

Security Extract

Sample Kerberos token

Kerberos tokens are encoded in a WS-Security header using the standard
<wsse:BinarySecurityToken> element. The Kerberos Token Profile defines
how each of the attributes within this token must be set when sending
Kerberos tokens. An example of a WS-Security header containing a
Kerberos token is shown below (some of the namespace values have been
truncated):
<wsse:Security soap:mustUnderstand="1">
<wsu:Timestamp
wsu:Id="Timestamp-a475236f-c2c8-4c37-a280-f6ae043b09dd">
<wsu:Created>2005-04-09T00:17:53Z</wsu:Created>
<wsu:Expires>2005-04-09T00:22:53Z</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken
ValueType ="wsse.Kerberosv5ST"
EncodingType="wsse.Base64Binary"
xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-3b4344fc-374f-4e71-9d1c-e6a356a62f6b">YYID
... pPZt
</wsse:BinarySecurityToken>
</wsse:Security>

For information on the ValueType and EncodingType values, see the

WS-Security specification.
When a Web service request containing a Kerberos token arrives at a
FileNet P8 Content Engine Web service, the Web service listener extracts
the token from the WS-Security header, and uses it to perform a JAAS
login using a FileNet P8-provided, application server specific Kerberos
Login Module. Once the JAAS login has completed successfully, the
FileNet P8 Web service listener is now in possession of a JAAS Subject, and
can pass the call along to Content Engine via the EJB transport.
See also Kerberos for Content Engine for more details on using Kerberos.

Web Service extensible authentication framework

Username and Kerberos token profiles can be used to authenticate against FileNet
P8 Web services. These are the only two credentials types built into FileNet P8 for
use over the Web services transport.
For clients that must use the Web service transport but cannot make use of one of
these two token types, FileNet P8 has provided a Web Services Extensible
Authentication Framework (WS-EAF). This framework consists simply of a set of
conventions for writing a JAAS Login Module that is able to interact with the
FileNet P8 Content Engine Web service listener to obtain the credentials that are
present in the WS-Security header of an incoming request packet. The next figure
illustrates this interaction:

Authentication

27

IBM FileNet Content Engine Web Service or .NET API client

...
<wsse:Security>
<wsse:BinarySecurityToken>
<CustomData/>
</wsse:BinarySecurityToken>
</wsse:Security>
...
J2EE application server
- IBM FileNet Content Engine application
7

Web container

JAAS login module

Web Services listener layer

2

LoginContext.Login(FileNetP8Engine, CBH);

{ Callback() }

{ CallbackHandler }

EJB container
EJB layer

Resource adapter
IBM FileNet Content Engine Core

The following steps occur in this graphic:

1. A Content Engine Web service client sends a request containing a custom set of
credentials packaged in a WS-Security header.
2. The request arrives at the Content Engine Web service listener. The Web service
listener extracts the WS-Security headers and examines them. It sees that they
do not contain one of the built-in FileNet P8 credential types, so it invokes the
FileNet P8 WS-EAF authentication mechanism. A JAAS CallbackHandler is
created and seeded with the contents of the WS-Security header.
3. A JAAS login is performed, specifying the FileNetP8Engine JAAS configuration
and the CallbackHandler created in the previous step.
4. The standard JAAS runtime looks up the login modules that are listed in the
JAAS configuration file for the FileNetP8Engine stanza and invokes each of the
listed Login Modules, passing in the CallbackHandler as a parameter.
5. The custom WS-EAF JAAS Login Module instantiates one or more standard
JAAS callbacks and passes these callbacks to the CallbackHandler's handle()
method.

28

Security Extract

6. For each callback that the client has requested, the Content Engine Web service
CallbackHandler supplies the callback with requested XML fragments from the
incoming WS-Security header, such that they can be retrieved by the custom
WS-EAF JAAS Login Module.
7. The Login Module is now in possession of the WS-Security header information,
and is able to use this information to perform its proprietary authentication
process. If the authentication is successful, then a JAAS Subject is populated
and returned.
8. The Content Engine Web service listener now has a valid JAAS Subject, and can
call the Content Engine Web service to handle the request, via the Content
Engine EJB.

SAML credentials
The Security Assertion Markup Language (SAML) is a Web services specification
that defines how to encode security assertions in XML.
FileNet P8 does not provide any explicit support for SAML tokens. However, the
Web Services Extensible Authentication Framework defined in the previous topic
can be used to build support for authenticating via SAML-based credentials within
FileNet P8 applications.

Java-based clients over the Web service transport

Java clients that use the Web service transport are able to use only Username
tokens.
Neither Kerberos nor Web Service Extensible Authentication Framework support is
available to Java-based clients over the Web service transport.

Process Engine authentication

Process Engine relies on Content Engine for authentication and directory service
access operations.
The following sections describe the steps that occur as a client of Process Engine
authenticates with Content Engine, and then sends the credentials obtained from
Content Engine to Process Engine with each request.
Authenticating the Process Engine Java API client using Content Engine EJB
Transport
The next figure shows a Process Engine Java API client in a FileNet P8
server environment. Note that both the Process Engine Java API and the
Content Engine Java API must be present on the client machine. The
Content Engine Client installation program installs the Content Engine Java
API component, and the Process Engine Client installation program installs
the Process Engine Java API. Note also that the figure assumes that the
Content Engine Java API is configured to work over the EJB transport. See
the following section for a discussion of how this will differ if the Content
Engine Web service transport is in use.
This figure represents a two-level authentication process, where the client
first authenticates with JAAS. The client then authenticates with Content
Engine, with the application server validating the JAAS credentials by
invoking one of the configured Login Modules to confirm that the client's
credentials are of a type accepted by this server and that they are valid.
This establishes the caller's identity, and provides access to FileNet P8.
Authentication

29

IBM FileNet Process Engine Client

Process Engine Application
1

Process Engine JAVA API

8

Content Engine JAVA API

JAAS

7
4

IBM FileNet Content Engine Server

IBM FileNet
Process Engine Server

Content Engine Web

Services Listener

1a

JAAS

vwBroker
VWKs
Process
Engine

Content
Engine
JAVA API

Content Engine EJB Layer

Content Engine Core

Enterprise
Directory

Process Engine client first authenticates with JAAS on the application server and then with the Content Engine
server.

The following steps occur as the Process Engine client application

initializes and then makes a call to the Process Engine server:
1. The Process Engine client performs a JAAS login, using the Login
Module configured in the client environment. This login probably
occurs before any interaction occurs with the Content Engine or Process
Engine APIs. It can happen automatically as a result of a J2EE
configuration, or the client can invoke the Login Module
programmatically.
Depending on what Login Module is in use, the Login Module can
make a call to the enterprise directory service, possibly through a proxy
or some intermediate SSO solution.
Important: In the case of legacy applications (pre-4.0.0) which pass the
user name and password to the Process Engine API, the API will
perform a JAAS login using the FileNet P8 JAAS Login Context.
2. The Process Engine Application makes a call to the Process Engine Java
API.
3. The Process Engine Java API sees that the client has not been
authenticated to FileNet P8 yet, and therefore makes a call to the
Content Engine Java API to obtain a FileNet P8 identity token.
4. The Content Engine Java API makes a call to the server. At the Content
Engine server, the call arrives at the J2EE application server's EJB
container with the caller's JAAS Subject. The application server
examines its security policy configuration, as well as how the Content
Engine EJB is configured, to determine what security policy is in place.

30

Security Extract

The application server determines whether the JAAS Subject associated

with the incoming request matches one of the authentication providers
that are configured and enabled for use with the EJB. If it does, the
application server makes a call to this authentication provider which
performs any necessary checks on the JAAS Subject (this might involve
contacting a directory service or SSO provider to validate the Subject).
If any part of this application server authentication process fails, an
appropriate error is returned to the caller (note that this would occur
before any logic within the Content Engine EJB is invoked).
5. If the incoming JAAS Subject is validated by the application server,
then the call is passed through to the Content Engine EJB, and the
JAAS Subject is available to the Content Engine EJB.
6. Within the Content Engine EJB, the Principal name is extracted from
the JAAS Subject, and searched for in the Content Engine user cache. If
not found, Content Engine calls the enterprise directory service to
expand the caller's identity information.
7. The EJB processes the incoming request. In this case, a FileNet P8
identity token is created, and returned to the caller (the Process Engine
Java API).
8. If all the above steps are successful, the Process Engine Java API now
has a FileNet P8 identity token, obtained from a Content Engine server.
The Process Engine Java API makes a call to the Process Engine server,
passing the identity token as a parameter. The Process Engine server
examines the identity token, and the signature on it is validated. If the
signature is valid, then the Process Engine server trusts that the token
and the user identified by the token are valid.
9. This optional step is unrelated to the authentication process, but will
occur in many cases. In this step, Process Engine wishes to retrieve the
detailed user information (full name, DN, e-mail address, group
memberships, etc.). It does so by calling Content Engine to retrieve the
requested user and group objects.
The FileNet P8 identity token used to convey the identity of the caller from
Content Engine back to Process Engine is protected by a pair of
cryptographic keys. One of these keys is a secret shared between the
Process Engine server and the Content Engine server, while another key is
dynamically generated for use with each token.
Authenticating the Process Engine Java API client using the Content Engine
Web service transport
Process Engine authentication through Content Engine over the Web
service transport is supported only for the user name and password case.
Alternate credential types over the Web service transport are not
supported.
The diagram for this scenario is the same as in the previous topic, with the
exception that the arrow in step 4 goes to the Web Service Listener, rather
than going to the EJB Listener. The Web Service Listener then extracts the
user's credentials from the WS-Security header, and performs a JAAS login
using a Login Module that has been configured at the server. Once that
step is complete, the Web service listener forwards the call along to the EJB
listener, and everything thereafter is the same as in the previous topic.
The Process Engine Web Service API client
The following graphic shows shows the Process Engine Web service
listener which is always co-resident with the Content Engine server.
Authentication

31

IBM FileNet Content Engine Server

Process Engine WS listener installed in
Content Engine

IBM FileNet Process Engine Client

Process Engine
Web Service-based application

Process Engine Web Service

2

Process Engine JAVA API

8
4

Content Engine JAVA API

IBM FileNet Process Engine Server
vwBroker

JAAS

Content Engine Web

Services Listener

2a

Content Engine Web

Services Authentication
Framework

2b

VWks
Content Engine EJB Listener
Process
Engine

Content Engine
Java API

Content Engine Core

Enterprise
Directory

Process Engine Web service client sends a request to the Process Engine Web service listener.

The following steps occur as Content Engine responds to a Process Engine

Web service-based application call:
1. The Process Engine client sends a Web service request to the Process
Engine Web service listener.
2. The Process Engine Web service listener obtains the JAAS subject by
using the Content Engine Web Services Authentication Framework,
which expects to find the Username and Password in the SOAP Header
based on the WS-Security UsernameToken profile.
3. The Process Engine Application makes a call to the Process Engine Java
API.
4. The Process Engine Java API sees that the client has not been
authenticated to FileNet P8 yet, and therefore makes a call to the
Content Engine Java API to obtain a FileNet P8 identity token.
5. The Content Engine Java API makes a call to the Content Engine EJB
home interface with the JAAS Subject obtained in step 2.
6. Within the Content Engine EJB, the Principal name is extracted from
the JAAS Subject and searched for in the Content Engine user cache. If
not found, Content Engine calls the enterprise directory service to
expand the caller's identity information.
7. The EJB processes the incoming request. In this case, a FileNet P8
identity token is created, and returned to the caller (the Process Engine
Java API).
8. If all the above steps are successful, the Process Engine Java API now
has a FileNet P8 identity token, obtained from a Content Engine server.
The Process Engine Java API makes a call to the Process Engine server,
passing the identity token as a parameter. The Process Engine server
examines the identity token, and the signature on it is validated. If the
signature is valid, then the Process Engine server trusts that the token
and the user identified by the token are valid.

32

Security Extract

9. This optional step is unrelated to the authentication process, but will

occur in many cases. In this step, Process Engine wishes to retrieve the
detailed user information (full name, DN, e-mail address, group
memberships, etc.). It does so by calling Content Engine to retrieve the
requested user and group objects.
Restriction: The only credential type supported for this scenario are user
name and password credentials. The Process Engine Web service does not
support the Web Services Extensible Authentication Framework (WS-EAF).

Application Engine and Workplace authentication

The Application Engine server hosts the Workplace Web application, Workplace
Java applets, Process Engine applets, and application development tools.
Application Engine is the presentation layer for both process and content. A
number of different components run on the Application Engine.
Workplace application
Workplace applets on page 34
Application Integration clients on page 35
IBM FileNet P8 Portlets clients on page 35
WebDAV clients on page 36

Workplace application
Workplace is a user Web application that provides access to the document
management and business process management capabilities of FileNet P8.
Workplace also supports extended FileNet P8 capabilities such as forms
management, records management, and portals.
Workplace is one example of a Java-based thin client solution, as described in the
section Browser-based clients of J2EE application servers. (Most of the
considerations discussed in that section apply for the Workplace application.)
Workplace is built using the Web Application Toolkit, and runs within a web
container on a Java 2 Enterprise Edition (J2EE) application server, positioning it
well to participate in the JAAS-based authentication framework of FileNet P8. The
Web Application Toolkit is an extensible framework for building web applications.
Programmers can use the toolkit to customize Workplace functionality or to build
customized web applications.
The following topics discuss how each of the high-level authentication options
discussed in Browser-based clients of J2EE application servers apply to the
Workplace application.
Application-managed authentication
Application-managed authentication (the mode supported by earlier
versions of Workplace) is basically a forms-based authentication, but the
Workplace application performs the redirection of unauthenticated user
requests to a log in page, and encodes the credentials supplied to the log
in page, in the user's JavaServer Pages (JSP) session. This mode supports
only user name and password credentials. The credentials collected from
the Application Engine custom login page are used to programmatically
perform a JAAS login. This mode is still the current default behavior of
Workplace.
Container-managed authentication
Authentication

33

In this mode, the application does not control the authentication process.
The deployment descriptor for the application specifies the security
constraints required to access application pages.
The deployment descriptor specifies the authentication method that should
be used. The following standard methods defined by the Servlet
specification are supported:
v Forms-Based Authentication: The container redirects the user to an
HTML page, where the user's credentials are collected.
v Basic Authentication: The container uses standard HTTP options to
direct the user's browser to prompt for user name and password
credentials.
v HTTPS Client Authentication: This mechanism requires each user to
have its own Public Key Certificate (PKC), and requires the use of an
HTTPS (SSL) connection between the client and the server.
Perimeter authentication
This option is how most SSO products integrate with a J2EE application
server. Client browsers running Workplace are redirected to a proxy server
that authenticates the caller, and places a token in an HTTP header for
them. When the request reaches the server, the container extracts the
credentials and invokes SSO provider software that performs a JAAS login
using them. This is known as a perimeter authentication because the actual
authentication occurs outside of the container. Clients are already
authenticated before their servlet requests arrive at the server. See
JAVA-based client authentication and the examples in Single sign-on
integrations via JAAS for more information.
Perimeter authentication lets Workplace leverage standard integrations
between the application server vendors and the SSO technology vendors.
Restriction: Support for SSO in Workplace is limited to two specific
combinations that IBM FileNet P8 has qualified, as discussed in Single
sign-on integrations via JAAS. If you are implementing SSO in an IBM
Tivoli Access Manager WebSEAL 6.0 environment, you must configure
WebSEAL for transparent junctions. For more information and
configuration details, see your IBM product documentation.

Workplace applets
The Application Engine server hosts the Workplace Web application, Workplace
Java applets, Process Engine applets, and application development tools.
Application Engine is the presentation layer for both process and content. A
number of different components run on the Application Engine. The sections below
discuss how each of these components deals with authentication and single sign-on
(SSO) integration.
The Workplace applications include the following Java applets:
v
v
v
v
v

Process Task Manager

Process Administrator
Process Configuration Console
Process Designer
Process Tracker

v Publishing Designer
v Search Designer

34

Security Extract

v
v
v
v

Image Viewer
Process Simulation Analyzer
Process Simulation Console
Process Simulation Designer

The topic Support for Java applets on page 18 discusses some of the concerns
that must be taken into consideration when using Java applets across a reverse
proxy server. The Workplace applets address these concerns in the current release.
The Workplace applets exchange XML data with the Application Engine server,
and this XML data contains URL references that are not, by default, translated
properly by reverse proxy servers. For this reason, some custom configuration
work is required to get reverse proxy servers to work properly with the applets.

Application Integration clients

The Workplace Application Integration toolkit allows third-party client applications
to integrate with Workplace. Windows-based applications, such as Microsoft Word
and Microsoft Outlook, can leverage Application Integration COM components for
this purpose. These COM components interact with the Application Integration
servlets, sending XML requests over HTTP, and receiving XML responses.
Application Integration clients are not able to participate in single sign-on solutions
(SSO) unless configured for Kerberso/SPNEGO; they are restricted to user nameand password-based authentication. Application Integration clients can co-exist
with thin client applications that participate in an SSO solution. However, a single
Application Engine plus Workplace deployment cannot simultaneously support
clients using container-managed authentication for SSO (for example,
browser-based Workplace clients coming in through a reverse proxy server), and
clients that are using application-managed authentication (such as Microsoft Office
clients using the Application Integration Toolkit). In order to support both SSO
which is setup using the container-managed option and Application Integration in
the same environment, a second copy of Application Engine plus Workplace must
be setup and deployed using the Application-Managed Authentication option to
service the Application Integration Clients via user name- and password-based
authentication.

IBM FileNet P8 Portlets clients

IBM FileNet P8 Platform includes the IBM FileNet P8 Portlets product, a portal
integration framework that provides commonly-required content and process
functionality within third-party portal products. This framework includes portlets
that provide user functionality such as authoring content, browsing features for
accessing content, and providing a view of a user's inbox.
When portlets are used within Workplace in the My Workplace page, they will
participate in the same SSO integrations as Workplace itself.
Restriction: For this scenario, Workplace must be configured for
container-managed authentication.
To support SSO solutions within a third-party portal integration, the portlets
container must first be configured for container-managed authentication. When this
configuration is in place, the IBM FileNet P8 Portlets recognize that the container
has taken care of authentication for them.

Authentication

35

In cases where links from a portlet start Workplace (configured for

container-managed authentication), an SSO infrastructure must also be in place to
propagate the SSO provider identity tokens to the container that is hosting the
application. Container-managed authentication is required to accept these tokens.

WebDAV clients
tbd
As of the current release, the WebDAV implementation has moved from Content
Engine to Application Engine. WebDAV is now implemented as a separate servlet,
residing in the same Web container as Workplace.
WebDAV is an HTTP-based API that does not present an HTML user interface to
clients. For this reason, WebDAV is not able to take advantage of forms-based
authentication schemes. In the current release, the WebDAV servlet must always be
configured for application-managed authentication, managing its own user
challenge process. The WebDAV servlet will be configured so that there is an
application-level BASIC HTTP challenge/response mechanism used to gather
WebDAV client credentials.
If Workplace is configured to use one of the supported end-to-end SSO solutions
using a reverse proxy server, then the reverse proxy server must either be
configured to pass WebDAV traffic through unmodified, or the WebDAV clients
must be configured to bypass the reverse proxy server, going directly to the
Application Engine server.
Application-managed authentication
If Application Engine is configured to use forms-based authentication (be it
container-managed forms-based authentication, the default
application-managed forms-based authentication, or a perimeter
authentication scheme using a form to collect credentials) then WebDAV
will not be able to participate in this. This will typically be the case, so the
WebDAV servlet will be required to manage its own user challenge
process. The WebDAV servlet will be configured so that there is an
application-level BASIC HTTP challenge/response mechanism used to
gather WebDAV client credentials.
Container-managed authentication
When Workplace is configured for a container-managed authentication
using a non-HTML login method, such as BASIC or CLIENT-CERT
authentication, then the WebDAV servlet can be configured as a resource
protected by this mechanism as well.
If a perimeter authentication mechanism is in place that uses a non-HTML
mechanism such as HTTP Basic authentication, then WebDAV clients can
be authenticated by that perimeter mechanism and participate in an SSO
environment.

Kerberos for Content Engine

Kerberos support is available to clients of the Content Engine Web Services API,
the Content Engine .NET API, and the Content Engine COM API. This support
includes the Enterprise Manager and Capture applications. Many third-party COM
and Web-service-based applications are also available that can take advantage of
this Kerberos support.
Introduction to Kerberos on page 37

36

Security Extract

Kerberos prerequisites on page 38

Creating the Kerberos Service Principal Name (SPN) identity on page 41
Enabling Kerberos on the application server on page 45
Using RC4-HMAC Security on page 48
KrbServiceLoginModule options on page 49
Using Kerberos on the client on page 50
Using Kerberos with a cluster of Content Engine servers on page 50
Cross-realm Kerberos authentication on page 51
Implementation on Windows 2008 R2 on page 52
Troubleshooting Kerberos on page 53

Introduction to Kerberos
Kerberos facilitates user authentication over an untrusted network of disparate
systems. Content Engine running on Windows or UNIX / Linux servers can use
Kerberos for single sign-on (SSO) authentication. This is also known as integrated
login since Content Engine takes advantage of an earlier Windows login to
securely establish a user's identity without asking the user for a password again.
There are several terms used in the rest of this section related to Kerberos:
Authenticate
To establish identity. In Kerberos, this is usually done initially by
presenting some credential, such as a password, when the client logs onto
the system. After this initial authentication, Kerberos will allow the use of
tickets and encrypted timestamp information to reliably establish the
identity.
Client An application that wishes to authenticate itself to a Service like Content
Engine. In regards to using Kerberos with Content Engine, a client might
be the FileNet P8 Enterprise Manager (EM) or applications using the
Content Engine .NET API, the Content Engine COM API or Content
Engine Web Services API.
Service
A server-based application running on a particular system (or one among
many in a cluster) that can use Kerberos authentication to verify the
identity of its clients. The Content Engine is such a service.
Key Distribution Center (KDC)
A central server known to both a Kerberos client and service that supplies
Kerberos authentication services. The KDC knows passwords for both the
client and the service and acts as an intermediary between the two. It is
responsible for issuing Kerberos tickets. In the case of using Kerberos with
Content Engine, the KDC is a Windows domain controller using Active
Directory.
Service Principal Name (SPN)
A name that identifies a particular Kerberos service that is registered by
the KDC. The client will use a SPN to identify which Kerberos service it
would like to authenticate itself to. In regards to the Content Engine, this
identifier is usually something like FNCEWS/ servername where servername
is the name of the Content Engine server system or a cluster.
Realm The users, systems, SPNs, and so on, whose security is controlled by a
KDC. For the Content Engine, this is equivalent to a Windows Active
Directory domain.
Authentication

37

Ticket Granting Ticket (TGT)

A small piece of encrypted data issued by the KDC that is given to either a
client or service after it has successfully authenticated itself to the KDC (for
example, by initially logging onto a client system or providing a service
with a cached password). A TGT may then be used to identity itself when
a client or service wishes to use some Kerberos function.
Service Ticket
A small piece of encrypted data issued by the KDC that can be used by a
client to identify itself to a particular service, like the Content Engine. This
ticket may be used many times by the client whenever it wishes to make
requests to that service, although it usually has a limited lifetime of 8 or so
hours.
Replay attack
An attempt by some bad guy to reuse parts of previous messages that
have passed over an untrusted network to falsely identify himself as some
other user. Kerberos protects itself from such attacks by encrypting
timestamp and other information with its tickets and raising an
authentication error if a particular ticket appears again with the same
timestamp.
Keytab
A key table. This is a secure table of user names and passwords that may
be used by services to identity themselves to the KDC.
Here is a quick sketch of how a client uses Kerberos to authenticate itself to a
service like Content Engine:
1. The client asks the KDC for a ticket to a service with a Service Principal Name
(SPN) using its key to encrypt parts of this request.
2. Receiving the client's request, the KDC first verifies that the request actually
came from the client and then creates the service ticket, which it passes back to
the client.
3. The client then adds this ticket, as well as some encrypted timestamp
information, to any messages it sends to the server. The client can reuse this
service ticket until it expires, typically in 8 or 10 hours.
4. When the service (for example, Content Engine) receives a message with a
ticket, it can decrypt parts of it with its own SPN key to verify the client's
identity. It also typically verifies the timestamp and other information to guard
against replay attacks.
Kerberos authentication goes far beyond this simple explanation and is too large a
subject to cover in this section. More information can be found on the Internet or
in many of the books written on Kerberos. See also the Kerberos Credentials
section of Web-Services-Based Client Authentication Via Ws-Security .

Kerberos prerequisites
Since Kerberos can be difficult to get working correctly, the first step is to make
sure that a number of prerequisites are met.
A running, non-Kerberos setup of Content Engine prerequisite
The Content Engine that you wish to configure for Kerberos authentication
must be in a working state, meaning it has already been installed and
configured (without Kerberos), and can be run successfully. You must be
able to start the FileNet P8 Enterprise Manager (EM) and log in with a
username and password.

38

Security Extract

System prerequisites
Only Windows clients can use Kerberos authentication, although either
Windows or UNIX / Linux Content Engine server systems can accept
Kerberos credentials. Windows-based Content Engine server systems must
use Windows 2003 or later. .NET clients should use Windows 2000 or later
systems. Earlier versions of Windows, such as Windows NT or Windows
98, do not support Kerberos.
Regardless of whether you use Windows or UNIX Content Engine servers
you must use Windows Active Directory as your directory service.
Domain and account prerequisites
A Windows client system needs to be in a domain (not a workgroup) and
the user needs to be logged on as some type of domain account. You must
log on using a domain account. Logging on a Windows client system as a
local account will not work.
All of the client systems should be in the same domain unless you follow
the steps described in Cross-realm Kerberos authentication.
The Content Engine server system will need network access to the Active
Directory system. A Windows server system can be a member of some
domain or may be in a Window's workgroup as long as it has access to the
Active Directory. If authenticating cross-realm, that is, when clients can
be in domains other than that of the SPN identity account's domain, then it
will be helpful if the Content Engine server system is a member of the SPN
identity account's domain (see Cross-realm Kerberos authentication).
Stand-alone .NET client prerequisites
A .NET stand-alone client needs at least .NET 1.1 and WSE 2.0 installed on
the Windows system, although .NET 2.0 and WSE 3.0 (or later) are
recommended.
Content Engine Java server prerequisites
1. Content Engine needs at least the 1.4.2 Java runtime environment
(JRE), but it is recommended that the equivalent Java Development
Kit (JDK) be installed to make use of some debugging utilities.
Although not required, the JAVA_HOME environment variable can be
set to allow the Java tools in the JDK to be accessed on Windows
systems, as in this example:
set JAVA_HOME=e:\j2sdk1.5.0_22
%JAVA_HOME%\bin\ktab

2. The Java virtual machine (JVM) requires that there be a Kerberos

configuration file specifying such values as the following:
[libdefaults]
default_realm = MYDOM.EXAMPLE.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = false
default_tgs_enctypes = des-cbc-md5 des-cbc-crc
default_tkt_enctypes = des-cbc-md5 des-cbc-crc
[realms]
MYDOM.EXAMPLE.COM = {
kdc = mydomainsys:88
admin_server = mydomainsys
default_domain = mydom.example.com
}
Authentication

39

[domain_realm]
.mydom.example.com = MYDOM.EXAMPLE.COM
mydom.example.com = MYDOM.EXAMPLE.COM

This sample uses DES encryption security. RC4-HMAC security can

also be used but will require that Content Engine be running either on
a WebSphere 6 or JBoss/WebLogic with Java 6 (or later) platform. See
Using RC4-HMAC Security on page 48.
Be careful of upper / lower case use in this file. Realm names should
always be upper case (MYDOM.EXAMPLE.COM) and Windows
domain names should always be lower case (mydom.example.com).
A sample of this file can be found at installdir\FileNet\Content
Engine\Kerberos\krb5.ini that you must edit for the particular
installation. The Kerberos realm values (equivalent to Windows
domains) should be adjusted as well as the kdc(Kerberos Key
Distribution Center, which is the Primary Domain Controller on
Windows systems) and admin_server values.
If the Content Engine server's Java Virtual Machine (JVM) is 1.5 or
below, this file should be saved on Windows systems in the
c:\winnt\krb5.ini file, even if Windows is installed in c:\WINDOWS or is
on some other drive. A 1.6 or later JVM should place this file in the
Windows system directory (e.g., c:\WINDOWS ). An alternative to using
c:\winnt\krb5.ini (or c:\WINDOWS\krb5.ini ) is to save the file
elsewhere and specify its location as an argument when starting up the
JVM, as in:
-Djava.security.krb5.config="c:/ce/config/krb/krb5.conf"

On UNIX this file should be /etc/krb5/krb5.conf and on Linux, this

file should be /etc/krb5.conf. UNIX systems may also use the
-Djava.security.krb5.config argument to specify another location.
In multiple-domain situations, the kbr5.ini (or krb5.conf ) file should
specify the SPN identity account's domain/realm and need not specify
those of the client systems. See Cross-realm Kerberos authentication .
3. Microsoft increased security in Windows 2000 SP4, Windows XP SP2
and Windows 2003 and in doing so broke Java's ability to use the
system's cached Kerberos Ticket Granting Tickets (TGTs) for integrated
logins. This can be patched by running <installdir>\FileNet\Content
Engine\Kerberos\AllowTgtSessionKey_fix_for_Krb5LoginModule.reg.
This uses RegEdit to add a new value to the Windows system registry
which will disable the new security feature. This registry edit can also
be used harmlessly on early Windows Service Packs.
Middleware, Web application servers
In general Kerberos is not supported in those cases where a .NET
stand-alone client is going through a Web application layer before going to
the Content Engine server. The problem is that the Web application layer
must typically do actions for (impersonate) any number of users. This
impersonation is possible, but doing so is beyond the scope of this topic.
The exception to this rule is that browser-based clients can use SPNEGO
authentication (which uses either Kerberos or NTLM authentication) and
connect to a Web application, which in turn calls Content Engine. This will
work because the application server itself uses Kerberos to authenticate the
user and then this identity is propagated to Content Engine using
container-managed authentication. Setup for this scenario is beyond the
scope of this topic.

40

Security Extract

Creating the Kerberos Service Principal Name (SPN) identity

A Kerberos Service Principal Name (SPN) is simply a name chosen to represent
some service (Content Engine on a particular server in our case).
The SPNs used by Content Engine should always be in one of these two forms:
FNCEWS/host_name
FNCEWS/[email protected]

The leading FNCEWS is the Content Engine service name and is needed on all its
SPNs. The other parts of the SPN show where the Content Engine server resides,
as a simple DNS name or a simple DNS name qualified with a domain. The
host_name and DOMAIN.COM must be changed according to the real name of the
Content Engine server and its real domain name.
As an example, the Content Engine server undistinguished DNS name (the host
name) might be MYCE01 and its domain might be MYDOM.EXAMPLE.COM. In
this case the two SPNs would be:
FNCEWS/myce01
FNCEWS/[email protected]

The host name should always be lower case and the domain name always upper
case. Windows systems are mostly case-insensitive but not everything is, so always
use the proper case.
The SPN identity is a Windows domain user account that has been mapped to
the SPN. This special user account has a password and from that the Key
Distribution Center (KDC) derives a key, which will be used to encrypt parts of the
Kerberos ticket. This key is a shared secret that is known only to the KDC, which
issues Kerberos tickets, and to the service itself (Content Engine in this case).
How does the client know what the SPN is? In the case of Enterprise Manager, it
derives this from the URL it uses to connect to the Content Engine server. If that
URL is, for instance, http://mysvr:9080/wsi/FNCEWS40SOAP, it uses an SPN of
FNCEWS/mysvr. If the URL is, http://mysrv.mydom.example.com:9080/wsi/
FNCEWS40SOAP, it uses FNCEWS/[email protected]. Other
clients use a simple algorithm like this or directly specify the SPN.
How does the KDC know about the SPN and how does it know what key to use
with that? The answer, with a Windows KDC, is that there must be one domain
user account set up (with some password, of course), this "identity" user account
must be specifically mapped to one or more SPNs, and that account provides the
key. The KDC is referred to on Windows systems as a Domain Controller.
How does the Content Engine server know what its SPN is? It actually does not
need to know this, but it can figure out the name of the identity user account by
using FNCEWS_ + host_name (for example, FNCEWS_myce01 for our example
Content Engine server named MYCE01). If some other identity user account name
must be used for some reason, as it would if this server was a member of a cluster
or if the system name is long, the name can be directly specified by the
serviceAccountName option (see KrbServiceLoginModule Options and Using
Kerberos with a Cluster of Content Engine Servers).
How does the Content Engine server know what key to use for decrypting its part
of a Kerberos ticket? It does this by logging on to the identity user account by
using the password stored in a keytab, a special Kerberos table of users and their
Authentication

41

passwords. This special login gets the Kerberos Ticket Granting Ticket (TGT),
which in turn gives the server access to its key.
The following steps of making an SPN Identity are not trivial, partly because
Windows allows Kerberos interoperability with Java and UNIX, but has never tried
to make it user friendly.
1.
2.
3.
4.

Choosing the SPNs

Creating an Active Directory user account
Mapping the Active Directory user account to the SPN on page 43
Creating a Kerberos keytab entry for the SPN on the Content Engine system
on page 44

Choosing the SPNs

You must follow certain rules when choosing an SPN.
The SPNs should be in the form:
FNCEWS/host_name
FNCEWS/[email protected]

where you should substitute your own Content Engine name for host_name and
that server's domain for DOMAIN.COM. The host name should be an
undistinguished (in other words, no dots) DNS name and all lowercase. The
domain name should be all uppercase. In the example setup, the host name is
MYCE01 and it is in the MYDOM.EXAMPLE.COM domain, so the two SPNs
would be FNCEWS/myce01 and FNCEWS/[email protected].
If this is a cluster, set host_name to the cluster name (see Using Kerberos with a
cluster of Content Engine servers on page 50).
Case matters when choosing the SPNs! Make sure the host name is lowercase and
the domain name is uppercase.
The SPNs that might be set up for SPNEGO (for example HTTP/myce01) are not
compatible with the SPNs used by Content Engine's Kerberos. SPNEGO is a
different service than the Content Engine's Kerberos service and hence needs a
different name. Also, Content Engine's Kerberos service names always start with
FNCEWS/ and this is not customizable, although the related Kerberos identity
account name that usually starts with FNCEWS_can be customized.

Creating an Active Directory user account

Create an AD domain user account that will be the identity behind the SPN.
This account will be mapped to the SPNs in the next step and, crucially, has a
password which, through some hashing, serves as a symmetric
encryption/decryption key for parts of the Kerberos tickets.
The name of this account should be FNCEWS_ + host_name and will generally be
similar to the short SPN name chosen above with an underscore ( _ ) in place of
the slash ( / ). There are two exceptions, however:
v For clusters, where host_name would be a cluster name instead.
v If the derived FNCEWS + host_name name would be longer than 20 characters,
as it would with host_names longer than 13 characters, a different shorter name
must be used.
The latter exception is because of complications on all platforms if the account's
User Principal Name (UPN) does not match the User Logon Name (pre-Windows

42

Security Extract

2000) name, which is restricted to 20 characters or less. If either of these

exceptions holds, then you must choose a 20 character or shorter unique user name
(for example, FN_long_user_name_12) and configure the Kerberos login module to
use this new name by setting the serviceAccountName option (see
KrbServiceLoginModule options on page 49). This identity user account name
is case-sensitive and should be remembered as it will be needed when creating this
account and for some later steps.
1. To create the account, open the Active Directory Users and Computers tool on
a Domain Controller in the Content Engine server's Windows domain. Create a
Windows domain user (not computer) account that will be used for the SPN.
This account must be in the same domain as that of the Content Engine system.
Enter the identity user account name, make sure that Password never expires
is selected and nothing else, and then enter a password for that account and
confirm it. Remember this password as it will be needed later.
2. Using the Active Directory Users and Computers snap-in again, select the
account you just created, right-click it and then select Properties... from the
menu. Select the Account tab and then select Use Kerberos DES encryption
types for this account(you will need to scroll down to the bottom of the
Account Options control to find this option). This sets up to use DES
encryption security with the Kerberos tickets; RC4-HMAC should not have this
option checked (see Using RC4-HMAC Security on page 48).
Note that this identity user account must not be used for purposes other than
acting as a Kerberos identity for a single Content Engine or cluster, meaning
that several Content Engine servers must not be sharing this same identity user
unless, of course, they are part of a cluster. This identity user account must also
not be the same user account that might have been set up for SPENGO
support. This latter restriction is needed because the user account set up for
SPNEGO will likely have its Active Directory UserPrincipalName attribute set
up in a way that is incompatible with the Content Engine's Kerberos.

Mapping the Active Directory user account to the SPN

After the Kerberos identity user account is created, it must be mapped to the
proper SPNs. This is done by using Microsoft's setSPN utility, which is available on
Windows 2003 Servers (and later).
1. Enter something like these two lines in a command window on a Windows
Domain Controller system:
setspn a
setspn a

FNCEWS/mycemp01 FNCEWS_mycemp01
FNCEWS/mycemp01.mydom.example.com

FNCEWS_mycemp01

If you enter these lines on a Content Engine system that is not a Windows
Domain Controller, the setSPN command appears to work but does not actually
set the SPNs correctly.
2. Substitute the SPN you have chosen and the name of the identity account just
created for mycemp01 and the domain mydom.example.com.
Note that the setspn utility uses the pre-Windows 2000 User logon name and
not the regular User logon name.
Note that another tool supplied by Microsoft, ktpass, must not be used for
mapping SPNs. Although ktpass is recommended for setting up SPNEGO
authentication with a web server, it must not be used for setting up Content
Engine's Kerberos identity user as it can modify the identity user account's
UserPrincipalName attribute in Active Directory and thus cause Content
Engine's Kerberos to fail.

Authentication

43

Creating a Kerberos keytab entry for the SPN on the Content

Engine system
Content Engine needs to have the password for the identity user account and
this is done by setting up a keytab (key table) with that information. Do this by
entering a command line to run the ktab Java utility on the Content Engine server
system. This command line varies depending on the type of the application server.
On WebSphere systems, this step needs to be done after setting up the Kerberos
kbr5.ini or kbr5.conf file and must also be redone after changing enctypes in that
file. This is needed because the WebSphere Ktab utility uses the krb5.ini file to
determine which enctype (encryption type) is used. If the kbr5.ini file does not
have the proper enctype or has not yet been created, then the keytab entry will
likely be incorrect.
1. Enter the command for your environment:
Option

Description

Windows-based WebLogic or JBoss

application servers

%JAVA_HOME%\bin\ktab a
[email protected]

Windows-based WebSphere application

servers

%JAVA_HOME%\bin\java
com.ibm.security.krb5.internal.tools.Ktab
a [email protected]

UNIX-based WebLogic or JBoss application

servers

${JAVA_HOME}/bin/ktab a
[email protected]

UNIX-based WebSphere application servers

${JAVA_HOME}/bin/java
com.ibm.security.krb5.internal.tools.Ktab
a [email protected]

2. Enter the password when prompted.

The user name is case-sensitive and must be exactly the same case in the ktab
command line as the user name defined in Windows Active Directory. For
instance, if the user account was created with the name
[email protected], then there might be mysterious,
hard-to-identify problems later if FNCEWS_MyName were used on the ktab
command. The domain name entered here in the ktab command must similarly
be upper case to avoid those mysterious problems.
Notice the underscore ( _ ) between FNCEWS and the system name. In the
above example, FNCEWS_mycemp01 is the identity account name, not the SPN,
which has a slash / delimiter instead (as in FNCEWS/mycemp01). If you
mistakenly enter the SPN, simply run ktab again using the account name. You
can clean up these mistakes by deleting bad entries using the same command
line as above, but substituting -d (delete) for the -a switch.
The ktab utility is part of the JDK distribution and this will create a file named
krb5.keytab in the logged on account's home directory. This home directory
would be something like:
Windows
c:\Documents and Settings\administrator.MYDOM\
Unix /home/username
Because the keytab contains sensitive information (encrypted passwords), you
as the administrator would probably not want to use the default keytab as
documented earlier. Instead, you could put restrictive file system permissions
on the keytab so that only a minimum number of accounts can read it. To

44

Security Extract

change the location of the keytabs, specify an extra option, -k path/mykeytab,

on the ktab command line (substituting the real path and keytab file name for
path and mykeytab).
The following are examples of -k usage for WebSphere application servers on
Windows:
%JAVA_HOME%\bin\java com.ibm.security.krb5.internal.tools.Ktab -k
c:/mypath/mykeytab -a [email protected]
or its equivalent:
%JAVA_HOME%\bin\java com.ibm.security.krb5.internal.tools.Ktab -k
FILE:c:/mypath/mykeytab -a [email protected]
The following is an example of -k usage for WebLogic or JBoss application
servers on Windows:
%JAVA_HOME%\bin\ktab -k c:/mypath/mykeytab -a
[email protected]
Moving the keytab file will also require using either the keytabPath= or
tgtLoginConfigName= option in the Content Engine's KrbServiceLoginModule
JAAS configuration, which is covered in another Kerberos topic.

Enabling Kerberos on the application server

Kerberos support is available to clients of the Content Engine Web Services API,
the Content Engine .NET API, and the Content Engine COM API. This support
includes the Enterprise Manager and Capture applications. Many third-party COM
and Web-service-based applications are also available that can take advantage of
this Kerberos support.
Enabling Kerberos on the application server (WebLogic 9.1 and later)
Enabling Kerberos on the application server (WebSphere 6.0) on page 46
Enabling Kerberos on the application server (WebSphere 6.1 and 7.0) on page
47
Enabling Kerberos on the application server (JBoss) on page 47

Enabling Kerberos on the application server (WebLogic 9.1 and

later)
To enable Kerberos under WebLogic, you must set up a special Engine Kerberos
Service Authentication Provider.
To set up the special Engine Kerberos Service Authentication Provider:
1. Copy the Engine-authenticator-wl.jar to the following location:
Option

Description

Windows

%WL_HOME%\server\lib\mbeantypes

UNIX

${WL_HOME}/server/lib/mbeantypes

This JAR file can be found in the Content Engine installation directory, such as
Program Files\FileNet\ContentEngine\Kerberos for Windows or
installdir/FileNet/ContentEngine/Kerberos for UNIX.
2. Start the WebLogic server and run the administrative console.
3. Navigate to Security > Realms > myrealm > Providers > Authenticators,
where myrealm is the default name of the security realm, which might be
different in your environment).
4. Create a new Engine Kerberos Service Authenticator and set its name to, for
example, EngineKrbAuthenticator.
Authentication

45

5.
6.
7.
8.
9.
10.
11.
12.

In the pane that follows, change the Control Flag setting to SUFFICIENT.
Click Create.
Go back to Security > Realms > myrealm > Providers > Authenticators.
Click EngineKrbAuthenticator and use the arrows to shift it above any LDAP
providers, but below the DefaultAuthenticator.
Click Apply.
Navigate back to the EngineKrbAuthenticator page and click Details or
Provider Specific.
Make any changes necessary on this page. For instance, set the Debug option.
Save the changes.

Enabling Kerberos on the application server (WebSphere 6.0)

To enable Kerberos under WebSphere 6.0, you must set up a special Engine
Kerberos Service Authentication Provider.
To set up the special Engine Kerberos Service Authentication Provider:
1. Copy the Engine-authn.jar to the following location:
Option

Description

Windows

%WAS_HOME%\lib

UNIX

${WAS_HOME}/lib

2.
3.
4.
5.
6.

This JAR file can be found in the Content Engine installation directory, such as
Program Files\FileNet\ContentEngine\Kerberos for Windows or
installdir/FileNet/ContentEngine/Kerberos for UNIX.
Start the WebSphere server and run the administrative console.
In the Security or Global Security page, click Authentication Mechanisms >
LTPA, if necessary.
Create a new Engine Kerberos Service Authenticator and set its name to, for
example, EngineKrbAuthenticator.
Enter a password and confirm it. This password will be needed by other
servers, so remember it.
Click Security > Global Security and change Active Authentication
Mechanism to LTPA.

7. In the Security or Global Security page, click JAAS Configurations >

Application Configurations.
8. Click New and enter FileNetP8KerberosService for Alias, click Apply, and
then click JAAS Login Modules.
9. Click New and in Module Classname enter:
com.filenet.engine.authentication.kerberos.login.KrbServiceLoginModule
and leave other fields as is. Then click OK.
10. If desired, add any options by clicking the new KrbServerLoginModule entry,
click Custom Properties, then New, and then enter the option name (for
example, debug) and its value (for example, true). Click OK and then click
JAAS Login Modules.
11. Click New and in Module Classname enter:
com.ibm.ws.security.server.lm.ltpaLoginModule and leave other fields as-is.
Then click OK.
12. Click New and in Module Classname enter
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule and leave
other fields as is. Then click OK.

46

Security Extract

13. Save the changes.

Enabling Kerberos on the application server (WebSphere 6.1 and

7.0)
To enable Kerberos under WebSphere 6.1 and 7.0, you must set up a special Engine
Kerberos Service Authentication Provider.
To set up the special Engine Kerberos Service Authentication Provider:
1. Copy the Engine-authn.jar to the following location:
Option

Description

Windows

%WAS_HOME%\lib

UNIX

${WAS_HOME}/lib

This JAR file can be found in the Content Engine installation directory, such as
Program Files\FileNet\ContentEngine\Kerberos for Windows or
installdir/FileNet/ContentEngine/Kerberos for UNIX.
2. Start the WebSphere server and run the administrative console.
3. In the Security > Global Security > Federated repositories > Trusted
authentication realms - inbound page, select Trust all realms (including
those external to this cell).
4. In the Security > Global Security page, click Java Authentication and
Authorization Service, to show the items underneath, then click Application
Logins.
5. Create FileNetP8KerberosService configuration in the Application Logins. If
Content Engine is configured using Configuration Manager, then a
FileNetP8KerberosService is already created, and there is no need to add this
again. Otherwise, click New and follow instruction to add
FileNetP8KerberosService login configuration.
6. Once FileNetP8KerberosService configuration is created, click
FileNetP8KerberosService, and follow the steps to add three login modules.
7. Click New and in Module Classname enter:
com.filenet.engine.authentication.kerberos.login.KrbServiceLoginModule
Leave other fields as is. Click OK
8. If desired, add any options by clicking the new KrbServerLoginModule entry,
click Custom Properties, then New, and then enter the option name (for
example, debug) and its value (for example, true). Click OK and then click
JAAS Login Modules.
9. Click New and in Module Classname enter:
com.ibm.ws.security.server.lm.ltpaLoginModule
Leave other fields as is. Click OK
10. Click New and in Module Classname enter:
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
Leave other fields as is. Click OK
11. Save the changes.

Enabling Kerberos on the application server (JBoss)

To enable Kerberos under JBoss 4.x or 5.x, you must set up a special Engine
Kerberos Service Authentication Provider.
To set up the special Engine Kerberos Service Authentication Provider:
1. Copy the Engine-authn.jar to the following location:
Authentication

47

Option

Description

Windows

%JBOSS_HOME%\server\default\lib

UNIX

${JBOSS_HOME}/server/default/lib

This JAR file can be found in the install_path\FileNet\ContentEngine\

Kerberos directory. If Configuration Manager is used, it might have already
copied the jar file to the directory.
2. Edit the %JBOSS_HOME%\server\default\config\login-config.xml file (or
${JBOSS_HOME}/server/default/config/login-config.xml on UNIX/Linux) by
adding the following lines right before the LdapExtLoginModule or
LdapLoginModule line in the FileNet stanza. Also change the flag of the
LdapExtLoginModule / LdapLoginModule line from required to sufficient if
necessary.
<!-- Kerberos login module -->
<login-module code=
"com.filenet.engine.authentication.kerberos.login.KrbServiceLoginModule"
flag="sufficient">
<module-option name =
"debug">true</module-option>
</login-module>

3. Edit the login-config.xml file again and add the following stanza after the last
of the other <application-policy> entries:
<application-policy
name="FileNetP8KerberosService"><authentication><login-module
code="com.filenet.api.authentication.jboss.login.FnClientLoginModule"
flag="required"></login-module></authentication></application-policy>

Using RC4-HMAC Security

Following previous directions, Content Engine will be set up to use 56-bit DES
encryption security. This can be changed to use the more secure 128-bit
RC4-HMAC security if your environment meets both these additional prerequisites:
v Content Engine is installed on either WebSphere 6 or later, or on JBoss or
WebLogic systems running Java 6 or later, and
v your directory service is Active Directory 2003 or later.
To use RC4-HMAC, modify the krb5.ini or kbr5.conf file and change two lines in
the following way:
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac

That is, replace the recommended des-cbc-md5 des-cbc-crc on those two lines
with rc4-hmac.
After changing this setting in your krb5.ini file, you should run (or rerun) the
step to create the keytab (rerunning ktab is not needed if you have already run
ktab on JBoss/WebLogic Java 6 or later setups, but is required if using WebSphere
or are upgrading from an earlier version of Java).
Make sure that the Kerberos identity user account you have set up does not have
Use DES encryption types for this account selected. If it is already selected, then
you must unselect it and re-enter the password.
It is not possible for the same SPN/identity user account to support both DES and
RC4-HMAC security. It must be one or the other.

48

Security Extract

KrbServiceLoginModule options
The KrbServiceLoginModule (or WebLogic Engine Kerberos Authentication
Provider) does the Kerberos service authentication on the Content Engine server.
This login module has several options that can change its behavior.
debug when true will output additional debugging information to the console,
server log, or both. The default is false. You can enable additional
debugging information when first setting up Kerberos, or afterward if
attempting to debug a problem with Kerberos authentication.
useShortNameAsPrincipal
when true will use the user's short name as the principal; if false then will
use the full Kerberos name in the form: [email protected]. The
default is false.
storeGssContext
when true will add a GSSContext as a private credential. This can be used
by the server to encrypt and sign messages between the server and the
client, but will need substantial programming on both to accomplish this.
When false, this private credential is not added. The default (and
recommended) setting is false.
loginUsingTicketSpn
if true will attempt to log in using the SPN (Service Principal Name) of the
Kerberos service ticket. The default is false, which will attempt to log in
using the normal FNCEWS_computername account name. The
recommended setting is false.
serviceAccountName
this specifies the account name that the service will use when it is logging
in. If not specified, this defaults to FNCEWS_ computername. This option
should only need to be set to some account that is shared by every server
if Content Engine is clustered or if on WebSphere systems and the default
name would be longer then 20 characters. This option is ignored if
loginUsingTicketSpn is true.
tgtLoginConfigName
this option specifies the name of a JAAS configuration that will be used
when the service initially logs in to get its Kerberos TGT (Ticket Granting
Ticket).
For example, if tgtLoginConfigName=KrbTgtLogin, then there could be a
JAAS configuration entry such as:
KrbTgtLogin {
com.sun.security.auth.module.Krb5LoginModule required
debug=true useKeyTab=true storeKey=true
keyTab="c:/etc/krb5.keytab";
};

If this is not set, the default is to use an internal configuration that is

tailored for the application server. It is recommended that this option not
be set as the default will almost always work correctly.
keytabPath
this option specifies the keytab file, which will be used for the service's
initial TGT login, and will be set like the following example:
keytabPath="file:/c:/etc/krb5.keytab"

Authentication

49

If this option is not set, then the default Java keytab will be used, which is
usually found in home/krb5.keytab. For example: C:/Documents and
Settings/mike.MYDO/krb5.keytab.
The keytabPath option needs to be used when the application server is
running as a Windows service or if the keytab is not in the default
location. This option is ignored if tgtLoginConfigName is set.
cacheSize
specifies the size of the ticket cache used on JBoss application servers. This
cache works around "request is replayed" errors that happen because of the
way that JBoss sometimes uses a Kerberos ticket twice during a normal
authentication and triggers the error on the second use. This defaults to
100 on JBoss and is ignored on other application servers. It is
recommended that this option not be set, unless running on JBoss servers
that have been getting Request is a replay errors, in which case you
could try values greater than 100.

Using Kerberos on the client

Kerberos security can be configured on the client.
To use Kerberos on the client, see Implementing Kerberos in the help topic
Developing IBM FileNet applications > Content Engine Development > Content
Engine Java and .NET Developer's Guide > Security > Working with Security.

Using Kerberos with a cluster of Content Engine servers

The SPN used for a cluster is different than that used for individual Content
Engine servers.
1. For a cluster, pick a unique SPN, say FNCEWS/cluster01, and create a single
domain user, FNCEWS_cluster01, that will be the Kerberos identity account for
that SPN. Run the setspn utility to map this SPN to this identity account by
typing:
setspn -a FNCEWS/cluster01 FNCEWS_cluster01
setspn -a FNCEWS/cluster01.mydom.example.com FNCEWS_cluster01

2. All Content Engine servers must then be set up to use this cluster-wide identity
rather than the server-name identity normally used. Do this as follows:
For WebSphere and JBoss (and other potentially supported application servers):
Add a new option, serviceAccountName=FNCEWS_cluster01 (substituting
your cluster name for cluster01) to the JAAS configuration for
KrbServiceLoginModule on each application server.
For WebLogic:
Set the Service Account Name option for the Engine Kerberos
Authentication Provider.
3. In cases where one client references a server's URL directly (recommended for
Enterprise Manager) and another client could reference the cluster URL of that
server (possible with customized .NET clients), then there must be additional
SPN mappings to the same identity account. As an example, here is what you
would enter for a cluster named cluster01 and a particular server within that
cluster, myce02 , all in domain mydom.example.com:
setspn -a FNCEWS/cluster01 FNCEWS_cluster01
setspn -a FNCEWS/cluster01.mydom.example.com FNCEWS_cluster01
setspn -a FNCEWS/myce01 FNCEWS_cluster01

50

Security Extract

setspn -a FNCEWS/myce01.mydom.example.com FNCEWS_cluster01

setspn -a FNCEWS/myce02 FNCEWS_cluster01
setspn -a FNCEWS/myce02.mydom.example.com FNCEWS_cluster01

Remember the following:

v All the SPNs must map to the same identity account (FNCEW_cluster01 in
the example above).
v All the clustered servers must have the
serviceAccountName=FNCEWS_cluster01 option set in the JAAS
configuration as previously mentioned (for example, serviceAccountName
=FNCEWS_cluster01).
v You must set up an keytab entry on each server for the identity account
name ( FNCEWS_cluster01 in the example).
Finally, it is extremely important that no single SPN be mapped to more than
one identity account. For example, the following two setspn commands, even if
they were done at different times would cause unexpected The network path
not found errors on the clients. Here is an example of a mapping you must not
do:
setspn -a FNCEWS/myce01 FNCEWS_myce01
setspn -a FNCEWS/myce01 FNCEWS_cluster01

This example has the same SPN, FNCEWS/myce01, mapped to two different
identities: FNCEWS_myce01 and FNCEWS_cluster01. Unfortunately, this can
occur innocently enough by starting with only a single Content Engine server
and later expanding to a cluster of Content Engine servers. Likewise, there is
no way to check for duplicates of this sort in Microsoft's setspn utility. See
Solving Kerberos Problems for what to do if this error condition occurs.

Cross-realm Kerberos authentication

Multiple Windows domains, where the clients are in one or more domains and the
Content Engine server is in another, can be made to work with Kerberos if you
take into account some special considerations. The first is that the domains (or
realms in Kerberos terminology) must accept the identity established in another
domain. This means that one domain trusts another.
There are three major ways that Windows systems have of establishing this
domain to domain trust:
v By creating a domain forest
v By establishing a transitive trust between two domain forests
v By establishing external trusts between sets of two domains
Domain forests were introduced in Windows 2000 Server and allow one or more
hierarchical domain trees with parent/child relationships. In the forest, the trust is
transitive in that one domain trusts another domain no matter where it is in the
forest. Windows 2003 Server went one step further and allowed transitive trusts
from one forest to another, although these inter-forest trusts are only available if
both forests have been promoted to Windows 2003 mode. External trusts
originated in Windows NT and are explicit trust links that are set up between one
domain and another that are not transitive in that if domains A and B trust each
other and domains B and C trust each other, then this does not imply that A trusts
C or C trusts A. Two-way external trusts mean that each domain trusts the other
(one-way external trusts are not supported by Kerberos).
These different type of domain to domain trusts work well with Kerberos
authentication, although each domain must have its directory configuration set up
in the GCD and the application server must have LDAP providers set up for each
Authentication

51

domain. The GCD directory configuration is done using Enterprise Manager

(right-click the P8 domain name, select Properties from the menu, click Directories
and add a new configuration for each domain).
v WebLogic security can be enabled for each domain by adding and configuring a
new Active Directory LDAP authentication provider for each.
v JBoss requires multiple LdapExtLoginModule or LdapLoginModule setups in the
FileNet JAAS stanza.
v Multiple LDAP user registries can be set with WebSphere, but only in version
6.1 and beyond. Earlier versions only support a single LDAP provider.
The second consideration for cross-domain Kerberos is that the SPNs will most
often need an @ qualifier, such as FNCEWS/
[email protected]. The shorter, unqualified SPN, like
FNCEWS/myce01, can also be used in some cases, but might have problems if the
server name myce01 is ambiguous as that name appears more than once in a forest
or if that shorter form is used with an external two-way trust or transitive
two-way trust. If the shorter SPN does not work, then the .NET client will likely
get The network path was not found error.
Enterprise Manager also needs special handling for cross-domain Kerberos
authentication as it tries to derive the SPN from the configured Content Engine
server URL. There will often be cases where the URL will need a fully qualified
domain name to get the correct SPN. For example, a Content Engine URL of
http://myce01.mydom.example.com:9080/wsi/FNCEWS40MTOM will be turned into an
SPN of FNCEWS/[email protected], which should work. A
shorter, unqualified URL such as http://myce01:9080/wsi/FNCEWS40MTOM would
produce an SPN of FNCEWS/myce01, which might not work.
Enterprise Manager's handling of fully qualified DNS names works in the case
where the Content Engine system is in the same domain as the SPN identity
account, but has problems when the Content Engine system is either in a Windows
workgroup or is a UNIX system. The problem is that the DNS name, say
myce01.mydom.example.com, will not automatically be defined as it is for systems
that are members of the mydom.example.com domain. The solution is that a DNS
entry must be manually added to map myce01.mydom.example.com to myce01's
IP address and this new DNS entry must be available to clients.
A third note is that the Active Directory domain that the SPN identity user account
is a member of is the domain/realm that should be defined in the krb5.ini (or
krb5.conf) Kerberos configuration file on the Content Engine server. It is not
necessary to configure all of the potential client domains/realms in that
configuration file.
A final note is that the client's domain from Kerberos's point of view is the domain
of the logged on user, which will not necessarily be the domain of the client
system. For instance, a client system is in domain NORTH that trusts the domain
SOUTH and the user as logged onto the system as Frank@SOUTH; in this case
Kerberos will use SOUTH as the client's domain.

Implementation on Windows 2008 R2

Implementation procedures on Windows 2008 R2 are basically the same as with
other Windows versions. However, since DES cipher by default is disabled in
Windows 2008 R2, krb5.ini file cannot use the default DES encryption type. There
are two ways to solve this problem:

52

Security Extract

v Enable DES cipher support on Windows 2008 R2. See the following technote
from Microsoft: http://technet.microsoft.com/en-us/library/
dd560670(WS.10).aspx
v Set the enctypes to rc4-hmac in Kerberos configuration file and recreate keytab
file. See Using RC4-HMAC Security on page 48.

Troubleshooting Kerberos
Troubleshooting problems with Kerberos can be complex, given the number of
computers and amount of software that can be involved.
One of the first things to try if encountering problems is to make sure that Content
Engine works first without Kerberos. The easiest way to verify this is to start the
FileNet P8 Enterprise Manager (EM) tool and log on using the admin's username
and password. If EM does not work in this simpler, username / password case,
then troubleshoot that before attempting to handle problems with Kerberos.
If it has been established that EM works with username / password, then test with
EM using its integrated logon setting. Make sure that the workstation running
EM has been logged on under Windows as a domain user and that user is also a
FileNet P8 domain administrator (gcd_admin) or object store administrator
(object_store_admin). Using EM might isolate the problem and point towards some
other problem that is outside Kerberos. If this EM login fails or there still does
appear to be a Kerberos problem, then the problems can be broken down into
whether the error seems to be generated on the client or on the Content Engine.
In most cases, the important part of the error will be near or at the end of the error
message. For instance, if the error message returned by the client was WSE594:
InitializeSecurityContext call failed with the following error message: The
network path was not found., the important part of this message is The network
path was not found.
Recovering from .NET client or Enterprise Manager problems
Recovering from Content Engine server problems on page 55

Recovering from .NET client or Enterprise Manager problems

When you work with Kerberos using .NET client or Enterprise Manager and
problems occur, you can recover from those problems.
There might be other less common problems with the client. One way to see if the
message is making it to the Content Engine server is to turn on Kerberos Service
debugging on the Content Engine server. Do this by setting debug=true in the
JAAS configuration for the KrbServiceLoginModule on WebSphere or JBoss. On
WebLogic, set the Debug option to true for the Kerberos Service Authentication
Provider. If the request is getting through to the Content Engine server, the server's
console or log will have additional debug lines for each request.
Unable to connect to the remote server - .Net client
The network path was not found on page 54
There are currently no login servers available to service the login request on
page 55
A specified login session does not exist. on page 55
Unable to connect to the remote server - .Net client:
You can recover from inability to connect to the remote server.

Authentication

53

Symptoms
Unable to connect to the remote server. No connection could be made because the
target machine actively refused it.
Resolving the problem
If you get this error, carefully check the URL, particularly the associated port
number, that you are using to connect to Content Engine. Also make sure that
Content Engine is running.
If the user is running Enterprise Manager and following the directions in the
Cross-realm Kerberos authentication section, this error can also arise if the Content
Engine system is not a member of the SPN identity user account's domain. For
example, if the Content Engine system is in a Windows workgroup or a UNIX
system and namedmyce01 and the SPN identity account is in the
mydom.example.com domain, then the URL that Enterprise Manager would need
could be something like http://myce01.mydom.example.com:9080/wsi/FNCEWS4MTOM.
This would fail because myce01 is not really in mydom.example.com domain, but that
URL needs to be that for cross-domain requirements. The solution is to manually
add myce01.mydom.example.com to the DNS used by the clients.
The network path was not found:
You can resolve errors when the network path was not found.
Symptoms
The network path was not found
Resolving the problem
This error might indicate one of several underlying problems:
1. Enterprise Manager has a bad Content Engine server URL. Enterprise Manager
calculates the Kerberos SPN by taking the host part of the URL and prefixing it
with FNCEWS/, so that, for example, a URL of http://myce01:9080/wsi/
FNCEWS40MTOM/ would yield an SPN of FNCEWS/myce01. This should match the
SPN previously set up for the server. It will also turn fully qualified domain
names like http://myce01.mydom.example.com:9080/wsi/FNCEWS40MTOM/ into an
SPN of FNCEWS/[email protected]. These derived SPNs usually work
well, but can sometimes have problems. Particularly watch out for URLs that
are not DNS names, like http://localhost:9080/wsi/FNCEWS40MTOM/ or
similarly ones using IP addresses, like http://123.45.67.89:7001/wsi/
FNCEWS40MTOM as these will yield bad SPNs.
2. The SPN is correct, but was never mapped by the setspn utility to the
corresponding identity user account, FNCEWS_myce01 in this example. Try
running setspn l FNCEWS_myce01 to list the SPNs that have been mapped to
this account. Check for misspellings, such as _ or \ instead of /.
3. The SPN was mapped to more than one identity account. One option to check
for this is to use the LDIFDE.EXE utility (part of Microsoft's Windows 2003
Server support tools) to dump the account information to a text file by issuing
a command like LDIFDE d dc=mydom,dc=example,dc=com -f mydom.txt. Then
open the mydom.txt file with a text editor and search for the SPN string,
FNCEWS/myce01 in this example. If duplicates are found, you can remove an
extra one by typing something like setspn -d FNCEWS/myce01 FNCEWS_baduser.

54

Security Extract

4. The SPN is not known in the client's domain. This situation can arise if the
client's logged-on user domain and Content Engine Windows domains are
either not the same or are not in the same Windows domain forest where the
domains implicitly trust each other. See the Cross-realm Kerberos
authentication section for a work-around for Windows domains that use
external or transitive two-way trusts.
5. The SPN had one of the above problems and was recently fixed. In this case
the .NET framework has cached the bad result and the only way to clear this is
to reboot the client system. It is a good idea to reboot the client anytime .NET
reports a The network path was not found error.
There are currently no login servers available to service the login request:
You can resolve errors when there are no login servers available to service the
login request.
Symptoms
There are currently no login servers available to service the login request
Resolving the problem
This error can sometimes be caused because of connectivity problems between the
client and domain controller systems for all involved domains. If the connectivity
seems to be okay, this error might also mean that the time servers on the client and
server are too far out of sync, particularly in cross-domain setups. Usually the
servers must have times within 5 minutes of each other, but sometimes having
them even 1 minute out of sync can cause problems.
A specified login session does not exist.:
You can resolve errors when a specified login session does not exist.
Symptoms
A specified login session does not exist. It might already have been terminated.
Resolving the problem
This could mean that the client workstation's logged-on user is a local account and
not a domain account. Kerberos requires that the logged-on user is a domain user
account.

Recovering from Content Engine server problems

When you work with Kerberos and problems occur on the Content Engine server,
you can recover from those problems.
If the Kerberos problem does not seem to be on the client, turn on Kerberos
Service debugging. Do this by setting the debug=true option in the JAAS
configuration for the KrbServiceLoginModule on WebSphere and JBoss. On
WebLogic do it by setting the Debug option to true for the Kerberos Service
Authentication Provider. What follows are a few of the more common Kerberos
problems. Some error messages will have a number, for example (9), that
represents a standard Kerberos error code. This number can appear in either the
message itself or, as is the case with WebSphere, as the minor error code for the
error.
Authentication

55

There can be many other Content Engine server Kerberos problems. If Kerberos
Service debugging is not enough to isolate the problem, try turning on additional
system debugging, which will give even more information. Content Engine
WebLogic and JBoss servers can specify the sun.security.krb5.debug property,
usually on the Java command line with -Dsun.security.krb5.debug=true. This
produces a lot of trace output on the JVM's console. There are two Java command
line switches for Content Engine WebSphere servers:
-Dcom.ibm.security.jgss.debug=all
-Dcom.ibm.security.krb5.Krb5Debug=all

which also provide extra messages in WebSphere's log.

null key (9)
Encryption errors
Password has expired - change password to reset (23) on page 57
Identity errors on page 57
Request is a replay (34) on page 58
Clock skew too great (37) on page 58
Identity user is not found in the keytab on page 58
Could not create default AuthorizationToken during propagation login on
page 59
Principal [email protected] not found on page 59
JAAS configuration FileNetP8KerberosService not found on page 60
Cannot get kdc for realm MYDOM.EXAMPLE.COM on page 60
Null key on page 60
Null name on page 61
Failure to obtain initial naming context on page 61
null key (9):
You can recover from a client or server has a null key (9) error.
Symptoms
The client or server has a null key (9)
Resolving the problem
This could indicate that the Content Engine server has not had the
AllowTgtSessionKey_fix_for_Krb5LoginModule.reg registry patch applied. This
patch is necessary on certain later service packs and versions of Windows.
Encryption errors:
You can recover from encryption or decryption errors.
Symptoms
KDC has no support for encryption type (14)
Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC
Cryptographic key type rc4-hmac not found

56

Security Extract

Cryptographic key type des-cbc-md5 not found

Cryptographic key type des-cbc-crc not found
Resolving the problem
These errors might mean that the identity domain user account does not have
the Use DES encryption types for this account option set if DES security is
desired or that it does have the option set if RC4-HMAC security is desired.
Another possibility is that the wrong ktab utility was used (for example, the Sun
ktab utility was used on a WebSphere system).
An error like this can also mean that the krb5.ini file does not have these settings
in the[libdefaults] section for DES security:
default_tgs_enctypes = des-cbc-md5 des-cbc-crc
default_tkt_enctypes = des-cbc-md5 des-cbc-crc

And similarly, for RC4-HMAC security, that the krb5.ini file does not have these
settings:
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac

Password has expired - change password to reset (23):

You can recover from password expired errors.
Symptoms
Password has expired - change password to reset (23)
Resolving the problem
The "identity" user account's password must be changed. Also remember to run the
ktab utility on the Content Engine server to change the keytab's password if
necessary.
Identity errors:
You can recover from conditions where user names and passwords are not
configured correctly.
Symptoms
Pre-authentication information was invalid (24)
Integrity check on decrypted field failed (31)
Cannot get credential for principal default service
Resolving the problem
The most likely error is that the user name and password in the keytab does not
exactly match the user name and password of the identity user account given
when creating the account. Notice that this match is case-sensitive for the user
name, the domain name (which must be uppercase in the ktab command) and the

Authentication

57

password. Try rerunning ktab and re-establishing the password paying close
attention to the upper / lower case used. Also validate the name of the identity
account and reset its password.
This could also mean that the keytab file was not found for the user account (in
the [email protected] form), but there should also be a
could not find user in keytab error prior to this.
This could mean that identity user account mapped to the SPN which the client
used does not match the user account that the Content Engine's
KrbServiceLoginModule used. A possible reason for this is that the login module's
serviceAccountName is not set to the correct identity account name (not the SPN)
for a cluster. For example, the name should be FNCEWS_ce01 and not
FNCEWS/ce01.
Another possibility is that Microsoft's ktpass utility was used to map an SPN to the
identity account. This utility changes the User logon name (also known as the
User Principal Name) field, and doing so automatically corrupts the password for
that account. The solution for this is to reset the identity account's password.
There is also the possibility that the system clocks are too far out of sync; see
Clock skew too great (37).
Request is a replay (34):
You can recover from a Request is a replay error.
Symptoms
Request is a replay (34)
Resolving the problem
This request has the same Kerberos token as an earlier request. This is probably
because a .NET client is not using CE .NET API calls and is reusing a WSE
KerberosToken/KerberosToken2 or a WCF KerberosRequestorSecurityToken object
rather than reconstructing it for each request.
Clock skew too great (37):
You can recover from a Clock skew is too great error.
Symptoms
Clock skew too great (37)
Resolving the problem
This error can happen if the clocks on the client machine and the Content Engine
server are more than some number of minutes apart. Commonly this is 5 minutes,
but can also be 1 minute. The fix for this is to more closely synchronize the clocks
on the two machines.
Identity user is not found in the keytab:

58

Security Extract

You can recover from conditions where the identity user is either not in the keytab
or the keytab file cannot be found.
Symptoms
The user could not be found in the keytab
Key for the principal FNCEWS_myce01@MYDOM. EXAMPLE.COM not available
in default key tab
No Kerberos creds in keytab for principal
[email protected]
Resolving the problem
These errors could either indicate that the "identity" user (for example,
FNCEWS_myce01@MYDOM. EXAMPLE.COM ) was not in the keytab or that the
keytab file itself could not be found. Use "ktab" by itself from the command line to
list the contents of the default keytab file and check for misspellings. The keytab
file is, by default, the c:\Documents and Settings\ user \krb5_keytab file. Where
user is the name of the account that the application server is running as. Note that
if the application server is running as a service, there will probably be no
corresponding user directory and it is best if the keytabPath="c:/my_keytab"
KrbServiceLoginModule option is used to specify what and where the keytab is.
Could not create default AuthorizationToken during propagation login:
You can recover from a Websphere authorization error.
Symptoms
Could not create default AuthorizationToken during propagation login
Resolving the problem
This is a WebSphere error that probably means that the security mechanism is set
to SWAM rather than LTPA. See Enabling Kerberos on the application server on
page 45 for how to set this up for WebSphere.
Principal [email protected] not found:
You can recover from the Principal [email protected] not found
error
Symptoms
Principal [email protected] not found
Resolving the problem
This error can occur if the GCD does not have a directory configuration for the
MYDOM.EXAMPLE.COM Active Directory. In Enterprise Manager, right-click the
name of the FileNet P8 domain and select Properties from the menu and then click
Directories.

Authentication

59

This error can also happen in a multi-domain environment if the GCD does not
have the directory configuration for a client domain set up, as each client domain
must individually have its directory configuration set up.
JAAS configuration FileNetP8KerberosService not found:
You can recover from a JAAS configuration FileNetP8KerberosService not found
error.
Symptoms
JAAS configuration FileNetP8KerberosService not found
Resolving the problem
This error will occur if the FileNetP8KerberosService JAAS configuration entry has
not yet been configured.
Cannot get kdc for realm MYDOM.EXAMPLE.COM:
You can recover from a Cannot get kdc for realm MYDOM.EXAMPLE.COM error
Symptoms
Cannot get kdc for realm MYDOM.EXAMPLE.COM
Resolving the problem
This error can happen if the kdc= line in the Content Engine krb5.ini file has not
been edited correctly to reference the primary domain controller for the
MYDOM.EXAMPLE.COM domain. Another possibility is that the Kerberos
configuration file, krb5.ini, cannot be found by Content Engine as it is either not
in the c:\winnt directory for Java 5 (or earlier) or the Windows system directory
(like C:\Windows) for Java 6 (or later); or the Djava.security.krb5.conf= setting
is wrong.
Null key:
You can recover from a null key error.
Symptoms
Null key
Resolving the problem
This error can happen on WebSphere systems if the server's SPN identity (for
example, [email protected] ) cannot be found in the Content
Engine server's currently configured keytab.
It can also happen if the keytab file itself cannot be found for some reason, such as
using the default keytab, but that keytab was created by one user and the app
server is running as another user account (a particular problem if the app server is
running as a Windows service). One fix for this is to specify the keytabPath option
for the KrbServerLoginModule, for example, keytabPath="c:/config/keytab".

60

Security Extract

Null name:
You can recover from a null name error.
Symptoms
Null name
Resolving the problem
This error will occur on WebSphere systems if the identity user name used for
Kerberos's identity account is longer than 20 characters. The default identity user
name is derived by Content Engine to be the string FNCEWS_ + host_name.
Unfortunately, this default name will be too long if host_name itself is 14 or more
characters long. If this is the case, this can be fixed by using some other name for
this identity user account and specifying that name in the serviceAccountName
option for KrbServiceLoginModule. (For example,
serviceAccountName=FN_long_host_name_123).
Another possibility, also on WebSphere servers, is that the encryption type of the
key saved in the keytab does not match the encryption type used when encrypting
the Kerberos ticket. One way for this to happen is if the identity account does
not have the Use DES encryption types for this account option set in the account's
property dialog for DES security, or it does have that option set for RC4-HMAC
security.
This problem might require setting the
Dcom.ibm.security.jgss.debug=all and
-Dcom.ibm.security.krb5.Krb5Debug=all properties on the JVM to diagnose as
described in Recovering from Content Engine server problems on page 55.
Failure to obtain initial naming context:
You can recover from failure to obtain an initial naming context.
Symptoms
Failure to obtain initial naming context
Resolving the problem
Attempting to perform a Kerberos login results in a Web services Kerberos
credential invalid error, and WebSphere Failure to obtain initial naming
context errors. These errors indicate that WebSphere did not initialize the Java
naming factory, which is required for Kerberos authentication.
1. Open the WAS admin console and expand Servers.
2. Click Application servers, click server name, then expand Java and Process
Management on the right.
3. Click Process Definition, click Java Virtual Machine and then enter the
following argument text in the Generic JVM arguments box (with a space to
separate it from other arguments, if needed):
-Djava.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory

4. Click Apply and Save.

5. Restart WebSphere.

Authentication

61

62

Security Extract

Authorization
When a security principal that has already been authenticated attempts to access
FileNet P8 objects, Content Engine or Process Engine will attempt to retrieve that
principal's user and group memberships from the directory service provider. If
successful, the user or group will be authorized to carry out actions described by
the access rights placed on the objects. The topics in this section describe
authorization: the various features used to manage security and apply security to
objects, as well as the details of security behavior
About access rights
Default security on page 68
Security for integrated components and third-party products on page 69
Mapping security levels to individual access rights on page 71
Markings on page 79
Object access rights and security on page 86
Object ownership on page 105
Property modification access on page 107
Required minimum access rights by operation on page 109
Security policies on page 112
Storage area security on page 117
Target access required on page 121
Understanding security inheritance on page 122

About access rights

IBM FileNet P8 provides a full-featured system of access rights that let you control
access to objects.
What are access rights?
ACE source: Default, Direct, Inherited, Template on page 67
ACE security levels on page 67
Allow or Deny and order of evaluation on page 68

What are access rights?

Access rights are made up primarily of Access Control Entries (ACEs) that are
organized into Access Control Lists (ACLs).
Most objects are independently securable, meaning they are secured by their own
Access Control List (ACL). An object's ACL is the collection of all the Access
Control Entries (ACEs) placed on it.
An object's access rights, also called permissions, determine which users can view
the object and what those users can do. For example, to see a folder a user needs
at least the folder's View properties permission. To add a document to the folder,
the user needs the Add to Folder permission. Access rights vary by object and
control all operations on that type of object. Documents (and only documents)
have permissions that let the user make new versions of the document, whereas
folders (and only folders) have an Add to Folder access right, and so on.

Copyright IBM Corp. 2006, 2011

63

Security identifier (SID)

Embedded into each ACE is a globally unique security identifier (SID) that
uniquely identifies a security principal, a user or group that Content
Engine grants or denies access to. The value of each SID must be:
v Unique within the configured directory server, across all configured
LDAP realms.
v Immutable. The directory server assigns a SID when it creates the user
or group, and the SID value associated with a user or group must never
change.
Most directory servers provide a built-in attribute as a stable and unique
user and group identifier. Content Engine uses these attributes as a default
to obtain and store the user or group's SID. The values are typically the
same for the user and group SID attributes, the UserUniqueIDAttribute
and GroupUniqueIDAttribute properties respectively, but it is possible to
specify different values for each property if required by your design. The
following table shows the default values for each LDAP provider:
Table of Security Identifier attributes used by the Content Engine for the listed directory
servers.
Directory Server

UserUniqueIDAttribute
default value

GroupUniqueIDAttribute
default value

IBM Tivoli Directory Server

Ibm-entryuuid

Ibm-entryuuid

Novell eDirectory

guID

guID

Oracle Internet Directory

Orclguid

Orclguid

Oracle Directory Server

Enterprise Edition (formerly
known as Sun Java System
Directory Server)

Nsuniqueid

Nsuniqueid

Active Directory *

objectSID *

objectSID *

Active Directory Lightweight

Directory Service (AD LDS)

objectSID

objectSID

* When a user or group is migrated from one Windows domain to another,

Active Directory assigns a new objectSID to the migrated user or group,
and can add the previous SID to its sIDHistory property. In this case,
Content Engine's directory service provider for Active Directory is able to
look up the sIDHistory to resolve a previous SID value that has been
persisted in an ACL into a user or group. There is a slight overhead
performing the sIDHistory lookup. Contact IBM Lab Services if you want
assistance updating SID values in ACLs to the current objectSIDs; after
such SID update service, sIDHistory lookup is not necessary.
You provide these property values while running Enterprise Manager's
Create a Directory Configuration Wizard during initial installation. For
more information, see the Directory Configuration Properties subsection of
your directory server's topic at Directory service providers.
Because most of the default SID attributes are generated by the LDAP
server itself during user or group creation, and because they are
machine-dependent, SID value changes that might result because of
activities such as backup, restore, moves, or duplication of the underlying
LDAP server and hardware, can lead to complications. To introduce
configuration flexibility and to avoid problems associated with a fixed SID
attribute, you can choose non-default LDAP attributes, such as employee

64

Security Extract

number, to function as the SID. The value of the attribute that you choose
for your user and group IDs must be unique across the configured LDAP
realms. Because the Content Engine authorization process uses the attribute
as the single identifier of a user or group in an LDAP repository, a
non-unique value will cause authorization failures.
In addition to the requirements that they be unique and immutable (or
static), non-default user or group SID values must be:
v Indexed, to improve performance of LDAP users or groups queries by
SID.
v Less than or equal to 507 bytes. You should choose reasonably compact
values for performance. (The lengths of default SID values range from
approximately 16 to 36 bytes.)
v Returned as Java String via JNDI queries. You must use as SID
attributes only those LDAP attributes that return Java String in the
LDAP Java API. (There are, however, exceptions: if you prefer to assign
default SID attributes in Active Directory or AD LDS using objectSID, or
in eDirectory using guID, you can do so even though these return a Java
byte[] type in the LDAP Java API.
If the value of a SID were to change, Content Engine would consider the
user or group to be a different security principal. For example, if the
default SID attribute is used and you delete a user from the directory
server, and then you recreate it with the same name and set of attributes
but with a different SID value, that user would not be able to access the
documents that it formerly had access to. This is because the directory
server would have assigned it a new SID; the user's former Content Engine
permissions would somehow have to be reestablished.
The following are some common considerations for selecting a non-default
SID attribute and managing SID values:
v Avoid using attributes containing family name or other information that
can change due to personal events. An employee's family name might
change as a result of a change in marital status or other reasons. Such a
change obviously does not affect the employee's security role, but it
would have the unintended effect of cause the employee's SID to
change, leading losing access, explained above.
v Avoid using attributes containing work group name or other information
that can change due to organizational events. A work group's name or
reporting structure might change, but this does not necessarily affect the
work group's or its members' security role. So these events should not
impact SID values, and such attributes are not good SID attribute
choices.
v The template or procedure to recreate or restore users and groups must
ensure identical SID values, including the case of characters and the use
of any filler spaces. Most LDAP servers can be configured to be
case-insensitive and ignoring filler spaces, but this is not always the
case. The best practice is to recreate or restore users and groups using
static template values.
v SID values for distinct users and groups should differ by more than just
the case of characters. Depending on the LDAP server and your
configuration, your system might reject an entry if it contains the same
value of an existing entry except for characters in different cases. Or it
might add a system-generated prefix to make the new entry
distinguishable. Either way leads to undesirable results.
Authorization

65

The security or LDAP administrator is responsible for maintaining SID

stability while performing administrative activities. In cases where SID
values must change, such as when changing from one type of directory
server or reorganizing the directory tree while using the default SID
attribute, or migrating to use non-default SID attributes, the security
administrator must reestablish Content Engine permissions for the affected
users and groups, or contact IBM Lab Services for assistance.
Permissions and Levels
Each FileNet P8 ACE contains a set of permissions that the grantee is
either allowed or denied. For example, Alice might be given permission to
read a document (View Content) and look at the document's properties
(View Properties). Bob might have these permissions and also have
permission to add a document of a particular class (Create Instance) and
delete a document (Delete). Unless these permissions are associated with
Alice's ACE, she will not be able to carry out these actions on a particular
document or class of documents.
In fact, each ACE has entries for all possible permissions for the particular
object, with each permission set to either Allowed or Denied (or if not set
at all the permission is implicitly denied). This is how Alice and Bob can
have different permissions. The Create Instance permission might be
marked Allow for Bob's ACE, and marked Deny for Alice's ACE. Deny
settings have precedence over Allow settings. So, in Alice's case, even if
she belongs to a group whose ACE indicates its members are allowed
Create Instance permission, she will be denied that permission because of
the Deny setting on her individual ACE.
Accounts reside in a directory server
FileNet P8 ACEs all represent accounts residing in one of the supported
directory servers used for authorization. However, FileNet P8 creates and
manages two internal accounts, #CREATOR-OWNER and
#AUTHENTICATED-USERS, which are not persisted in the authentication
provider.
FileNet P8 uses LDAP, the Lightweight Directory Access Protocol, to
provide accounts to Content Engine where they become associated with
FileNet P8-specific permissions and other descriptors explained in this
topic. The use of LDAP ensures that account information is safely
encrypted in transit between the authentication provider or directory
server and Content Engine. See Directory service provider integration for
information about the supported directory servers.
Access Control Lists (ACLs)
Once users are authenticated and logged onto a particular object store,
their access to information, documents, workflows, etc. is controlled by
security settings either on those objects or on objects that control the access
to those objects. Each securable object has an Access Control List (ACL)
that indicates who is granted and who is denied permissions to its
properties and any associated content. An ACL can contain any number of
grantees, which can be both users and groups. Each grantee's set of access
permissions is stored as an access control entry (ACE).
Simply put, then, each ACL is a collection of ACEs whose purpose is to
ensure that only those users and processes have the access that the system
designers intend.

66

Security Extract

Understanding how ACEs and their associated permissions are inherited is

an essential part of understanding and designing the security behavior for
your application. Each ACE, besides indicating whether an access
permission is allowed or denied, also contains information about the
source of each permission. That is, a permission can either be applied
directly, inherited from another object, or applied from a security template.
The source has a direct effect on the permission's subsequent inheritance
behavior, even determining whether it is inheritable to some other object.
The next section describes these various aspects of an ACE.
Object store administrators can view and modify an object's security using
either Enterprise Manager or the Workplace or Workplace XT applications.
However, each provides a different security interface with different
capabilities and behavior: How Workplace applications display security
shows the application interface. Enterprise Manager's security editor
illustrates the following data fields:
ACE Name
The name of a user or group is associated to each ACE. This is in
"principal name" format, which can vary depending on the underlying
authentication service. Underlying the "Name" of the ACE is its fully
qualified Distinguished Name or (if using Active Directory) its Principal
name. Some FileNet P8 security interfaces will display this full name.

ACE source: Default, Direct, Inherited, Template

Every ACE has a source, either Default, Direct, Inherited, or Template.
You can view the source types of ACEs in Enterprise Manager's security editor.
Default
Permissions are placed on an object by the Default Instance Security ACL
of its class, as well as permissions placed on a subclass by its parent class.
Default ACEs are directly editable; if you do, its source type becomes
Direct.
Direct Permissions are added directly to an object. Direct ACEs are directly
editable.
Inherited
Permissions are placed on the object by a security parent or by setting up a
relationship with an object-valued property whose Security Proxy Type has
been set to Inherited. Inherited ACEs are not directly editable. See
Understanding security inheritance and Configure security inheritance for
information.
Template
Permissions are placed on the object by a security policy. Template ACEs
are not directly editable and do not appear on classes. Rather, a document,
folder, or custom object class can have a default Security policy which will
pass template ACEs to the instances of the class, if all the conditions for
the template apply. (See Security policies.)
:

ACE security levels

A security "level" is a predefined collection of rights which simplify applying and
administering individual rights.
Authorization

67

For example, the Full Control level for a document includes all possible document
rights, whereas the Major Versioning level includes only those rights required to
allow the user to perform the various tasks required to create a major version of a
document. Documents, folders, custom objects, choice lists, and other securable
objects all have their own predefined levels appropriate to the type of object.
Levels can be viewed and assigned using the object's security editor. Applications
can be designed to expose only the levels to users, or they can allow users to
choose to assign levels or the individual rights. Enterprise Manager's security
editor includes a custom level which is displayed if individual rights have been set
that are different from the pre-designed rights-to-level mappings.
The topic in the Mapping security levels to individual access rights provides
specific definitions of security levels.

Allow or Deny and order of evaluation

Each ACE has one access type: either Allow or Deny.
When evaluating the access granted by a particular ACL, the current system
applies ACEs in the following order of precedence (higher on the list takes
precedence over lower):
ACE source and type

Display

Direct/Default Deny

Deny is selected and is editable.

Direct/Default Allow

Allow is selected and is editable.

Template Deny

Deny is selected and is not editable.

Template Allow

Allow is selected and is not editable.

Inherited Deny

Deny is selected and is not editable.

Inherited Allow

Allow is selected and is not editable.

You cannot remove or change an inherited access right, but you can override one
by directly allowing or denying an access right. To edit an inherited access right,
the administrator must modify the parent that is the source of the inherited access
right.
Because Deny has precedence over Allow within each category (for example, a
Template Deny takes precedence over a Template Allow), if you explicitly deny an
access right to a group and explicitly allow it to a member of that group, the access
right will be denied to the member.
Thus, if an ACL contained two ACEs that were identical in every respect except
that one was an Inherited Deny and the other a Direct Allow, the Direct Allow
would take precedence, with the result that the user would be allowed the ACE.

Default security
Objects have security settings applied automatically by the system.
This topic answers the question, "What is the security behavior if administrators
and users do nothing to change it?"
Object store administrative groups
Members of the groups added to the Object Store Wizard as object store
administrators (object_store_admin) have Full Control of object stores and

68

Security Extract

their contents, which means that while using Enterprise Manager they can
perform any valid action on any item. See the Reference section for the
specific actions.
Users
When creating an object store, the administrator selects one or more groups
that will have basic, non-administrative access rights. For example, if the
administrator selects the Domain Users group as the nonadministrative
group when creating an object store, users of the Workplace and Workplace
XT applications can:
v Add folders at the top level of the object store.
Important: A new folder acquires its initial security from the Folder
class, which grants Full Control to the folder creator (also called Owner
Control), Full Control to members of the object store administrative
groups, but only View Properties access to Domain Users. A user must
have Add to Folder access rights to put documents in the folder. This
means that, by default, users can create top-level folders and add items
to their own folders. However, users cannot add items to the folders
created by other users.
v Add documents (with Add to Folder access rights to the selected folder).
v View the properties and content of all folders.
v View the properties and content of all documents.
v Run the designer applications but not those that are workflow-related.
Other access rights are not set one way or the other, which means they are
implicitly denied to members of non-administrative groups.
Note: For any given access right (for example, View Properties), an access
right has three possible settings: Allow, Deny, or neither. If an access right
is neither explicitly allowed nor explicitly denied, it is "implicitly denied."
Users of other client applications (such as WebDAV and Application
Integration for Office) are subject to the same security as application users
but typically cannot perform as many operations.

Security for integrated components and third-party products

IBM FileNet P8 is integrated with several FileNet and third-party software
products. The topics in this section briefly describe the security features of some of
those products and the requirements when used in conjunction with IBM FileNet
P8 Platform.
IBM FileNet P8 security is enforced for all operations performed via an integrated
application, although the details of implementation will vary depending on the
application.
IBM FileNet P8 does not support operating systems, databases, or other software
from independent software vendors, and might or might not certify updates, fixes,
or service packs released by independent software vendors. For any incident
involving such software or for any updates to such products, customers must
obtain information, support, and updates from the independent software vendor.
IBM might inform you (and might on occasion make a patch available) when a
patch to such software is required for correct functioning of IBM FileNet P8
software. When another vendor's patch interferes with the functioning of IBM
Authorization

69

FileNet P8 software, we will resolve the problem or advise you not to apply that
particular patch until the issue has been resolved.
Browsers
Database security
Security for IBM Legacy Content Search Engine
Security for IBM Content Search Services
Security for FileNet P8 eForms on page 71
Security for IBM Enterprise Records on page 71

Browsers
Browser cookies contain a session key.
For each Workplace or Workplace XT session, the application creates a cookie on
the client containing the session key. The cookie persists in the client memory
cache for the duration of the session and is cleared when either the session or the
browser is closed on the client. Connectivity problems can occur on browsers
configured to refuse cookies.

Database security
IBM FileNet P8 Platform security is enforced for database information accessed
through Workplace, Workplace XT, integrated applications, and administrative
applications. Access to the Global Configuration Database (GCD) database is
configured during initial Content Engine configuration. Object store databases are
secured in the same way
.

Security for IBM Legacy Content Search Engine

Content Engine software logs on to Verity using the credentials of the IBM Legacy
Content Search Engine account.
Content Engine secures Autonomy K2 (Verity) collections by placing an ACL on
each collection that allows access only to the IBM Legacy Content Search Engine
account. No user will be able to use external Verity tools to access the collection
unless an appropriate user and password is provided.
Content Engine does not utilize or depend on Verity's own internal security
features like securing its servers, collections, and objects inside collections.
For more information, see the entries for the IBM Legacy Content Search Engine
accounts in Users and Groups and the description of K2 access to file storage areas
in Storage Area Security.

Security for IBM Content Search Services

IBM Content Search Services index files contain snippets of document content and
other document information. Depending on your security requirements, you might
want to prevent or restrict access to the IBM Content Search Services server and
these index files.
Make sure that the file system directory in which the index files are stored (by
default, CSS_Home\config\collections) has at least the same level of security as the

70

Security Extract

repository in which your documents are stored. If access to your repository is

restricted, ensure that your index files have at least the same level of restrictions.
Communication between the IBM Content Search Services client and server is not
inherently secure. Therefore, you should consider using SSL (Secure Sockets Layer)
to secure IBM Content Search Services data sent over the network.
Setting up TCP access restriction to the IBM Content Search Services server ensures
that the server can only be accessed by the computer on which the client is
installed.

Security for FileNet P8 eForms

FileNet P8 eForms is an expansion product that layers on top of the authentication
mechanisms in place for Workplace and Workplace XT applications.
FileNet P8 eForms appears as an element of each application, it inherits its session
from the application, and the entry points that touch eForms are part of the
application deployment.
The Form Data, Form Policy, Form Template classes (all subclasses to the
document class) are not available for creation unless the expansion product is
installed and enabled. Once created, they are regular document objects that receive
default permissions from their class like any other object, and could then take
advantage of explicit, inherited, and security policy security as needed.

Security for IBM Enterprise Records

IBM Enterprise Records uses several security features.
The IBM Enterprise Records application security uses the following features:
v Markings
v Cross-object store references
v Security parent folders
IBM Enterprise Records is an extension to the Workplace and Workplace XT
applications, and uses the application's security user interface.
Related information:
Cross-object store references
Manage security

Mapping security levels to individual access rights

IBM FileNet P8 security levels are logically defined sets of individual permissions,
intended to simplify the process of assigning permissions to objects.
v Whereas Enterprise Manager displays both levels and the individual rights that
comprise them, some applications, including Workplace, display only the level.
v Applications can name the level differently than Enterprise Manager does.
The topic About access rights - Levels section explains the relationship between
security levels and individual access rights. The topics in this section list the access
rights that make up the security levels for each of the main securable objects.
FileNet P8 domain root security levels on page 72
Object store security levels on page 72
Authorization

71

Class definition security levels on page 73

Folder security levels on page 74
Document security levels on page 76
Custom object security levels on page 77
Other object security levels on page 78

FileNet P8 domain root security levels

Explanation of domain root security levels.
The table below maps domain root security levels to the rights from which they
are comprised. For example, the Use stores and services security level includes
only View all properties rights, while Full Control includes all rights available to
this object. In Enterprise Manager, you can view and modify access rights and
permissions on the Security page of the FileNet P8 domain root property sheet.
In Enterprise Manager, the domain root security page displays:
v GCD administrators, users and groups who have been granted Full Control.
v #AUTHENTICATED-USERS who by default receive Use stores and services.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.
Table that maps domain root security levels,, which are marked with a check symbol, to the access rights.
Rights

Full Control

Use stores and services <Default>

View all properties

AccessRight.READ
Modify all properties
AccessRight.WRITE
Create child objects
AccessRight.CREATE_CHILD
Delete stores
AccessRight.DELETE
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL

Object store security levels

Explanation of object store security levels.
The table below maps object store security levels to the rights from which they are
comprised. For example, the Use object store security level includes the rights
Connect to store, Create new objects, Modify existing objects, and Delete

72

Security Extract

objects. Access rights to an object store are limited to only that object store and do
not extend to other object stores in the FileNet P8 domain.
In Enterprise Manager, the object store's security page lists the users and groups
that were added while running the object store wizard as follows:
v Users and groups added as "users" receive the Use object store level.
v Users and groups added as "administrators" get Full Control and are therefore
object store administrators.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to connect to an object store could appear as Connect to store in an
application UI, but the actual setting for connecting to an object store is the
AccessRight.CONNECT value.
Table that maps object store security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Use object store

View object store

<Default>

Connect to store
AccessRight.CONNECT
Create new objects
AccessRight.STORE_OBJECTS
Modify existing objects
AccessRight.MODIFY_OBJECTS
Delete objects
AccessRight.DELETE
Set owner of any object
AccessRight.WRITE_ANY_OWNER
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL
Modify certain system properties
AccessRight.PRIVILEDGED_WRITE

See Object store access rights for more information.

Class definition security levels

Explanation of class security levels.
The table below maps class definition security levels to the rights from which they
are comprised. For example, the View Properties security level includes the rights
View all properties and Read permissions.
In Enterprise Manager, you can view and modify access rights and permissions on
the Security page of a class definition's property sheet.
Authorization

73

Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.
Table that maps class definition security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Modify properties

Link

View properties
<Default>

View all properties

AccessRight.READ
Modify all properties
AccessRight.WRITE
Link
AccessRight.LINK
Create instance
AccessRight.CREATE_INSTANCE
Create subclass
AccessRight.CREATE_CHILD
Delete
AccessRight.DELETE
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL
Modify Owner
AccessRight.WRITE_OWNER

Folder security levels

Explanation of folder security levels.
The table below maps folder security levels to security rights. For example, the
View Properties security level includes the rights View all properties and Read
permissions.
In Enterprise Manager, you can view and edit these permissions on the Security
page of a folder's property sheet or the Default Instance Security page of the folder
class.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.

74

Security Extract

Table that maps folder security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Modify
properties

Add to folder

View properties
<Default>

View all properties

AccessRight.READ
Modify all properties
AccessRight.WRITE
Reserved12 *
AccessRight.RESERVED12
Reserved13 *
AccessRight.RESERVED13
File in Folder / Annotate
AccessRight.LINK
Unfile from folder
AccessRight.UNLINK
Create subfolder
AccessRight.CREATE_CHILD
Delete
AccessRight.DELETE
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL
Modify owner
AccessRight.WRITE_OWNER
Minor versioning (Inherit only)
AccessRight.MINOR_VERSION
Major versioning ** (Inherit only)
AccessRight.MAJOR_VERSION
View content ** (Inherit only)
AccessRight.VIEW_CONTENT
Change state ** (Inherit only)
AccessRight.CHANGE_STATE
Publish ** (Inherit only)
AccessRight.PUBLISH

* Deprecated permissions.
** Also used by Publishing.
Authorization

75

Document security levels

Explanation of document security levels.
The table below maps document security levels to the rights from which they are
comprised. For example, the View Properties level includes the rights View all
properties and Read permissions.
In Enterprise Manager, you can view and edit these permissions on the Security
page of a document's property sheet or the Default Instance Security page of the
document class.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.
Table that maps document security levels, which are marked with a check symbol, to the access rights.
Rights
View all properties
AccessRight.READ
Modify all properties
AccessRight.WRITE
Reserved12 *
AccessRight.RESERVED12
Reserved13 *
AccessRight.RESERVED13
View content
AccessRight.VIEW_CONTENT
Link a document/Annotate
AccessRight.LINK
Publish**
AccessRight.PUBLISH
Change State
AccessRight.CHANGE_STATE
Minor versioning
AccessRight.MINOR_VERSION
Major versioning
AccessRight.MAJOR_VERSION
Delete
AccessRight.DELETE

76

Security Extract

Full
control

Minor
Major
Modify
versioning versioning properties

View
properties Publish

View content
<Default>

Table that maps document security levels, which are marked with a check symbol, to the access rights.
Full
control

Rights

Minor
Major
Modify
versioning versioning properties

View
properties Publish

View content
<Default>

Read permissions
AccessRight.VIEW_CONTENT
Modify permissions
AccessRight.WRITE_ACL
Modify owner
AccessRight.WRITE_OWNER
Unlink document
AccessRight.UNLINK
Create subfolder (Inherit
only)
AccessRight.CREATE_CHILD

* Deprecated permissions.
** Publish is defined in Workplace to include Modify permissions.

Custom object security levels

Explanation of custom object security levels.
The table below maps custom object security levels to the rights from which they
are comprised. For example, the View Properties security level includes the rights
View all properties and Read permissions.
In Enterprise Manager, you can view and edit these permissions on the Security
page of a custom object's property sheet or the Default Instance Security page of
the custom object class.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.
Table that maps custom object security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Modify
properties

Link

View properties
<Default>

View all properties

AccessRight.READ
Modify all properties
AccessRight.WRITE
Reserved12 *
AccessRight. RESERVED12

Authorization

77

Table that maps custom object security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Modify
properties

Link

View properties
<Default>

Reserved13 *
AccessRight.RESERVED13
Link / Annotate
AccessRight.LINK
Delete
AccessRight.DELETE
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL
Modify Owner
AccessRight.WRITE_OWNER
Minor versioning (Inherit only)
AccessRight.MINOR_VERSION
Major versioning (Inherit only) **
AccessRight.MAJOR_VERSION
View content (Inherit only) **
AccessRight.VIEW_CONTENT
Change state (Inherit only) **
AccessRight.CHANGE_STATE
Publish (Inherit only) **
AccessRight.PUBLISH
Create subfolder (Inherit only)
AccessRight.CREATE_CHILD
Unfile folder from folder (Inherit only)
AccessRight.UNLINK

* Deprecated permissions.
Application Integration users do not see custom objects. Workplace users see
custom objects if enabled by a site preference, but a custom object's Link access
right is hidden in Workplace.

Other object security levels

Explanation of other security levels.
The table below maps security levels to the rights from which they are comprised
for objects that are not otherwise defined in this help section. Examples of such

78

Security Extract

classes are events, subscriptions, and lifecycles. Note that the Link access right
allows the user to associate the object with another object; it is hidden in the
Workplace and Workplace XT applications.
In Enterprise Manager, you can view and modify access rights and permissions on
the Security page of the object's class definition's property sheet.
Each right in the table is expressed as a user interface (UI) description of the right
and as an access right setting that corresponds to the UI description. For example,
the right to view all properties could appear as View all properties in an
application UI, but the actual setting for viewing all rights is the AccessRight.READ
value.
Table that maps object security levels, which are marked with a check symbol, to the access rights.
Rights

Full Control

Modify properties

Link

View properties
<Default>

View all properties

AccessRight.READ
Modify all properties
AccessRight.WRITE
Link
AccessRight.LINK
Create subclass
AccessRight.CREATE_CHILD
Delete
AccessRight.DELETE
Read permissions
AccessRight.READ_ACL
Modify permissions
AccessRight.WRITE_ACL
Modify Owner
AccessRight.WRITE_OWNER

Markings
This section explains what markings are and how they affect the effective security
on objects. Primarily designed for use by the IBM Enterprise Records application,
markings are available to any application that needs the kind of property-based
layer of security that markings provide.
Markings overview on page 80
Marking security: Add, Remove, Use on page 81
Effect of Copy to reservation on page 82
Constraint Mask on page 82
Allow, Deny permissions on page 83
Hierarchical and Non-hierarchical on page 84
Authorization

79

Marking administration (create, modify, remove) on page 85

Markings overview
Markings allow access to objects to be controlled based on specific property values.
When a marking is applied to an object, the resulting access permissions for the
object are a combination of the settings of its original access permissions and the
settings of the marking's Constraint Mask for each marking that is applied to it.
The result of this combination is the effective security mask.
In general terms the way the markings works is:
1. A marking set is defined, containing several possible values called markings.
2. Each marking value contains a set of access permissions which define who can
assign that specific value to an object property, who can modify or remove that
specific value, and, once it is assigned, who will have access to the object it is
assigned to.
3. The marking set is assigned to a property definition on a class such that the
value of that property on instances of the class must be one of the markings
defined by the marking set.
4. Values can only be assigned by users authorized by the associated marking and
access to the object is restricted based on the marking once it is applied.
Markings do not replace conventional access permissions on an object, but rather
are co-equal with them in determining access rights. In other words, if an object
has one or more markings applied to it in addition to one or more permissions in
its permissions collection (ACL), then access to that object is only granted if it is
granted by the permissions and by the markings. Another way to think about how
this works is:
1. A user or process tries to access an object.
2. First, Content Engineresolves the object's ACL to determine who can access the
object and what those users can do.
3. Then it computes the markings applied to the object to see which users to stop
(defined by the marking's Security list) and what they should be stopped from
doing (defined by the marking's constraint mask).
You can have multiple properties assigned to a single class with marking sets
associated, and they will all be used to determine the final access to the object. The
collection of all markings being actually applied to a particular object is displayed
by Enterprise Manager as the object's "active markings".
"Active markings" is the term Enterprise Manager uses in its security editor on its
Active Markings/Owner button. You will see this button text on object instances
whether or not there are actually active markings applied to the object. This button
will just say "Owner" for those objects that cannot have markings applied, which
include all class definitions.
Modifications to markings or marking sets are subject to the Marking Set Cache
Entry TTL setting which affects how often the marking set cache is updated on the
server and the current Enterprise Manager machine.
However, the marking set cache is updated whenever any change or addition is
made to markings or marking sets. Therefore, the cache is most likely up-to-date
by the time the MarkingSetsTTL forces a refresh of the cache.

80

Security Extract

Markings and marking sets are persisted in the FileNet P8 domain resource, the
GCD. This gives them IBM FileNet P8 domain-wide scope, that is, they are
available and have the same meaning across all object stores in a IBM FileNet P8
domain served by a common GCD. The marking-enabled property templates and
the actual properties based on these templates are, however, specific to the object
store in which the property template was created.
The number or size of markings in a single marking set is limited by available
system memory. To perform an access check on a marked object, the entire
marking set and all its markings must be loaded into memory. This is not going to
work if there are millions of markings. For this reason, you should limit the
number of markings in a marking set to no more than 100.
Markings cannot be used in conjunction with choice lists.

Marking security: Add, Remove, Use

Marking security consists of the Add marking, Remove marking, and Use Marked
Objects.
Add marking and Remove marking
A user with Add rights to a marking can set the property value associated
with the marking, if it has not been set. Only those markings to which the
user has Add rights will show in the list of marking values available to be
set in a property. A user with Remove rights to a marking can remove the
marking value.
For example:
1. A Document has a property associated with a marking set. No value
has been specified for the property.
2. The marking set has markings Red, Blue, and Green.
3. Alice has Use rights to Red; Use and Add rights to Blue and Use, Add
and Remove rights to Green.
When Alice views the Document properties, she can set the property
value to Blue or Green but not Red. If the property was set to Green,
she could alter it to be Blue. If the property was set to Blue, Alice
would be unable to alter the property's value.
Use Marked Objects
Use right determines whether the presence of the marking on an object
constrains access to that object. If the user has Use right to the marking,
access to the object will not be constrained.
Users attempting to
access the object

Marking (in Property A)

Bob

Bob

Use Marking Object

Alice

Alice

Use Marking Object

Access
Control
List

Document
Property A

In this example, Alice has the Use Marked Objects access right which lets
her bypass the marking. Her access to the object will be evaluated by the
object's ACL. Bob does not have Use Marked Objects and therefore will
neither see nor have access to the object, regardless of any permissions the
object's ACL might grant him.
Markings and marking sets are Content Engine objects, each with a class
description:
Authorization

81

v Markings are objects that combine metadata behavior with access control
behavior in a way that allows an object's access control to change by
changing a property value.
v Marking sets are containers for markings. Marking sets are associated
with a Property Template which can then be used to add a property to
one or more classes.

Effect of Copy to reservation

If the string property containing a marking has kept the default Copy to
Reservation setting of True, then a user who has Use Marked Objects but does
not have the Add Marking permission will not be able to check out a document,
even if the user has Full Control of the document itself.
This is by design, since to checkout a document creates a new Reservation
document which must have the marking on it due to its property's Copy to
Reservation value of True. This requires the marking to be Added to the new
document, and since the user in this scenario does not have the Add Marking
permission, the checkout will be prevented.
Related information:
Class property definitions (More tab)
Versioning properties

Constraint Mask
By default, all the rights are checked, meaning all constraints are masked and only
those that have the Use Marked Objects access rights on the marking will be able
to view and access the object.
When one of the rights in the constraint mask is cleared, it indicates that users
with this privilege on that object are allowed through the marking restriction even
if they do not have the Use Marked Objects access right on the marking. In this
way, the constraint mask can be used to design more granular control at the
marking level.
Here are some examples to illustrate the security behavior of the constraint mask:
v If the constraint mask has all permissions selected (turned on), and if Alice does
not have Use Marked Objects rights to that marking, then Alice will have no
access and will not see the object, even if she has Full Control on the object's
ACL.
v If the constraint mask has all permissions selected (turned on) except View All
Properties and Delete which are deselected (turned off), and if Bob does not
have Use Marked Objects rights to that marking, then Bob can see and delete
the object, provided that he is granted those permissions on the object's ACL.
v If the constraint mask has all permissions deselected (turned off), and even if
Carol does not have Use Marked Objects rights to the marking, then Carol can
do everything to that object granted her by the object's ACL. (Deselecting all
permissions in the constraint mask effectively renders the marking inactive.)
v If Dave has Use Marked Objects rights to the marking, the constraint mask has
no effect on his resulting access. His access will be solely determined by the
object's ACL.
In the following graphic:

82

Security Extract

v Alice and Bob are members of the Authors group. The only property selected in
the constraint mask is Modify all properties. The ACL on the document gives
Authors the Delete permission.
v Alice has the Use Marked Objects right, and therefore the marking's constraint
mask does not apply. She can delete the document (and anything else that the
ACL grants to Authors).
v Bob does not have the Use Marked Object, and therefore the marking's
constraint mask applies to him. The constraint mask specifies Modify all
properties and that means that Bob does not have the Modify all properties right
on any object to which this marking is applied, even if it is explicitly granted to
him by the ACL. The document has not granted the Modify all properties right
to Bob in the first place since he is not a member of the Editors group and
therefore the marking has no impact on him. Also, Bob can delete the document
(regardless of whether or not he has the Use marked objects right) since the
marking constraint mask does not affect the Delete right, and because it has
been granted to him by virtue of his membership in the Authors group.
v Alice and Bob are not members of the Editors group. Because the Editors group
is not listed on the marking, Editors do not have the Modify all properties right
despite being granted Full Control by the document itself. The reason for this is
the constraint mask in the example only specifies the Modify all properties right.
As a result, either having or not having the Use marked object right on the
marking can only affect the Modify all properties right on any given object
marked with this marking.
Marking (in Property A)
Constraint Mask:
Modify all properties
Security:

Document Access
Control List

Bob

Use Marking Object

Authors group:
Delete

Alice

Use Marking Object

Editors group:
Full Control

Document
Property A

Allow, Deny permissions

Each access control entry listed on a marking value's security page is marked
either Allow or Deny.
Allow Allow is the default setting for each new security added to a marking's
security list. It is also the most common way to set up marking security
behavior. Unless clearly stated, this topic describes Allow security types.
Deny
Typically markings are used to determine who will be denied access to
evaluate the security rights of the object. Users who have the Use Marked
Objects access right will not be limited by the constraint mask of the
marking. However, an administrator can set up deny rights on the marking
which will override any allow access otherwise granted to the marking.
For example:
1. The security on a document grants #AUTHENTICATED-USERS full
control access.
2. The document has a single-valued property associated with a marking
set with possible values of Chicago, New York, and Boston.
3. The property value is set to Boston.

Authorization

83

4. The Boston marking has a constraint mask of full control allow (all
permissions selected).
5. The group Everyone_Boston has Use/Allow rights to the Boston
marking.
6. The Sales group has Use/Deny rights to the Boston marking.
In this scenario:
v Users who are not members of Everyone_Boston cannot access the
document.
v Users who are members Everyone_Boston can access the document,
unless they are also members of Sales.
v Users who are members of Everyone_Boston and Sales cannot access
the document. The deny setting on the marking overrides the allow
setting and ensures that no one in Sales sees the document even if
they are in the Boston office.

Hierarchical and Non-hierarchical

There are two types of marking sets: hierarchical and non-hierarchical.
v Non-hierarchical (also called "list" ) marking sets contain one or more markings,
each independent of all others. This type of marking set can be assigned to
either single or multi-valued properties.
v Hierarchical marking sets arrange markings in a simple, single branch series.
Each hierarchical marking has a superior marking in the same set, except for the
first, or top marking. Hierarchical marking sets support an order of precedence
when evaluating access rights. A marking in a hierarchical marking set explicitly
grants access rights to some set of security principals. In addition, it also
implicitly grants the same rights for all markings that are inferior to (or below) it
in the hierarchy. Hierarchical marking sets can be assigned only to single-valued
properties.
In the following, the user Alice has been granted the Use Marked Objects right by
the Top Secret marking. Since this is a hierarchical marking set, the effect of this is
that she not only has the Use Marked Objects right for the Top Secret marking, she
also implicitly has it for the Secret and the Restricted markings as well. This means
that for Alice, objects that are marked with either the Restricted or Secret markings
behave as if they are marked with the Top Secret marking. Similarly, Bob has
implicit Use Marked Objects right to the Restricted marking, because it is lower in
the hierarchy than Secret.
Security Access
Marking Set

Top Secret

Alice:
Use Marked Object

Secret

Bob:
Use Marked Object

Restricted

Carol:
Use Marked Object

There is an exception to the rule that permissions granted on superior markings

are implicitly granted on inferior markings. Recall that there are two types of
access permissions:
v Allow permissions (the more common of the two)
v Deny permissions

84

Security Extract

Deny permissions always take precedence over allow permissions. The way this
works for hierarchical marking sets is that deny permissions on inferior markings
always take precedence over allow permissions on superior markings. This
behavior is illustrated in the example below:
Security Access
Marking Set

Top Secret

Alice:
Use Marked Object

Secret

Alice:
Deny Use Marked
Object

Bob:
Use Marked Object

Restricted

In this example Bob is implicitly granted access to objects marked Secret or

Restricted as well as being explicitly granted access to objects marked Top Secret
due to the fact that he is granted the Use Marked Objects access right on the Top
Secret marking which is superior to both Secret and Restricted.
Alice, on the other hand, is denied access to objects marked Top Secret or Secret
but is granted access to objects marked Restricted. The reason for the difference is
that Alice is explicitly denied the Use Marked Objects right by the Secret marking.
Since Deny permissions are implicitly present on all superior markings, it is
implicitly present on the Top Secret marking. She is also explicitly allowed access
by the Top Secret marking, but since Deny permissions take precedence over Allow
permissions, she is still denied access to objects marked with Top Secret. What can
be less clear is why she is granted access to objects marked with Restricted.
The reason is because she implicitly obtains access rights to objects marked
Restricted by being granted Use Marked Objects rights by the Top Secret marking
which is superior to Restricted. The Deny permission on the Secret marking has no
affect on the Restricted marking because the Restricted marking is inferior to the
Secret marking.
From this example three general rules can be observed:
1. Allow permissions affect markings downward in the hierarchy; that is, an
Allow Permission placed on a superior marking is implicitly present on inferior
markings.
2. Deny permissions affect markings upward in the hierarchy; that is, a Deny
Permission placed on an inferior marking is implicitly present on superior
markings.
3. Deny permissions take precedence over Allow permissions.

Marking administration (create, modify, remove)

You can use Enterprise Manager for creating and applying marking sets.
Applications can also utilize one of FileNet P8's APIs.
Here are some general rules governing administration:
Renaming a marking set
Renaming a marking set after it has been persisted is not allowed. The
marking set name can be modified only during the creation of markings.
Once it has been persisted, the marking set name is read-only.
Changing the marking value
The value of a marking can be modified even when properties exist which
Authorization

85

use that marking value. Existing objects that have property values set to
the old marking value will not be updated to reflect the new marking
value and, therefore, will need to be updated manually. If the property
value is not updated, the marking security on those objects will no longer
have any effect.
Modifying the constraint mask and security
You can change the marking's constraint mask and security any time
without affecting existing properties.
Deleting a Marking Set
Marking sets that are referenced by at least one property template cannot
be deleted. The marking set can be deleted if it is not associated with any
property templates or after any associated property templates have been
deleted.
Removing a marking
Individual markings can be deleted from a marking set at anytime, even if
a property value is set to that marking.
Export issues
Since P8 domain resources contained in the GCD are not exportable,
markings are not directly deployable to another FileNet P8 domain.

Object access rights and security

The topics in this section describe the access rights that apply to securable objects
and also provide some security details.
Securable objects
Access rights required to take actions on page 87
Object store access rights on page 90
Class access rights on page 91
Folder access rights on page 92
Document access rights on page 93
Compound document security on page 95
Document lifecycle policies and lifecycle actions access rights on page 97
Annotation access rights on page 98
Custom object access rights on page 99
Workflow definition access rights on page 99
Event and subscription access rights on page 100
Script access rights on page 100
Publishing access rights on page 100
Search access rights on page 102
Document entry template access rights on page 103
Workflow rosters and queues on page 103

Securable objects
An independently securable object has its own Access Control List (ACL) that
specifies its security and ensures that access rights are checked each time a user
tries to access it. A dependently securable object depends on some other object as
its security parent.
The important securable objects are:

86

Security Extract

v
v
v
v

FileNet P8 domain (Domain Root)

Object stores
Classes
Documents plus several subclasses of the document class:
Publish templates

Entry templates
Publication documents
Stored searches
Search templates
Workflow definitions
Workflow queues, rosters, and logs
v Folders
v
v
v
v
v
v

Custom objects
Events and subscriptions
Lifecycle policies and actions
Security policies
Annotations
Choice list class

v Property template class

The following objects are dependently securable, meaning that their security is
provided by, and is the same as, the object that is their security parent:
v Content elements have the same security as their document.
v A property assigned to a securable object has the same security as that object.
v The individual choices in a choice list have the same security as the object that
the choice list is assigned to.
v A lifecycle state in a lifecycle policy
Related information:
Annotations
Concepts: choice lists
Concepts: properties
|

Access rights required to take actions

|
|

IBM FileNet P8 has security requirements for access rights to take certain actions
on objects.

Table 1. Rights required to take activities

|
|

Action

Objects affected by the

action

Rights required to perform the

action on the affected object

Checkin major version

Document

MAJOR_VERSION

Checkin minor version

Document

MINOR_VERSION

|
|

Checkout

Document

MAJOR_VERSION or
MINOR_VERSION

Authorization

87

Table 1. Rights required to take activities (continued)

|
|

Action

Objects affected by the

action

Rights required to perform the

action on the affected object

Cancel checkout

Document reservation

MAJOR_VERSION or
MINOR_VERSION or DELETE

|
|
|
|
|
|

If checkout is exclusive, it can only be

canceled by the user who checked it
out or who has both WRITE_OWNER
and DELETE access to the reservation

Demote Version

Document

MAJOR_VERSION

Promote Version

Document

MAJOR_VERSION

Freeze

Document

WRITE_ACL

View content

Document or Annotation

VIEW_CONTENT

|
|

Move Content

Document or Annotation
or Version Series

WRITE

|
|

Lock

Document or Folder or
Custom Object

WRITE

|
|

Unlock

Document or Folder or
Custom Object

WRITE

|
|

Take Federated
Ownership

Document

WRITE_ACL

|
|

Annotate

Document or Folder or
Custom Object

All rights required for Create action

using the annotation's class definition

LINK

|
|
|

Create subscription on
document

Document and Event

Action

|
|
|

Document: LINK
Event Action: LINK
All rights required for Create action
using the subscription's class
definition

|
|
|

Delete subscription on
document

Document and Event

Action

Document: UNLINK
Event Action: UNLINK
Subscription: DELETE

|
|

Apply security template

Document, Folder, or
Custom Object

WRITE_ACL

Change state

Document or Task

CHANGE_STATE

File

Folder

Object store: STORE_OBJECTS

Folder: LINK

Object being filed: READ

Unfile

Folder

Object store: REMOVE_OBJECTS

Folder: UNLINK

|
|

Raise Event

Event

Event class definition: READ and

CREATE_INSTANCE
Object store: STORE_OBJECTS

Create class

88

Security Extract

Class definition

WRITE

Table 1. Rights required to take activities (continued)

|
|

Action

Objects affected by the

action

Rights required to perform the

action on the affected object

Modify

Any object

Object store: MODIFY_OBJECTS

Change class

Any object

Object: WRITE and WRITE_ACL

|
|
|
|

Class definition: READ and

CREATE_INSTANCE
Set object-valued
property

Any object

|
|
|

WRITE (can also be changed by

Modification Access Required)
Target: READ (can also be changed by
Target Access Required)

View object properties

Any object

READ or
Object store: WRITE_ANY_OWNER

|
|
|

Special rights for

modifying Owner
property

Any object

|
|
|
|
|
|
|

Special rights for

modifying Creator,
DateCreated,
LastModifier,
DateLastModified,
DateCheckedIn
properties

Any object

|
|

Unset object-valued
property

Any object

WRITE (can also be changed by

Modification Access Required)

|
|

Modify object properties

Any object

WRITE (can also be changed by

Modification Access Required)

|
|

View Permissions
property

Any object

READ_ACL

|
|

Modify Permissions
property

Any object

WRITE_ACL

|
|

Create

Object store objects,

except class definitions

Class definition: READ and

CREATE_INSTANCE

Object store:.WRITE_ANY_OWNER
WRITE
Object store: PRIVILEGED_WRITE

|
|
|
|
|

WRITE_OWNER

Object store: STORE_OBJECTS

Delete

Objects from an object

store

if relationship object: UNLINK

if component relationship object:
UNLINK or DELETE

|
|
|

if reservation object:
MINOR_VERSION or
MAJOR_VERSION or DELETE

if any other object: DELETE

|
|
|
|

if an object-valued property's
DeletionAction is set to PREVENT
and references another object, this will
prevent the deletion from taking place

|
|
|

Do anything in an object Object store

store (often interpreted as
a Read right)

CONNECT

Authorization

89

Table 1. Rights required to take activities (continued)

|
|

Action

|
|
|

Objects affected by the

action

Rights required to perform the

action on the affected object

Create new instances

(applies to Create, Link,
or File)

Object store

STORE_OBJECTS

|
|
|

Modify existing objects

(applies to all other
modifying actions)

Object store

MODIFY_OBJECTS

|
|
|

Delete an object (applies

to Delete, Unlink or
Unfile)

Object store

REMOVE_OBJECTS

Install Addon

Domain

WRITE

|
|

Create GCD objects

(including object store)

Domain

WRITE

|
|

Delete GCD objects

(including object store)

Domain

DELETE

|
|
|
|

Modify properties on
GCD objects (including
object store)

Domain

WRITE

|
|
|
|
|
|
|
|
|
|
|

More information about access rights required to take actions

v In addition to the rights that let you view, modify or delete, every action related
to objects in an object store always require the object store CONNECT right, and
could also require one or more of the following, depending on the action:
STORE_OBJECTS, MODIFY_OBJECTS, REMOVE_OBJECTS.
v The owner of an object gets implicit READ, READ_ACL, WRITE_OWNER and
WRITE_ACL rights to that object.
v Users with object store WRITE_ANY_OWNER rights also get implicit READ and
WRITE_OWNER rights to all objects in that object store.
v Users with READ access to the domain, also implicitly have READ access to all
object store objects, and can therefore view the properties of all object stores.
v Users with WRITE access to the domain will implicitly have WRITE_ACL access
to all object store objects so can change the permissions of object stores (not the
contents).

|
|
|

Object store access rights

When running the Object Store wizard, you specify the users and groups that
should be object store administrators and those who should have
non-administrative access rights. You can view and modify these security
assignments any time while running Enterprise Manager.
With one exception, administrative users and groups get Full Control on the object
store ACL and likewise on all security ACLs of all securable objects. Note that this
does not include the permission to create object stores, file storage areas, content
cache areas, and related actions like deleting and moving. These permissions
belong only to the user and groups who were specified as GCD administrators
(gcd_admin) when the IBM FileNet P8 domain was created. A user or group can, of
course, belong to both the object store administrators group
object_store_admin_group and the GCD administrators (gcd_admin) group.

90

Security Extract

The exception mentioned above is the permission Modify certain system

properties which determines which users can set certain system properties
(Creator, DateCreated, LastModifier, DateLastModified) that are normally system
only. Users and groups who will be running system level tools (like import and
migration tools) might need this permission.
Non-administrative users and groups get the following security levels:
v Use object store on the object store ACL.
v Modify Properties on the root folder (to a Workplace or Workplace XT user, the
root folder represents the object store).
v View Properties and Create Instance on all classes.
v A Custom level on the Default Instance Security of document classes that
includes View All Properties and Create Instance.
See the Reference section for more information about these security levels.
Relationship of object store permissions to permissions on objects contained by
the object store
Several permissions that appear on the Security tab of each object store's
property sheet have a hierarchical relationship to other permissions on
classes and objects contained in that object store:
v If a user or group is granted rights to Delete objects, Create new
objects, or Modify existing objects on the Security tab of the object
store, and if the user or group also has the right to delete or modify on
the Security tab of the actual object instance as well as the Create
instance permission on the Security tab of the object's class (for example,
a document class), the user or group can delete, modify, or create the
objects based on these classes.
v If a user or group is allowed these permissions on the object store, but
does not have the delete, modify, or create permissions on the object
instance or its class, the user or group cannot delete, modify, or create
the object.
v If a user or group is denied these permissions on the object store, the
user or group cannot delete, modify, or create the objects even if the
object's instance or class gives the user or group these permissions.
Workplace and Workplace XT
To log in, a user must have at least View Properties access rights to the
object store that contains the user and site preference files.
Users see all object stores configured through Enterprise Manager but must
have View Properties access rights to the root folder in order to open an
object store.

Class access rights

Classes receive default security initially from their parent class.
Enterprise Manager displays all available classes in its Document Class and Other
Classes nodes. The administrator can define any number of new subclasses of most
of these classes and can edit the access rights of any class.
Class security tabs
When you use Enterprise Manager to display the properties of a document
class, you see three security-related tabs:
Authorization

91

v The Security Policy tab displays the name of the document class' default
security policy, if there is one; lets you change the default security
policy; and lets you run the security policy wizard to create a new
policy.
v The Default Instance Security tab displays the access rights that will be
applied to each new document (the first version) based on the class. The
#CREATOR-OWNER (the user who creates the object using this class) is
granted Full Control by default.
v The Security tab displays the access rights of the document class itself.
By default users are granted Create instance so they can create new
instances of the class (in this case new documents), but are not granted
Create subclass, since subclassing is by default reserved to system
administrators.
Classes receive default security from their parent class
Content Engine provides the Document Class which you can modify and
use as the start of your own hierarchy of document classes. For example,
you could create this hierarchy of document classes:
Document Class (predefined, can be modified)
Tax Bills (subclass of Document Class)
Property Tax Bills (subclass of Tax Bills)
Estate Tax Bills (subclass of Tax Bills)

Each document class receives its default security from its document class
parent. Subsequent updates to a parent class propagate to the child classes.
New objects acquire initial security from a class
The Default Instance Security collection of permissions on a document
class provides the initial security for a new document based on that class.
Similarly with folders and every other class that allows you to create
"instances" of it. This initial security is not treated as Inherited and is
therefore editable. Modifying a class does not affect the security of existing
objects based on that class.
See also Class definition security levels.

Folder access rights

Folders are instances of the folder class and obtain default security from their class.
Folders have the following security characteristics:
v Each folder is independently secured by its own ACL.
v Folders pass security to their directly contained subfolders, if the subfolder has
set its "Inherit parent permissions" property to True, and if the parent folder has
inheritable permissions.
v A folder can become the security parent of the documents and custom objects it
contains, if both the folder and the contained objects have been properly
configured.
v Folders contain several permissions marked "(Inherit only)" that will be inherited
by the documents contained in that folder if there is a properly configured
security parent relationship between the folder and the documents it contains.
v A folder can be associated with a security policy, but can only use Application
security templates, which require custom programming to apply the template to
the folder.
Folder access rights

92

Security Extract

Table of folder access rights

Full Control

Modify Properties

Add to Folder

View Properties

Includes all access rights

and permits all operations
including:

Create subfolders; modify

folder properties

Add documents and

View the folder properties
custom objects to the folder and security; open the
folder

v Modify security
v Change owner
v Delete the folder

Default security
The new folder acquires its initial security, with source type of "Default",
from the Default Instance Security page of its class. By default, the user
who creates the folder gets Full Control.
Modifying the security of a particular folder class has no effect on the
security of existing folders that are instances of that class. By contrast,
modifying a folder's security can affect subfolders. Specifically, a child
subfolder inherits only access rights from the parent folder if its "Inherit
parent permissions" property is set to True and the parent has permissions
that are set to be inheritable.
Folder behavior using the Workplace or Workplace XT applications
When a user opens an object store using the Workplace or Workplace XT
applications, the object store's root folder displays only those items the
user is allowed to see. Users cannot add documents to the root folder but
must select another folder. However, using the designer Java applets,
users can save stored searches, search templates, workflow definitions, and
publish templates to the root folder of an object store.
When a user deletes a folder using the Workplace or Workplace XT
applications, the folder gets deleted without deleting the contained
documents. Enterprise Manager offers additional options for deleting
contained documents when deleting folders.
The application's Preferences folder, which contains the various site and
user preferences files, is visible in Enterprise Manager but is not visible
using the Workplace or Workplace XT applications. This is configured
using the IsHiddenContainer property.
Related information:
About deleting folders

Document access rights

Documents are instances of the document class. When first created they obtain
initial security from the Default Instance Security ACL of their class.
Documents have the following security characteristics:
v The first document version passes the same permissions to subsequent versions,
all of which have source type of Default.
v Each document version is independently secured by its own ACL.
v Documents are the security parent of any annotations associated with them.
v A document can have a folder as a security parent from which it will receive
"Inherit" permissions.

Authorization

93

v A document can be associated with a security policy from which it will receive
"Template" permissions. Security policies can be configured to place security on
documents as they pass through various versioning states.
See the Documents and Folders section of Administering Content Engine. For
security information about compound documents, see Compound document
security.

Access rights defined

Table of document access rights
Full Control
All access
rights listed in
the columns to
the right and:
v Modify
security
v Change
owner

Minor
Versioning

Major
Versioning

v Check out a
document

v Change state v Modify

(promote
property
and demote)
values

v Check in a
minor
version
v Cancel a
checkout

v Delete the
document

Modify
Properties

View
Properties
v View
properties
and security

Publish

View Content

v Publish the
document

v View content

v Check out a
document
v Check in a
major
version
v Cancel a
checkout

Tip: The Unlink document access right is not included in any of Enterprise
Manager's predefined levels. It can be assigned directly.

Initial security acquired from the document class

A document acquires its initial default security from its document class and, if the
application's site preference allows it, the application user can modify the security.
By default, the user who creates a document gets Full Control (also called Owner
Control).
Modifying document class security has no effect on the security of existing
documents.

Content element security

The document's content elements are not independently securable but can only be
accessed through their document version. In effect, a document's content has the
same security as the document. In Enterprise Manager, a document's security
information appears on the Security page of its property sheet. In Workplace or
Workplace XT, a user can display a document's Info page to view security
information and to assign a security policy.

Browsing vs. searching

To navigate to a document by browsing, a user must have access to all folders and
subfolders in the path to the document. By contrast, a search template checks only
the document's security even if the search specifies a folder. This means that
searches might allow a user to find documents that could not be found through
browsing.

94

Security Extract

Related information:
Versioning states
About compound documents

Compound document security

Component Relationship objects define the structure of a compound document and
specify rules for binding from the parent to a child component.
Component Relationship objects are not independently securable, and inherit the
security of their parent document. This parent-based style of security means that
users with view rights to a child component document are not guaranteed view
rights to all component relationship objects that reference them.
A user needs the access right Link a document / Annotate on a parent component
document to be allowed to create component relationship objects that reference the
document as a parent component. Also, Unlink document or Delete rights on the
parent component document are required to delete a component relationship
object, and Modify all properties rights on the parent component document are
required to modify the properties of a component relationship object.
View all properties rights are required on a child component document to assign
the document to the Child Component object-valued property of a component
relationship object.
Component Relationship Actions and Parent Component Requirements
Table of component relationship actions and parent component requirements
Component relationship
action
Create

Requirements

Comments

In addition to security
requirements, a parent
document
CompoundDocumentState
property must be set to
CompoundDocument for any
child component relationship
objects to be created that
User must have View all
reference the document as
properties rights on the child the parent.
component to create
component relationship
object that references the
child.
User must have Link a
document / Annotate rights
on the parent component to
create component
relationship object that
references the parent.

Authorization

95

Table of component relationship actions and parent component requirements

Component relationship
action
Delete

Requirements

Comments

Users must have Unlink

document or Delete rights
on the parent component to
delete a component
relationship object that
references the parent.

Any user with Unlink

document rights on the
parent component is also
granted Delete rights on any
direct child component
relationships object.
This enables a user without
delete rights on a parent
document to delete child
component relationship
objects, that is, to modify the
structure of the compound
document.

Modify properties

Users must have Modify all

properties rights on the
parent component to modify
properties on a component
relationship object.

Property update rights allow

users to modify order
number, change child
document referenced, and
modify custom properties on
component relationship
objects.

Requirements for Child Component Actions

Table of child component actions and security requirements
Child Component Action

Security requirements

Delete

Before deleting a child component, query for

any component relationship objects which
deny deleting the child component as long
as the component relationship object exists.
This query is performed bypassing the
credentials of the user initiating the delete
action since that user might not have View
all properties rights on all existing
component relationships that reference the
child component.

Checkout, Delete, Demote version, Promote

version, Modify properties

These actions on a child component might

require that component relationship objects
that reference the child component be
updated. This requires View all properties
and Modify all properties rights on all
component relationship objects that reference
the child component. The user initiating the
action might not have these rights on the
component relationship objects so the server
must be able to bypass the credentials of the
user to query, retrieve and update properties
as needed on these objects.

Enterprise Managerexposes the ability to modify a component document

structure according to the user's access rights to the parent document. The
access rights required to make modifications are listed below, along with
the text that Enterprise Manager uses to display these on the Security

96

Security Extract

property page of the Document Properties property sheet. Enterprise

Manager disables the appropriate user interface controls if the user does
not have the proper access to make a modification.
Table of access rights required to modify a component document structure.
User Action

Required Access

Displayed in Enterprise
Manager

Add compound document

link

FN_ACCESS_LINK

Link a document / Annotate

Remove compound
document link

FN_ACCESS_UNLINK

Unlink document

Reorder / modify compound FN_ACCESS_WRITE

document link

Modify all properties

Important: The Unlink document access right is not included in

Enterprise Manager's Full Control access level and must be directly
assigned.

Document lifecycle policies and lifecycle actions access

rights
Document lifecycle actions and lifecycle policies are independently securable.
Lifecycle actions and lifecycle policies have the following security characteristics:
v Both are instances of their own classes: the Document Lifecycle Policy class and
Document Lifecycle Action class. Therefore they obtain initial security from the
Default Instance Security ACL of their class, like all objects do when first
created. Both classes are subclassable. You can view and modify these classes
under Enterprise Manager's Other classes node.
v Lifecycle actions and policies are independently securable. They are not required
to have the same security as the security placed on the document class (or
individual document) to which they are attached. It is obviously a much simpler
security model if they do. However it can be configured differently if required
by the needs of the application's security.
v Document lifecycle actions and policies do not have a security parent
relationship with any other object. Specifically, a lifecycle policy does not have a
security inheritance relationship with the document class to which it is
associated.
v In Enterprise Manager, individual lifecycle actions and lifecycle policies are
displayed in subfolders of the Object Stores > object store name > Document
Lifecycles node. If these folders are empty it means that none have been created
for that object store. Both objects have property sheets containing a Security tab
which allows you to view and modify the security on that object.
v Like other objects, lifecycle actions and lifecycle policies have an owner property.
The owner need not be the same as the owner of the document with which the
lifecycle policy is associated.

Authorization

97

Document lifecycle policy access rights

Table of document lifecycle policy access rights
Full Control

Modify Properties

Link

View Properties

All in Modify
Properties plus:

All in Link plus:

All in View
Properties plus:

v View properties

v Delete
v Modify
permissions

v Modify all
properties

v Link a document

v Read permissions

v Create instance

v Modify owner

The Link access right is hidden in the Workplace and Workplace XT applications.

Document lifecycle action access rights

Table of document lifecycle action access rights
Full Control

Modify Properties

Link

View Properties

All in Modify
Properties plus:

All in Link plus:

All in View
Properties plus:

v View properties

v Delete
v Modify
permissions

v Modify all
properties
v Create instance

v Link a document
lifecycle policy

v Read permissions

v Modify owner

The Link access right is hidden in the Workplace and Workplace XT applications.
Related information:
Concepts: lifecycles

Annotation access rights

Annotations are instances of the Annotation class. Therefore they obtain initial
security from the Default Instance Security ACL of their class, like all objects do
when first created.
Annotations have the following security characteristics:
v Each annotation is independently persistable and independently secureable by
its own ACL.
v Annotations are not versionable and are not automatically passed from one
version of an annotated document to the next version. In order for the next
version to include the same annotation as its previous version, the annotation
would have to be newly created for that document version.
v The document or folder that has an annotation will be the security parent of the
annotation if the grantee has been set with an inheritable depth. The permissions
will appear on the annotation with a source of "inherited", which is normal in
security parent relationships.
v Just like document content, an annotation's content elements, if there are any, are
not independently securable and can only be accessed through the annotation
object itself. In effect, then, an annotation's content has the same security as the
annotation. In Enterprise Manager, an annotation's security information appears
on the Security page of its property sheet. This is available from the Annotation
tab on the document or folder property sheet.

98

Security Extract

v If you are using Workplace or Workplace XT, be aware that these applications
limit permissions on annotations to the following simplified permission levels:
Owner Control, Modify Content, and View Content. For more information, see
Working with documents > Working with documents in Workplace > Work
with Security > Manage Security.
v Like other objects, annotations have an owner property. An annotation owner
need not be the same as the owner of the document or folder that contains the
annotation.
Table 2. Annotation access rights defined
Full Control

Modify Properties

View Properties

View Content

All access rights

listed in the columns
to the right and:

Modify property
values

View properties and

security

View content

v Modify
permissions
v Modify owner
v Delete

Custom object access rights

Custom objects are securable, containable objects (can be filed in folders) but have
no content and are not versionable.
Custom objects acquire security from the following sources:
v The Default Instance Security tab of the class (acquired when the custom object
is created).
v A security parent, if configured.
v A security policy. Because custom objects are not versionable, a security policy
can apply only application security templates, and only according to a custom
application written using IBM FileNet P8 Platform APIs.
Table 3. Access rights defined
Full Control

Modify Properties

Link

View Properties

All access rights

listed in the columns
to the right and:

Modify property
values

Associate the custom

object with other
objects

View properties and

security

v Modify security
v Change owner
v Delete the custom
object

The Link access right is hidden in Workplace.

See also Custom object security levels.

Workflow definition access rights

Workflow definitions are versionable documents with the same security as regular
documents. A user must have View Properties access rights to launch or to
participate in a workflow.
Acquisition
A workflow definition acquires its initial security from the Default Instance
Authorization

99

Security ACL of the Workflow Definition class. Subsequent updates to this

class have no effect on the security of existing workflow definitions. A
workflow definition is otherwise like any other document with regard to
security.
Inheritance
A workflow definition can inherit security from a folder security parent
that contains the workflow definition, and can also obtain security from a
security policy.
Workflow attachments
A document can be attached to a workflow. The workflow cannot alter the
document's access rights in any way.

Event and subscription access rights

Event objects and subscription objects have the same access rights.
If you modify security within an event script and you also use security
propagation, use synchronous events to minimize the chances of deadlocks that
can arise with asynchronous events.
Table 4. Access rights defined. Table of event and subscription access rights
Full Control

Modify Properties

Link

View Properties

All access rights listed in

the columns to the right
and:

Modify property values

Associate an event with a

subscription or script;
associate a subscription
with a document class or a
workflow

View properties and

security

v Modify security
v Change owner
v Delete the event or
subscription

The Link access right is hidden in the Workplace and Workplace XT applications.

Script access rights

Some scripts run with Content Engine server credentials.
When started, a script contained in any of the following objects runs with Content
Engine server credentials and is therefore considered a trusted script.
v Classification
v Event
v Lifecycle Action
Any other script runs with the credentials of the user who starts the script; the
software enforces security for that user.

Publishing access rights

Publishing creates a new document, called a publication document, according to
the specifications in the publish template selected by the user, and the optional
style template specified in the publish template. For example, a manager might
maintain a Procedures Guide (a Microsoft Word document) and publish it in
HTML format to the /Department folder, which is available to all members of the
department.
A publish template acquires security from the Publish Template class

100

Security Extract

You can think of a publish template as a wizard that Workplace users can
use to create new documents by publishing existing documents. Advanced
users create publish templates using the Publishing Designer application. A
publish template is saved as a versionable document in the Publish
Template class and acquires the class' Default Instance Security.
Access rights defined
A publish template has the same access rights as any other versionable
document except that the Publish access right appear only in Enterprise
Manager, which prevents users and authors from publishing a publish
template.
A publication document has the security specified in the publish template
To publish a document, the user selects the document and the publish
template. The user must have Publish access rights to the document and
View Content access rights to the publish template, as well as the
permission to add objects to the destination folder.
The publish template specifies the location, properties, and security of the
publication document. The template author has the following options for
applying security on the publication document:
v Specify security for the publication document
v Copy security from the document class of the publication document
v Copy security from the source document
v Use security from the destination folder (the publication document's
location)
v Apply security from a security policy
See Specify publication document security in the Publishing Designer
Help for more information on these options.
Republishing
When an author updates a previously published source document, the
author might also want to update the publication document. The publish
template specifies what occurs when a source document is republished. A
republished document can replace the existing publication document or
add a version to it, and:
v Copy security from the previous version, if any
-orv Apply security specified in the publish template
Deleting the source
The publish template specifies whether to delete publication documents
when the source is deleted (a source document can have many publication
documents). To delete a published source document, a Workplace user
must have Owner Control of the source and any publication documents
deleted with it. If the user has insufficient access rights for one or more of
the deletions, the operation results in an error and no deletions occur.
Style template
A style template, created on the Content Engine using the Publishing Style
Template Manager, specifies how to translate a document from its original
format into HTML or PDF. No special security settings are required as the
Transformation Engine takes ownership of each publish request in its
queue and assumes that the user has Full Control.
Authorization

101

Related information:
Specify publication document security

Search access rights

A stored search or search template is stored as a versionable document in the
Stored Search class.
For security purposes, a search is like any other versionable document except that
the Publish access right is hidden except in Enterprise Manager, which prevents
users and authors from publishing searches. See the Search Designer Help for
information on creating searches.
Tip: A stored search appears on the Workplace and Workplace XT browse pages; it
looks and acts like a folder. A search template appears on both the search and
browse pages; the user usually must complete the search criteria and then execute
the search.
Acquisition and inheritance
The user who creates a search specifies its security. Unless the user makes
a change, the search acquires the security of the Stored Search class along
with any security policy that might be assigned. Subsequent updates to the
Stored Search class have no effect on existing searches.
A stored search can optionally inherit from a folder security parent and
from a security policy.
Access rights defined
Table of search access rights
Access right

Meaning

Owner Control

Any operation including modify security, change owner,

and delete

Minor Versioning

Not supported in Search Designer

Major Versioning

Check out and check in the search as a major version,

cancel a checkout

Modify Properties

Edit custom properties, rename the search

View Content

Execute the search, view search criteria, copy the search

View Properties

View properties and security

Publish (visible only in Enterprise Manager)

Publish a stored search or search template

Using searches in Workplace and Workplace XT

Workplace and Workplace XT users have various ways to access
documents.
v To execute a search, the user must have at least View Content access
rights to the search.
v A user who browses to a document or search must have at least View
Properties access rights to the folders in the path.
v A search can retrieve documents that the user could not access by
browsing.
v For a property search, the document list includes a document if the user
has at least View Properties access rights to the document.

102

Security Extract

v For a content search, the document list includes a document if the user
has at least View Content access rights to the document.

Document entry template access rights

The document entry template provided by Workplace or Workplace XT is an
alternate Add document wizard.
The document entry template is created using the Entry Template Designer
application. It can set a new document's security or allow the user to set it. You
can also use Entry Template Designer to create alternate wizards for adding folders
and custom objects.
An entry template is saved as a versionable document in the Entry Template class
and acquires security from the class. An entry template is like any other
versionable document with respect to security. Entry templates can only be
modified through the Entry Template Designer if the user has permission to
promote a version (Major Versioning).
Related information:
Entry Template Designer

Workflow rosters and queues

Process Engine defines and enforces security for the rosters and queues used in
processing workflows.
Workflow security
Using Process Configuration Console, you can assign access rights to
workflow rosters, work queues, component queues, and user queues. The
following table describes what each access right allows you to do.
Table of access rights you can assign to workflow rosters, work queues, component queues, and user queues
In a...

having this access right...

means you can...

Workflow roster

Query

View the roster summary of the work

item. You can also view the work
item itself if you have read access to
the queue containing the work item.

Create

Launch a workflow.

Query & Create

Do both of the above.

Authorization

103

Table of access rights you can assign to workflow rosters, work queues, component queues, and user queues
In a...

having this access right...

means you can...

Work or component queue

Query

View work items.

Process

Lock, modify, save, and complete

work items.
(The Process option alonewithout
Queryis valid only if there are no
other users with the Query option
selected.)
Note that Process access applies to
the queue in which the work item is
locked, rather than to the destination
queue (the queue to which the work
item is dispatched upon completion
of the step). The destination is under
system, not user, control.

Query & Process

User queue (a database table with a

Query
server specification, such as Inbox(0))
Query & Process

View and process work items in the

queue.
View work items.
Lock, modify, save, and complete
work items.
Note that Process access applies to
the queue in which the work item is
locked, rather than to the destination
queue (the queue to which the work
item is dispatched upon completion
of the step). The destination is under
system, not user, control.

User queue (user's subset of work

items in the queue, such as Inbox)

No access rights

View work items assigned to you. In

addition, you can lock, modify, save,
and complete work items assigned to
you.
Note that you do not have full access
to the work itemyou can only see
and modify those data fields,
workflow groups, and attachments to
which the workflow author has given
you access.

Query
Query & Process

View work items assigned to you.

Lock, modify, save, and complete
work items.
Note that Process access applies to
the queue in which the work item is
locked, rather than to the destination
queue (the queue to which the work
item is dispatched upon completion
of the step). The destination is under
system, not user, control.

104

Security Extract

Important tips regarding security

The following are several items to be aware of when assigning access
rights to workflow rosters and queues.
Table of important tips when assigning access rights to workflow rosters and queues
If...

then...

the user is a member of the Process Engine

Administrator Group pe_admin_group,

the user automatically has full rights to each

roster and queue, even if you don't explicitly
assign him access rights.

you do not assign anyone to a specific access

you give everyone this specific access right
right for a roster or queue,
to the workflow roster or queue. For
example, if you only assign Query access
rights to a user, the user can still create or
process workflows if you have not explicitly
assigned those access rights for the
workflow roster or queue, respectively.
Tip: To give a specific access right to all
users, leave the access right blank. Do not
assign an all-inclusive group such as
Domain Users (Active Directory). Assigning
large groups to a workflow roster or queue
can adversely affect database and memory
usage.

Important: To prevent (nearly) everyone from accessing a workflow roster

or queue, assign at least one user to each possible access right for the
workflow roster or queue. For example, to prevent most access to a queue,
assign the Query & Process access right to one member of the Process
Engine Administrator Group (pe_admin_group), who has implicit access to
the queue anyway.
Related information:
Component Integrator security issues

Object ownership
Object ownership
All objects have an owner property. Ownership of an object confers special
privileges on that object, including the right to load the object and the right
to read and modify the Permissions collection on the object and modify the
owner. (As explained below, markings can be used to override the special
privileges implicitly granted to owners.)
An object store administrator might need to take or change ownership of
an object. For example, if a user has left documents in an exclusive
checkout state but is no longer available, the administrator could take
ownership of the document and cancel the checkout.
You can take ownership of an object if you have the object's "Modify
owner" permission. You can assign ownership of an object to another
authenticated user or group if you have the object store's "Set Owner of
any object" permission.
Related topics
Take or change ownership
Authorization

105

Default Instance Security and Ownership

Each class that allows instances of itself to be created has a Default
Instance Security Descriptor associated with it, exposed as the Default
Instance Security tab in Enterprise Manager. The Default Instance Security
defines the default Permissions for new objects of that class. Default
Instance Security includes a default Owner. The behavior of the Default
Owner is as follows:
v If the Default Owner is set to a valid Security Principal, then that
Security Principal will be assigned as the owner of instances of objects
that are created.
v If the Default Owner is NULL, the owner of instances of that class will
be set to NULL.
v If the Default Owner is set to #CREATOR-OWNER, then the owner of
instances of objects that are created using the default will be set to the
identity of the object's creator.
v In all cases, the Default Owner can be overridden at object creation time
by the caller.
The default value for Default Instance Security Descriptors is established at
object store creation time. The default value for Default Owner is always
set to #CREATOR-OWNER.
NULL Owner
Objects can have NULL Owners. When the Owner is NULL, it means that
the special access rights implicitly granted to the Owner are not granted to
anyone. Access checking behavior is otherwise unaffected.
Changing Ownership
The owner of an object can only be changed to the caller's security identity
(assuming the caller has the Modify owner access right) if the caller has
the Set owner of any object right granted by the object store. The purpose
for this special capability is to provide a "back door" for allowing certain
privileged users to recover access to any object (since once ownership is
acquired, the Permissions collection can be modified and additional access
rights can be granted to any user, including the owner).
There are two exceptions to this rule:
v Exception 1 is the case when the object has a security proxy wherein
changing the owner is prohibited regardless of what privileges the caller
has been granted.
v Exception 2 is the case when the object has one or more Markings
applied that either prevent a user who has otherwise been granted Set
owner of any object from even connecting to the object at all, or mask
the Modify Owner access right even if the right to connect is granted.
Note: Even with these two exceptions, a backdoor is still available, except
that it requires a few more steps and is restricted to GCD Administrators,
that is, users granted Full Control on the EntireNetwork object (which
represents the FileNet P8 domain). GCD Administrators can update access
rights on Markings and can therefore grant themselves any rights on any
Marking.
Creator-Owner substitution
#CREATOR-OWNER is a special grantee that is a place holder for the
future owner of an object. This grantee appears in Default Instance

106

Security Extract

Security permissions lists, Default Instance Owner, Security Templates

permissions lists, and permissions lists on objects that can have security
children - Folders for instance.
Substitution of the #CREATOR-OWNER for the actual owner occurs under
the following circumstances:
v When Security Templates are applied.
v When an object inherits security from a parent.
v When a security descriptor is initialized from the class Default Instance
Security. An exception to this rule is when the Default Instance Owner is
set to NULL in which case Permissions from the Default Instance
Security that specify #CREATOR-OWNER as the Grantee are ignored
and not copied to the Permissions collection of the created object.
Restriction: Creator substitution does not occur at Permission evaluation
time. As a result, #CREATOR-OWNER does not function as a generic
macro that always evaluates to the current owner.

Property modification access

To be able to edit a property, a user generally needs Write access to the property.
However, Content Engine provides an optional way to add another layer to the
required access rights to modify custom properties. System administrators can do
this by configuring the Modification Access of property templates. (Because this
feature depends on a system property called Modification Access Required, the
acronym for modification access behavior is MAR.)
Remember: Property modification access behavior is a feature primarily intended
for the IBM Enterprise Records application, especially in connection with markings.
It is available for use by non-records management applications that need granular
control over user ability to modify properties.
About MARs
The property sheets of all property templates have a Modification Access
page that contains a list of access rights. By default, these access rights for
all property templates are unselected. If left unselected, then the property
template has no modification access behavior and "normal" property
security applies. However, if you select one or more access rights,
properties based on the property template will have different security than
normal, as described below.
Normal property security (no modification access)
Custom properties are all based on property templates. In Enterprise
Manager's Property Templates node are listed the property templates that
have been added to the object store. The property template's own ACL,
contained in its property sheet's Security page, controls who can access the
property template. Default security on property templates is one of the
decisions made by the Object Store Wizard: object store administrators
have Full Control, and object store users have View all Properties and
Read Permissions. You could change these default assignments, but only if
there is a clear reason to do so. Administration of property templates is not
made available by Workplace or Workplace XT, nor by any of the
applications based on these applicationsIBM FileNet P8 eForms,IBM
Enterprise Records, Application Integration.

Authorization

107

Security on a property that has been added to a class and then placed on
an instance of the class is governed not by the security of the property
template, but by its object's security. The initial state of the security for any
object is created from the default instance permissions defined via its class
and thereafter edited through the Security tab of the object's property
sheet. For example, the Default Instance Security of a document class is
copied onto a new document, and it is this security that governs access to
the document's properties.
However, keep in mind that property templates have a Settability setting
(found on the More tab of the property sheet) that can be configured so
that the properties based on them will be read-only, read/write, settable
only on create, or settable only on checkin. These settings take precedence
over any permissions granted by the object's security. In other words, a
property marked read-only is not modifiable even if the user is granted the
Modify all properties access right on the document. (See Property
Template properties (More tab - String), or any of the other More tab
property topics, for a description of the choices for settability.)
There are two property-related access rights that appear on the ACLs of all
securable objects:
v View all properties: whether the user can see the object's properties.
v Modify all properties: whether the user can modify the values assigned
to the properties (taking into account any settability restrictions on
modifying the property).
Document Access Control List
Bob

View all properties

Modify all properties

Alice

View all properties

Modify all properties

Document
Property A

Property Template A
Settability: Read/Write

In this graphic showing normal property security, the property template's

settability is Read/Write which carries to the property when it is added to
the document class and onto the document. The document's ACL grants
Alice permission to see and modify all properties, while Bob can see all
properties but cannot modify them. Therefore, Alice could change the
value of Property A (and any of the other readable or writable properties
contained by the document), while Bob can see Property A (and all others)
but cannot change its value.
Property security if modification access has been configured
By setting a property's Modification Access Required property, you can
establish another layer of access permissions that affects who can modify
the property. You can use the MAR to specify that certain properties can be
modified only by users with a specified set of rights, as opposed to the
"normal" condition in which users need only the Modify all properties
access right to the object.

108

Security Extract

Document Access Control List

Bob

Delete document

Alice

Delete document

Document
Property A

Property Template A
Modification Access:
Delete
Settability: Read/Write

In this graphic, Property Template A has a MAR in which the Delete

permission is set. Property A has been added to the document. The ACL
on the document permits Alice to delete the document while it prevents
Bob from deleting the document. Therefore Alice can modify Property A
and Bob cannot (assuming the property is settable).
Remember: Enterprise Manager does not collect the property modification
access settings in a single view or page.
As mentioned above, if you do not specify any values, meaning that all the
access rights on the Modification Access page are left unselected, then
there is no MAR behavior and normal property security applies. A
property template's Modification Access settings are settable only on create
and therefore cannot be changed later on.
Exceptions to the normal access requirements
As described above, setting or modifying a property generally requires
Write access to the object to which the property belongs. A different right
is required for the following actions:
v To modify Permissions, SecurityPolicy, or SecurityParent, a user requires
WriteAcl access.
v To modify the Owner property, a user requires WriteOwner access.
Related information:
Property template properties (More tab)

Required minimum access rights by operation

Explanation of the required minimum access rights required by Content Engine to
carry out document-oriented operations.
The following assumptions must be made with respect to the access right
requirements listed in this topic:
v In addition to the access rights specified below, the caller also has the minimum
access rights required to connect to the object that is the target of the operation.
(The minimum access rights required to connect to an object include Connect to
store granted by the Object Store in which the object resides, and one or more of
the following rights: View properties or Modify owner granted by the target
object; or Set Owner of any object granted by the object store.)
v No Document Life Cycle is attached.
v No Markings are applied.
v No Security Proxy is in effect.
v No Security Policy has been applied.
v There are no object properties with Target Access Required with values set.
Authorization

109

v There are no object-valued properties with a deletion action of Delete Action

Prevent.
v The caller has sufficient access rights to delete objects related by object-valued
properties that have a deletion action of Delete Action Cascade.
Tip: System properties that have this behavior include Containers, Annotations,
Workflow Subscriptions, and Dependent Documents (the latter two are
technically not system properties but are almost universally present).
v There are no properties with non-standard settability requirements (settable only
on create or settable only before checkin).
v No changes have been made to either the Owner or Permissions simultaneous to
the operation.
Create minor version
Table that maps the access rights required of the granting object to create a minor version
of a document.
Granting object

Required minimum access rights

Object Store

Create new objects

Document Class
Definition

Create instance

Document (instance
just created)

View properties
-ORModify owner
-ORSet Owner of any object
Important: These rights are not, strictly speaking, necessary to
create the object; however, it is possible for users to
programmatically create an object to which they cannot connect.

Create major version

Table that maps the access rights required of the granting object to create a major version
of a document.
Granting object

Required minimum access rights

Object Store

Create new objects

Document Class Definition

Create instance

Document (instance just created)

View properties
-ORModify owner
-ORSet Owner of any object (see NOTE above)

Checkout minor version

110

Security Extract

Table that maps the access rights required of the granting object to checkout a minor
version of a document.
Granting object

Required minimum access rights

Object Store

Create new objects

-ANDModify existing objects

Document Class Definition

Create instance (for creating the reservation)

Document (target document)

Minor versioning OR Major versioning

Checkout major version

Table that maps the access rights required of the granting object to checkout a major
version of a document.
Granting object

Required minimum access rights

Object Store

Create new objects

-ANDModify existing objects

Document Class Definition

Create instance (for creating the reservation)

Document (the target document)

Major versioning OR Minor versioning

Cancel checkout
Table that maps the access rights required of the granting object to cancel a checkout of a
document.
Granting object

Required minimum access rights

Object Store

Delete objects

Document (the reservation)

Delete
-ORMinor versioning
-ORMajor versioning

Other

If exclusive reservation, the caller must be the same

as the user who did the checkout or have both
AccessRight.DELETE and
AccessRight.WRITE_OWNER for the reservation
object. (These access rights are included in
Enterprise Manager's Full Control access level to the
document.)

Check in minor version

Table that maps the access rights required of the granting object to check in a minor version
of a document.
Granting object

Required minimum access rights

Object Store

Modify existing objects

Document (on the reservation)

Minor versioning
Authorization

111

Table that maps the access rights required of the granting object to check in a minor version
of a document.
Granting object

Required minimum access rights

Other

If exclusive reservation, only the user who checked

out the document can check it in.

Check in major version

Table that maps the access rights required of the granting object to check in a major version
of a document.
Granting object

Required minimum access rights

Object Store

Create new objects

Document (on the reservation)

Major versioning

Other

If exclusive reservation, only the user who checked

out the document can check it in.

Promote or demote
Table that maps the access rights required of the granting object to promote or demote a
document.
Granting object

Required minimum access rights

Object Store

Modify existing objects

Document (on the reservation)

Major versioning

Delete minor or major version

Table that maps the access rights required of the granting object to delete the minor or
major version of a document.
Granting object

Required minimum access rights

Object Store

Delete objects

Document (on the target document)

Delete

Security policies
A security policy serves as a collection of security templates, each of which
contains a predefined list of permissions, or Access Control Entries, that can be
configured to apply to a document, custom object, or folder.
Except where specifically mentioned, this topic describes the association of security
policies with documents and document classes. To fully understand this topic, you
should be familiar with document versioning and the versioning states Released,
In Process, Reservation, and Superseded.
Remember: Security policies are just one way to apply ACEs to an object's ACL.
The other sources are the object's class, a security parent, direct edits to the object's
security, and by programmatically setting the object's access rights.
About security policies on page 113
About templates on page 113
Assigning security policies on page 114
Preserve Direct ACEs on page 115

112

Security Extract

Effects of changes on page 115

Rules of association on page 116
Support in Workplace and Workplace XT on page 117
Custom objects and folders on page 117
Related information:
Versioning states

About security policies

Security policies allow system administrators to apply access control to large
numbers of documents without directly editing the ACL on each document.
Security policies, in conjunction with versioning states, allow a system
administrator to configure the system to automatically modify ACLs on documents
when their versioning state changes. For example, the administrator can configure
the system to automatically grant access to a document to a wide audience when it
is released.
Sequence tables detail the versioning states through which documents proceed
following check in, check out, and other versioning actions.
To create a security policy, you run one of the security policy wizards provided by
Enterprise Manager and by Workplace and Workplace XT. The wizard creates a
security policy that the system administrator can then customize by adding
security templates. Once created, the security policy can be associated with
documents, folders or custom objects. Alternatively, the administrator can make the
security policy the default value for the security policy property for one or more
classes. Making a specific security policy the default for a class ensures that all
instances of the class are associated with that security policy unless the value is
explicitly overridden.
The security policy class can have subclasses, just like the other classes in
Enterprise Manager's "Other Classes" node. The security policy wizard lets you
create a security policy using a subclass, whereas Enterprise Manager's wizard
supports only the base class. You could also use one of the supported FileNet P8
APIs to create a security policy using a subclass.
Security policies can be exported and imported between object stores.
Related information:
Versioning actions
Create a security policy
Assign a security policy
Exporting and importing

About templates
A security policy serves as a collection of security templates, each of which
contains a predefined list of permissions, or Access Control Entries ACEs), that can
be configured to apply to a document, custom object, or folder.

Authorization

113

Except where specifically mentioned, this topic describes the association of security
policies with documents and document classes. To fully understand this topic, you
should be familiar with document versioning and the versioning states Released,
In Process, Reservation, and Superseded.
Remember: Security policies are just one way to apply ACEs to an object's ACL.
The other sources are the object's class, a security parent, direct edits to the object's
security, and by programmatically setting the object's access rights.
There are two kinds of security templates:
v Versioning security templates automatically update the permissions on
documents as their versioning state changes to one of the four possible
document versioning states: Reservation, In Process, Released, and Superseded,
for which there are four corresponding versioning security templates.
v Application security templates can be configured to apply a list of permissions
to a document, custom object, or folder according to logic programmed into an
application using P8 APIs.
A security template applies to a document version if (1) the document version has
an associated security policy, and (2) the associated security policy has a template
for the document's version state. For example, if the document goes into the
Released versioning state, and the security policy has a Released template, then the
permissions listed in the Released template apply.
Templates cannot be shared between security policies and cannot be independently
loaded or saved apart from their security policy. Permissions on an object that
originate from a security policy will appear on the object's ACL with a Source type
of Template. As such they cannot be directly edited using Enterprise Manager's
Access Control Editor or by using the FileNet P8 API.
Newly created security templates contain no default permissions placed on them
by the Content Engine. Administrators can add permissions at creation time while
running the security policy wizard, or at any later time. Applying a template that
contains no permissions to an object will have the effect of removing any existing
permissions on that object that were previously applied by a security policy.
Related information:
Versioning properties
Edit a security policy

Assigning security policies

Security policies can be assigned to a document or to document versions.
Security policies can become associated with documents in two ways:
By assigning it as the default security policy for a document class.
In this case, the default security policy is automatically associated with the
object instance at the time of creation unless the default is explicitly
overridden. The default security policy will continue to be associated with
all versions in the document's version series, unless you do something to
change the association. By having the same security policy for all
documents in a class, you have a simple, easily understandable and
manageable security scheme. If, on the other hand, you change a single
document version's class, the new class's default security policy (provided
there is one) would be immediately applied to that document version and

114

Security Extract

the old security policy (if there was one) would be removed. However,
changing a version's class does not override a security policy that was
directly assigned to that version by a user, nor does it change any earlier
versions of the same document.
By assigning it to a specific document version.
Each document version in a version series could, theoretically, have a
different security policy assigned to it. The document class's default
security policy will be placed on each instance of the class, but you can
override the default with a different security policy. You would do this
manually, using Enterprise Manager to open the document version's
property sheet and changing the security policy. This would be
cumbersome and difficult to manage from a system administrator's point
of view, and should be done only as an exception to the normal
application by the document class.

Preserve Direct ACEs

In addition to the list of security templates associated with it, each security policy
has an important property called Preserve Direct ACEs (also called Preserve Direct
Permissions). This property, which can be set to either True or False, governs
whether or not direct permissions are preserved in the target object's ACL when a
security template is applied to it. The value of this property applies to all the
templates contained by the security policy.
By default, this property is set to True, because this is likely to be the most
common use case. In fact, the security policy wizard does not ask you to set a
value and just sets it to True. After you have created the security policy, you can
open its property sheet's General tab to view or change the Preserve Direct ACEs
setting.
Related information:
Change "Preserve Direct ACEs"

Effects of changes
Documents get their security policy from the default security policy of their class,
if the class has one. Therefore, if you change a document's class to a class that has
a different default security policy, the document will immediately take on that new
security policy. This also means that if you change a document's class to one that
has a security policy that is not the class' default (that is, the new class has a
security policy associated with it that was not its original default policy), the
document will not take on that new policy but will keep its association with the
former security policy.
These scenarios describe the security behavior of changing a document's class, and
assume that the security policies in question have appropriate templates.
If you change a document version's class, and both the new class and the old class
have different default security policies, the permissions applied by the old security
policy are immediately removed and the permissions of the new security policy are
immediately applied to the version. The permissions already applied by the old
document class' Default Instance ACL are not changed. In other words, the new
document class does not apply its Default Instance permissions to the document.
If you change a document version's class, and the version has a policy that does
not match the previous class, the software assumes that the version has a security
policy that was applied by a user and leaves it as is.
Authorization

115

If you change a document's class, and the old class has a security policy and the
new class does not, the permissions applied by the old security policy are
immediately removed. Since the new class has no security policy, the permissions
on the document would come from the other usual sources: from being directly
applied, from the Default Instance ACL of the new document class, and from a
security parent, if there is one.
Related information:
Change document class

Rules of association
Security policies have several rules of association which affect their behavior.
Here are the rules of association for security policies:
v A security policy can contain both versioning and application templates.
v A security policy can contain zero or more application security templates and
from zero to four versioning security templates. Although it is permissible for
security policies to have no templates, it is effectively only a placeholder until
you add one or more templates. Workplace and Workplace XT require you to set
at least one template.
v A security template can have zero or many permissions assigned to it. A
template containing no permissions is allowed programmatically and by
Enterprise Manager's security policy wizard. The security policy wizard
provided by Workplace and Workplace XT require that you add at least one
permission to a template.
v A security policy can be assigned to zero or many folders, zero or many
documents, or zero or many custom objects, or any combination of the three
object types.
v Documents, folders, and custom objects can have zero or one security policy.
v The class definitions for documents, folders, custom objects, and their
sub-classes can each have zero or one default security policy associated with
them. When instances of the class are initially created, the instance will take the
default security policy if there is one. In the case of documents, the default
security policy will be passed to subsequent versions, unless a different security
policy is explicitly provided. In this case, the new security policy is passed to
subsequent versions; it will not automatically revert to the class default.
v A single security policy can be associated with many document, folder, and
custom object classes.
v A single security template cannot be shared between security policies. Each
security template belongs uniquely to the security policy it is associated with.
v The versioning security templates in one security policy have no relationship
with those in another security policy, even though they have the same default
names (Released, In Process, Reservation, Superseded). These default names can
be changed.
Changes to an existing security policy do not propagate to existing documents
until the version state changes or the next version is created. If, however, you
change the document's current policy to some other security policy by directly
changing the document version's property sheet, then these changes are
immediately applied to the version and the permissions applied by the former
security policy are immediately removed.

116

Security Extract

Related information:
Edit a security policy
Rename a security template

Support in Workplace and Workplace XT

Workplace and Workplace XT fully support the effects that security policies have
on document security.
Advanced users of these applications with authorship permissions can run the
application's security policy wizard and create security policies. The user can then
assign the security policy to individual documents wherever the security page is
presented (providing the user has Modify Permissions access) and on multiple
documents at one time using the My Search page results list.
Because the applications do not permit editing classes, you must use Enterprise
Manager to assign a security policy as the default for a document class. The usual
way to use a security policy is to assign it as the default of a document class, and
then let the class apply the policy to new instances. This ensures that all
documents in that class will be associated with a single security policy.

Custom objects and folders

The custom object class and the folder class can also be assigned a default security
policy that will be associated with instances of those classes, just like they are for
documents.
There is an important difference: custom objects and folders can only receive
permissions from application security templates, since versioning security
templates can only be applied to documents. The relationship between a custom
object or folder and an application security template is done using a GUID
assigned to the template. The GUID is called by the application whenever the
program's logic requires the security state described by the template. Associations
can only be made by customized applications created using a FileNet P8 API.
Enterprise Manager's security policy wizard lets you create application security
templates as part of defining a security policy. It can also automatically assign a
GUID to the new template or use a 32-bit GUID that your own program generates.

Storage area security

Security must be configured on the shared directory location under which file
storage areas and content cache areas will be created.
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:
v Database storage area, in the same database where non-content bearing objects
are stored, is automatically included and available when you create an object
store. No additional security configurations are needed.
v File storage areas located on either a Windows or a UNIX directory.
Authorization

117

v Fixed storage area, requiring a fixed content device provided by one of the
supported providers.
v Content cache areas, which deliver better performance by providing local storage
of frequently accessed documents without having to request them over the
network.
File storage area security
Content Engine on UNIX, file storage on Windows on page 121
Content cache area security on page 121

File storage area security

Configuring file storage area security ensures that content files are safe from
unauthorized usage.
Content Engine operating system account
The Content Engine operating system user (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 operating system 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 operating system 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.
v For Windows-based Content Engine and file storage areas, these
operating system login accounts must reside in the same Windows
domain or in trusted Windows domains.
v For UNIX-based Content Engine and file storage areas, security is
configured using NFS, the protocol suite developed by Sun
Microsystems that allows different makes of computers running different
operating systems to share files and disk storage. Configuring NFS
security should be done by experienced network administrators. Consult
your operating system documentation for details.
v For a mixed environment of UNIX and Windows, you will need an NFS
Gateway product in order to provide interoperability between
Windows-based and UNIX-based clients.
Important: When we speak of Content Engine running under an
operating system 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 operating system 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 operating system 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 operating system user account,

118

Security Extract

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.
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:
v Remove unwanted inherited or inheritable permissions. This can also
include preventing the root directory from inheriting permissions from
its parent directory, since the parent will normally grant Read access to
general groups like 'users'. Be careful not to accept the default security
setting when creating a root directory, since the default will normally
grant Read access to a broad set of users.
v Grant the ce_os_user full control access to the root directory. Make this
inheritable by all folders and files created under the root.
v As explained above, you can optionally grant full control access to the
root directory to an operating system group account that the ce_os_user
belongs to. This must also be made inheritable by all folders and files. If
you use a group account, it is not necessary to grant access to the
individual user accounts.
v If there is an administrative user or group that will need access to the
files of the store, then grant Full Control access to the root folder to
these accounts and make the permissions inheritable by all folders and
files.
v If you are running Content Search Engine (K2) administration servers,
you must grant K2 access to any Content Engine file storage area that
will be indexed, as follows:
Windows-based file storage areas
The user that the K2 service runs as must have Read access to
the file storage area root directory. This is an operating system
user who is defined as the logged on user of the service.
UNIX-based file storage areas
One way to grant access is to set the Set UID bit of all the K2
program files, and then also set the owner of each program file
to a particular user. Then this particular user must have
Read/Execute access to the file storage area root directory.

Authorization

119

Important: If you are using a group instead of individual user accounts,

then the K2 operating system user must be made a member of the
operating system group.
Important: On an upgraded file storage area, the Verity collections will
be in a subdirectory of the file storage directory. In this case, the K2
operating system user must be granted the access described above to
this collections subdirectory.
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.
Important: 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 operating system 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:
v USER: Grant the ce_os_user account read, write, and execute permissions.
v GROUP: Grant the Content Engine operating system group account
read, write, and execute permission. Note that this will apply to either a
private group (same Id as the user), or a specific operating system group
account, depending on how ce_os_user is configured. (Use of a
non-private group account to control security is optional.)
v OTHERS: Do not grant access. Be careful not to allow read access to
Others.
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.

120

Security Extract

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.
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.
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.

Target access required

Target Access Required is a feature of object-valued properties that allows an
application designer to specify the access rights that are necessary on the target
object in order to assign it to a property.
This feature is implemented as a property named Target Access Required on the
PropertyDefinitionObject class. Property Definition Objects are used to define
object-valued properties as part of Class Definitions. The Target Access Required
property specifies the access level that the caller must be granted by the target
object in order to assign it as the value of the object-valued property being defined.
The default value for Target Access Required is View properties, that is, if the
Target Access Required is not specified then the caller must have at least Read
access on the target object to refer to it using an object-valued property.
Example 1
Suppose there are two classes, A and B. Class A includes an object-valued
property named OVP_B. The definition for OVP_B specifies that its
required class is "B" and the Target Access Required is Modify All
Properties. This means that the value of A.OVP_B, when it is set, must
always be an instance of class B. It also means that in order assign a value
to A.OVP_B the caller must be granted Modify All Properties by the
instance of B that is the target of the assignment.

Authorization

121

Consider the following code snippet that illustrates assigning the value of
an instance of class B to an instance of class A's OVP_B property:
Dim IA as A
Dim IB as B
Set IA = ObjectStore.ConnectObject("A", guidIA)
Set IB = ObjectStore.ConnectObject("B", guidIB)
IA.OVP_B = IB

In this example, the target object is IB; therefore the caller must have
Modify All Properties access on IB or the assignment will fail.
Example 2
Suppose there are two additional classes, C and D. Class C includes an
object-valued property named OVP_D. The definition for OVP_D specifies
that its required class is "D"; however the Target Access Required is not
specified. This means that the value of C.OVP_D, when it is set, must
always be an instance of class D; however, since the Target Access
Required on the definition for OVP_D is not specified, the caller only
needs to be granted View properties by the instance of D.
Consider the following code snippet that illustrates assigning the value of
an instance of class D to an instance of class C's OVP_D property:
Dim IC1 as C
Dim ID1 as D
Set IC1 = ObjectStore.ConnectObject("C", guidIC1)
Set IC1 = ObjectStore.ConnectObject("B", guidIB)
IC.OVP_D = ID

In this example, the target object is IC. There is no Target Access Required
on the property definition for OVP_D therefore it defaults to View
properties which means that the caller must have Read access to IB or the
assignment will fail.

Understanding security inheritance

Security inheritance is one of the powerful features of the IBM FileNet P8 security
design.
Security inheritance refers to the passing of permissions from a parent object to a
child object. For instance, a folder could be the parent of a subfolder or a
document; a document could be the parent of an annotation. The child object can
inherit the security permissions from its parent object. Because of inheritance, the
security administrator can apply security updates to many objects in one operation
by setting the permissions at the parent level which can then be inherited by the
children at various, configurable levels.
Some important characteristics of inherited permissions are:
v Inherited permissions have a source type of Inherited. For more information on
the different source types, see About access rights.
v You cannot modify inherited permissions on a child object. You must modify the
permissions on the parent object. Inherited permissions are displayed as disabled
in security interfaces like Enterprise Manager's security editor. Modifications
made on the parent object will be automatically applied to the inherited
permissions on the child objects after the next metadata refresh.
v When you delete a parent, the parent's permissions that were previously
inherited will also be deleted from the child objects.

122

Security Extract

v When you change the inheritable permissions on a parent object, the change
applies to all versions of a security child that is inheriting those permissions.
v Inherited permissions are a lower precedence than other sources (default, direct,
or template) and so can be overridden by them. This is an issue only when
using deny permissions, since using only allow permissions causes them all to
be combined, no matter what their source.
v Security children can have multiple parents, and parents can themselves have
parents. The effect of more than one parent is to combine all their permissions
into a set of inherited denies and a set of inherited allows (the denies take
precedence).
v Normally, inherited access rights also apply to the parent object itself, for
example when you use This object and all children. However, to apply
inherited access rights only to children and not to the parent, use All children,
but not this object or Immediate children, but not this object. This is
particularly useful for access rights like Delete, where you want to allow the
children to be deleted, but not the parent.
v For more information, see Configure a folder's security inheritance and the
Configure security inheritance.
v To enable inheritance on folders, use the Inherit parent permissions check box,
on the folder's General tab.
Inheritable depth (Apply to)
Each ACE has an inheritable depth setting that is invoked if the ACE is
configured to be inherited by a child object. The inheritable depths are:
This object only
This ACE would not be inherited even if it were configured for
inheritance.
This object and immediate children
This ACE applies to the object and would be inherited by the
parent object's children, but not by the child object's children. After
inheritance takes place, the child ACE will have an inheritable
depth of This object only.
This object and all children
This ACE applies to the object and would be inherited by every
generation of the parent object's child objects. After inheritance
takes place, the child object's ACE will have an inheritable depth of
This object and all children.
All children but not this object
This ACE would be inherited by every generation of the parent
object's child objects, but does not affect the parent object itself.
Immediate children only, but not this object
This ACE would be inherited only by the parent object's immediate
children, but not by further generations, and does not affect the
parent object itself.
The Enterprise Manager security editor lets you set inheritable depth in its Apply
to section. See Configure inheritable depth for more information.
Important: The setting for inheritable depth does not apply to situations where the
ACE is being applied in non-inheritance conditions. For example, an ACE on a
Default Instance Security ACL of a class will be applied to an instance of that class,

Authorization

123

even if the ACE has an inheritable depth of This object only, because the
application of security from a Default Instance ACL is considered default security
and not inherited security.
Security Parent, Security Folder, Security Proxy Type
You can configure the relationship between a parent and child object in
several ways.
Security Parent
Restriction: This feature has been deprecated as of 4.0.1, although
it is still available for compatibility with earlier versions. Any
existing applications that use this feature will continue to work as
before, without change.
When a folder's Security Parent property is configured, that folder
becomes a Security Parent for the documents and custom objects
contained within it. That is, inheritable permissions are inherited
by the Security Parent folder's documents and custom objects.
Internally, setting the SecurityParent property on a RCR or DRCR
will be transformed into setting the SecurityFolder property on the
object that is the head of the RCR/DRCR (a document or custom
object) to its tail (the folder). You can see the Security Parent
property on all documents and custom objects: in Enterprise
Manager, right-click the document or custom object, select
Properties, then click the Properties tab and scroll down the list of
properties.
Security Folder
A Security Folder is a folder from which an object inherits security,
but there is no requirement that its security children be filed in the
folder. You can see the Security Folder property on all documents
and custom objects: in Enterprise Manager, right-click the
document or custom object, select Properties, then click the
Properties tab and scroll down the list of properties.
Security Proxy Type
Content Engine provides extensible security parent relationships by
means of the Security Proxy Type property placed on the metadata
of custom object-valued properties. This property would be added
to a security child's class and the values set into it establish that
child's security parent. You can add this property to any class of
objects as required by your security design. An object can have
many such Security Proxy Type properties, that is, many security
parents with the inherited ACEs from each being merged together
and contributing with equal priority to the access check that
produces the final security mask.
You can apply the Security Proxy Type property to objects other
than folders. For example, you could add a Security Proxy Type =
Inheritance property to the class of a document and then later set
that property in the document (the security child) to a custom
object (the security parent). You can see the Security Proxy
property on all objects: in Enterprise Manager, right-click the
object, select Properties, then click the Properties tab and scroll
down the list of properties.
Configuring inheritance

124

Security Extract

For configuring inheritance on documents and custom objects, see

Configure a document's security parent and Configure a folder to be a
security parent.
Folders have an Inherit parent permissions check box on the General tab
of their property sheets in Enterprise Manager. This check box governs
inheritance between folders. When you select it, the folder will inherit
permissions from its parent folder if the parent folder has inheritable
permissions. This option is selected by default. Clearing the check box
removes any ACEs that were formerly inherited from the parent folder.
Subclassed permissions are copied, not inherited
When you make a new subclass from a class definition, some permissions
are passed from the parent class definition to the new child class definition
in a manner that is not inheritance. When you make a new subclass, those
permissions of the originating class definition that have a Source type of
Default or Direct and are of inheritable depth "This object only" are exactly
copied to the new subclass with a source of Default and no change in
inheritable depth.
During subclassing, the child class receives the ACEs of its parent as
described in the following table. Notice that Default permissions with
inheritable depth of This object only are not inherited by the child; rather
they are copied without change and are therefore modifiable on the child
object.
Table that maps how a child class receives the ACE of its parent and whether it is copied or inherited.
If the ACE on the parent class is marked...

...then the same ACE on the subclass will

be marked...

Inheritance or
copy?

Source = Default

Source = Default

Copy

Inheritable depth = This object only

Inheritable depth = This object only

Source = Direct

Source = Inherited

Inheritable depth = This object and immediate

children

Inheritable depth = This object only

Source = Direct or Inherited

Source = Inherited

Inheritable depth = This object and all children

Inheritable depth = This object and all

children

Source = Inherited

Does not appear. Inheritance is stopped by

the inheritable depth.

Not applicable

Source = Direct or Inherited

Source = Inherited

Inherited

Inheritable depth = All children but not this

object

Inheritable depth = This object and all

children

Source = Direct

Source = Inherited

Inheritable depth = Immediate children only, but

not this object

Inheritable depth = This object only

Inheritable depth = This object only

Inheritance

Inheritance

Inherited

Summary of security sources

The following table summarizes how objects receive initial security.
Security inheritance takes place only if the source class or object has
inheritable permissions:

Authorization

125

Initial security comes

from...

Object
Folder

The
DefaultInstancePermissions
of its class, or directly set
when creating.
Security policy, if
configured.

Document

The
DefaultInstancePermissions
of its class, or directly set
when creating.
Security policy, if
configured.

Custom
object

The
DefaultInstancePermissions
of its class, or directly set
when creating.

Inherits additional security

from...
Its parent folder (the folder
immediately above), if the
Inherit parent permissions
check box is selected on the
child folder.

Its security can be inherited by...

Child folders, if Inherit parent
permissions is enabled on those child
folders, and if there are inheritable ACEs.
Documents or custom objects that
consider the folder its security folder, if
the folder has inheritable ACEs.

Custom object-valued
properties with Security Proxy By other objects (document, custom
Type set.
object, folder) through a Security Proxy
Type property and acting as security
parent.
Security folder, if configured
using Security Parent or
Security Folder properties.

Any annotations assigned to the

document version, if the document has
inheritable ACEs.

Custom object-valued
properties with Security Proxy By other objects (document, custom
object, folder) through Security Proxy
Type set to "Inheritance". See
Configure security inheritance. and acting as security parent.
Same as Document.

By other objects (document, custom

object, folder) through Security Proxy
and acting as security parent.

Security policy, if
configured.
Annotation

The
DefaultInstancePermissions
of its class, or directly set
when creating.

Document, Folder, Custom

Object.

None.

Other
Classes

Its parent class.

Any additional parent classes

up to the top of the class
hierarchy.

Child classes, if there are inheritable

ACEs.

Related information:
Folder properties (General tab)
Inheritance between classes

126

Security Extract

Directory service providers

Content Engine retrieves security data from directory servers for the purpose of
authenticating security principals and authorizing users and groups. Both
authentication and authorization rely on a directory service repository.
Introduction
Content Engine does not implement its own authentication module.
Instead, it uses the Java 2 Enterprise Edition (J2EE) application server's
authentication mechanism. Before clients can log in to a Content Engine
server, the application server's authentication providers must be configured
to point to specified directory servers.
Content Engine's security objects, such as realms, groups and users, are
stored in directory servers. Content Engine retrieves those objects through
a Directory Service Provider layer. There are different provider
implementations for different types of directory servers.
A directory server is divided into partitions, each of which is called a
naming context (or namespace). There are different types of naming
contexts, such as the configuration naming context which holds
configuration information, and data naming contexts, which contain all
directory data. Each data naming context is defined as a Content Engine
realm. Each realm contains groups and users.
FileNet P8 has been designed and extensively tested and optimized for
directory servers with very large numbers of users. Optimization has
particularly focused on FileNet P8's querying for accounts using pattern
matching (starts with, exact match) and whether the search is optimized
for short name or display name.
Terminology and basic concepts
Distinguished Name
A name that uniquely defines a directory entry within an LDAP
server. The DN contains one component for each level of the
directory hierarchy from the root down to the level where the
entry resides. A typical distinguished name might be:
CN=StephenHawking,CN=Users,DC=Filenet,DC=Com. This
distinguished name identifies the Stephen Hawking user object
in the Filenet.com domain.
User Principal Name
A user principal name (UPN) is a friendly name that is short and
easy to remember. The user principal name consists of a shorthand
name that represents the user and typically the DNS name of the
domain where the user object resides, or any other designated
name.
The user principal name format consists of the user name, the at
sign (@), and a user principal name suffix. For example, the user
James Smith, who has a user account in the reskit.com domain,
might have the user principal name [email protected]. The user
principal name is independent of the distinguished name of the
user object, so a user object can be moved or renamed without
affecting the user principal name.
Copyright IBM Corp. 2006, 2011

127

Among the types of directory servers that Content Engine

supports, only Active Directory has a UPN attribute. The attribute
name is userPrincipalName.
Short Name
Short name is a property in both Content Engine User and Group
classes:
v User.ShortName
v Group.ShortName
User short names and group short names must be unique across all
configured directory servers. Content Engine uses the account SID
as its unique identifier, while Process Engine uses the shortname as
its unique identifier. Therefore, Process Engine requires that the
directory server attribute that you assign as the user's shortname
have only one single value, even if it is a multi-valued property.
User short name is also persisted to a Content Engine object store
as a property such as Document.Creator. User.ShortName and
Group.ShortName are configurable through the Configuration
Manager, the Content Engine API, and Enterprise Manager.
Values for user and group short names have the following
restrictions:
v The short name cannot be a null value.
v The short name cannot contain any of the following special
characters: = \.
Realm In this document the term realm describes a base object for
searching the directory. When Content Engine interacts with a
directory service, most operations are done in the context of a
realm.
FileNet P8 domain
When you install and configure Content Engine, you create a new
FileNet P8 domain which provides the security context for
authenticating applications. In order to avoid possible confusion
between the FileNet P8 domain and Windows domains, these
terms are typically spelled out completely. For more information,
refer to Administering IBM FileNet P8 > Administering Content
Engine > FileNet P8 domain > Concepts: FileNet P8 domain.
Authentication Provider
All interaction with the directory server that has been configured
during installation as the FileNet P8 authentication provider is
read-only and is initiated only from Process Engine and Content
Engine servers.
Login FileNet P8 lets you configure a login supporting a number of
different parameters. Because authentication and login attributes
are persisted in databases, workflow definitions, and stored
searches you cannot change the attribute at a later time, including
during upgrade. See the sections describing logging on in the topic
that describes your directory server.
Find

128

Security Extract

Documentation refers frequently to finding users and groups. This

refers to the activities of Enterprise Manager's Select Users and
Groups dialog box, which Enterprise Manager uses to search for
accounts to add to the ACL of an object, and also to similar

controls used in Workplace, Workplace XT, and Process Task

Manager. On the Content Engine API level, "finding" refers to the
FindUsers and FindGroups methods.
SSL

You should configure SSL to avoid passing credentials in clear text

between the FileNet P8 servers and the directory server.

Group support
FileNet P8 supports groups that can include any number of users
and other nested groups. Also, it honors any account states and
restrictions (such as whether disabled and login hours) defined by
the directory server.
Configuration Overview
Directory configuration for Content Engine is conducted in the following two
areas: authentication and authorization. Content Engine does not support different
types of directory servers in the same Content Engine domain.
Directory Configuration for Authentication
Directory configuration for authentication, including configuring login
formats, occurs in the application server's authentication providers and is
done using FileNet P8 Configuration Manager.
Content Engine server does not implement its own authentication module.
Instead, it uses a J2EE application server's authentication mechanism.
Directory Configuration for Authorization
A GCD administrator (gcd_admin) can log in to Enterprise Manager and
configure the direct connection between Content Engine and the directory
service.
Third-party developers can also directly call the Content Engine APIs to
automatically configure it.
CA Directory
IBM Tivoli Directory Server on page 133
Novell eDirectory on page 138
Oracle Internet Directory on page 142
Oracle Directory Server Enterprise Edition on page 146
Windows Active Directory on page 150
Windows Active Directory Lightweight Directory Services (AD LDS) on page
160
Directory service performance on page 166

CA Directory
IBM FileNet P8 supports CA Directory for providing directory services.
Overview (CA Directory)
Support matrix (CA Directory) on page 130
Directory Configuration Properties (CA Directory) on page 131
Get and search operations (CA Directory) on page 133

Overview (CA Directory)

IBM FileNet P8 supports CA Directory for LDAP services.

Directory service providers

129

One instance of CA Directory can have multiple data naming contexts. Because
each CA Directory data naming context is mapped to a Content Engine realm, one
CA Directory can be mapped to multiple Content Engine realms. For each realm,
you need to create an application server authentication provider and a
DirectoryConfigurationCA object, so that there is a one-to-one relationship between
Realm object and authentication provider, and also a one-to-one relationship
between Realm object and DirectoryConfigurationCA object. For each
DirectoryConfiguration object, FileNet P8 extracts the realm name from the
specified UserBaseDN property value by comparing it with each data naming
context. For example, if the UserBaseDN for this DirectoryConfiguration object is
"ou=people, o=isp ", and there are two data naming contexts: "o=isp" and
"dc=filenet,dc=com", then you know the realm name for this
DirectoryConfiguration object is "o=isp".
Important: It is an IBM best practice to configure TLS or SSL between your
application server that hosts Content Engine and your directory server. This will
include making changes to the Content Engine DirectoryConfigurationCA object
that was created while running Configuration Manager. Consult your application
server's documentation for instructions.

Support matrix (CA Directory)

Use this support matrix as a quick lookup of supported directory features.
Table of CA Directory features that are supported or not supported by Content Engine.
Features

Supported By Content Engine

One-way SSL

Yes

Two-way SSL

No

Transport Layer Security (TLS)

No

Static Groups *

Yes

Nested Groups

Yes

Universal Groups

No

Supported User type (objectClass)

inetOrgPerson

Supported Static Group types (objectClass)

groupOfUniqueNames, groupOfNames

Follow referrals for Search (for example, User and

Group retrieval)

No

Support multiple realms

Yes

Chaining

Yes

Roles

No

Directory aliases

No

Restrict to single realm

No

Configurable user short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable group short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Yes

Configurable group display name attribute

Yes

Multiple authenticating attributes support

No

130

Security Extract

Table of CA Directory features that are supported or not supported by Content Engine.
Features

Supported By Content Engine

Use email attribute as short name

Yes, for user short name

Do not use email for group short name

Sorting

Yes. Return users and groups in sorted order: ascending only.

Server side sorting

Yes

Paging/Continuation

Yes. Return users and groups page by page. Page continuation

happens automatically in the back end.

LDAP attributes to read in a group entry when

resolving member users and member groups

member, uniqueMember

* Static groups
Static groups are useful when the members do not change often. Users and
other entries can be grouped using a static group entry. A static group
entry contains a list of members DNs. The static group entry usually has
an object class of "groupOfNames" and an attribute "member" that has one
value for each of the members in the group. If a user is removed from the
directory, then you must manually remove the user's member DN from
each group that the user belonged to.

Directory Configuration Properties (CA Directory)

A list of the properties in the DirectoryConfigurationCA class.
v For authentication, use Configuration Manager's Configure LDAP task to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
List of properties for the DirectoryConfigurationCA class, whether it can be edited, and a description for each property.
Property Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the fixed description of the class

from which a given object is instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is running the directory server
product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate to the directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server. The value of this
property defaults to port 389 for all supported directory server types.

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.ETrustProvider

DirectoryServerType

No

Specifies the type of directory server: CA

DirectoryServerUserName

Yes

Specifies the bind user DN for LDAP connection. Example:

"uid=admin,ou=People,o=isp"

DisplayName

Yes

The user-readable, user-provided, provider-specific name of an object.

DynamicGroup
MemberAttribute

Yes

Specifies the directory server attribute that holds the static members of a
dynamic group.

DynamicGroup
QueryAttribute

Yes

Specifies the attribute in the dynamic group that holds the dynamic
LDAP query. The Content Engine server runs this query to retrieve the
dynamic members of the group.

DynamicGroupObjectClass

Yes

Specifies the type of dynamic group to search.

GroupBaseDN

Yes

The base DN for searching for groups in the directory server.

Directory service providers

131

List of properties for the DirectoryConfigurationCA class, whether it can be edited, and a description for each property.
Property Name

Editable?

Description

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object.

GroupMembership
SearchFilter

Yes

The search filter for group membership queries.

GroupNameAttribute (also
called
GroupShortNameAttribute)

Yes

Defines the directory server attribute to be used as the short name for a
group.

GroupSearchFilter

Yes

Specifies search filter for groups. Example:

(&(objectclass=groupOfNames)(uid={0}))
where uid has been set as the short name. GroupSearchFilter must use
the same LDAP attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the security identifier (SID)
for each group. Select an attribute whose values are unique and do not
change over time. Typically, this attribute is the same as the
UserUniqueIDAttribute.
You must use only those LDAP attributes that return Java String in the
LDAP Java API.

Id

No

An object's globally unique ID (GUID).

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer (SSL) protocol is enabled

for a given DirectoryConfiguration object. The default value is false,
indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms only. A user can be in a

configured realm but belong to a group in an unconfigured realm. If set
to False, that user cannot log in because the system cannot look up all
the user's group memberships. If set to True, group memberships in
unconfigured realms are ignored.

SearchDynamicGroup

Yes

A boolean that indicates whether Content Engine searches dynamic

groups. When the property value is False, dynamic groups are not
searched.

UserBaseDN

Yes

The base DN for searching for users in the directory server.

UserDisplayNameAttribute

Yes

Specifies the display name for a User object.

UserNameAttribute (also
called
UserShortNameAttribute)

Yes

The directory service attribute that has been configured as the Logon
Attribute.

UserSearchFilter

Yes

Specifies search filter for users. Example:

(&(objectclass=person)(uid={0}))
where uid will serve as the short name. UserSearchFilter must use the
same LDAP attribute as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the security identifier (SID)
for each user. Select an attribute whose values are unique and do not
change over time. Typically, this attribute is the same as the
GroupUniqueIDAttribute.
You must use only those LDAP attributes that return Java String in the
LDAP Java API.

132

Security Extract

Get and search operations (CA Directory)

Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user or group by DN.
Get User or Group by SID
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by SID.
3. If found, return.
Search Users or Groups in a Given Realm
1. Connect to the host corresponding to the specified realm.
2. Search for the users or groups by the search criteria.

IBM Tivoli Directory Server

IBM FileNet P8 supports IBM Tivoli Directory Server for providing directory
services.
Overview (IBM Tivoli Directory Server)
Support matrix (IBM Tivoli Directory Server) on page 134
Directory Configuration Properties (IBM Tivoli Directory Server) on page 135
Get and search operations (IBM Tivoli Directory Server) on page 137

Overview (IBM Tivoli Directory Server)

One instance of IBM Tivoli Directory Server can have multiple data naming
contexts. Because each data naming context is mapped to a Content Engine realm,
one IBM Tivoli Directory Server can be mapped to multiple Content Engine realms.
For each realm, you need to create an application server authentication provider
and a DirectoryConfigurationIBM object, so that there is a one-to-one relationship
between Realm object and authentication provider, and also a one-to-one
relationship between Realm object and DirectoryConfigurationIBM object.
For each authentication provider, FileNet P8 extracts the realm name from the
specified User Base DN value by comparing it with each data naming context. For
example, if this authentication provider's user base DN is ou=people,o=isp, and
if there are two data naming contexts: o=isp and dc=filenet,dc=com, then you
know the realm name for this authentication provider is o=isp.
Directory service providers

133

Important: It is a best practice to configure SSL between your application server

that hosts Content Engine and your directory server. This will include making
changes in the application server to the authentication provider's
DirectoryConfigurationIBM object that was created while running Configuration
Manager. Consult your application server's documentation for instructions.

Support matrix (IBM Tivoli Directory Server)

Use this support matrix as a quick lookup of supported directory features.
Table of IBM Tivoli Directory Server features that are identified as being supported or not supported by Content
Engine.
IBM Tivoli Directory Server Features

Supported By Content Engine

One-way Secure Sockets Layer (SSL)

Yes

Two-way SSL

No

Transport Layer Security (TLS)

No

Static Groups

Yes

Dynamic Groups

No

Nested Groups

Yes

Supported User type (objectClass)

inetOrgPerson

Supported Static Group types (objectClass)

groupOfUniqueNames, groupOfNames

Roles

No

Follow referrals for Search (for example, User and Group

retrieval)

No

Support multiple realms

Yes

Chaining

Yes

Directory aliases

No

Restrict to single realm

Yes - Just configure one realm in application server

Configurable user short name attribute

Yes - Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable group short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Yes

Configurable group display name attribute

Yes

Multiple authenticating attributes support

Yes - See Configure multiple authenticating attributes.

Use email attribute as short name

Yes - for user short name

Do not use email for group short name

Sorting

134

Security Extract

Yes - Return users and groups in sorted order: either

ascending or descending order.

Table of IBM Tivoli Directory Server features that are identified as being supported or not supported by Content
Engine.
IBM Tivoli Directory Server Features

Supported By Content Engine

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engine to perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. Note that SSS is normally
enabled by default but is sometimes disabled due to
concerns with performance.

Paging/Continuation

Yes - Return users and groups page by page. Page

continuation happens automatically in the back end.

LDAP attributes to read in a group entry when resolving

member users and member groups

uniqueMember, member

Directory Configuration Properties (IBM Tivoli Directory

Server)
A list of the properties in the DirectoryConfigurationIBM class.
v For authentication, use Configuration Manager's Configure LDAP screen to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
List of properties for the DirectoryConfigurationIBM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the

fixed description of the class from which a
given object is instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is

running the directory server product.

DirectoryServerPassword

Yes

Specifies the user password used to

authenticate to a given directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory

server. The value of this property defaults to
port 389 for all supported directory server
types.

DirectoryServerProviderClass

Yes

Specifies the directory server provider class

name:
com.filenet.engine.security.IBMTivoliProvider

DirectoryServerType

No

Specifies the type of directory server: IBM

DirectoryServerUserName

Yes

Specifies the user name for authenticating to

the directory server.

DisplayName

Yes

The user-readable, provider-specific name of

an object. This property is usually the
designated Name property of the object's
class.

GroupBaseDN

Yes

The base DN for searching for groups in the

directory server.

Directory service providers

135

List of properties for the DirectoryConfigurationIBM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group

object generated by the authentication
provider. The default property value is
dependent on the authentication provider
and is specified by the provider's
configuration.

GroupMembershipSearchFilter

Yes

The search filter for group membership

queries.

GroupNameAttribute

Yes

Defines the directory server attribute to be

used as the short name for a group.

GroupSearchFilter

Yes

Specifies search filter for groups. Example:

(&(objectclass=group)(cn={0}))
where cn will serve as the short name.
GroupSearchFilter and GroupNameAttribute
must use the same LDAP attribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as

the security identifier (SID) for each group.
Select an attribute whose values are unique
and do not change over time. Typically, this
attribute is the same as the
UserUniqueIDAttribute.
You must use only those LDAP attributes
that return Java String in the LDAP Java
API.

Id

No

An object's globally unique ID (GUID).

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer

(SSL) protocol is enabled for a given
DirectoryConfiguration object. The default
value is false, indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms

only. A user can be in a configured realm but
belong to a group in an unconfigured realm.
If set to Yes, that user cannot log in because
the system cannot look up all the user's
group memberships. If set to No, group
memberships in unconfigured realms are
ignored.

UserBaseDN

Yes

The base DN for searching for users in the

directory server.

UserDisplayNameAttribute

Yes

Specifies the display name for a User object

generated by the authentication provider.
The default property value is dependent on
the authentication provider and is specified
by the provider's configuration.

UserShortNameAttribute

Yes

The directory service attribute that has been

configured as the Logon Attribute.

136

Security Extract

List of properties for the DirectoryConfigurationIBM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

UserSearchFilter

Yes

Description
Specifies search filter for users. Example:
(&(objectclass=user)(cn={0}))
where cn has been set as the short name.
UserSearchFilter and UserNameAttribute
must use the same LDAP attribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as

the security identifier (SID) for each user.
Select an attribute whose values are unique
and do not change over time. Typically, this
attribute is the same as the
GroupUniqueIDAttribute.
You must use only those LDAP attributes
that return Java String in the LDAP Java
API.

Get and search operations (IBM Tivoli Directory Server)

Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user or group by DN.
Get User or Group by SID
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by SID.
3. If found, return.
Search Users or Groups in a Given Realm
1. Connect to the host corresponding to the specified realm.
2. Search for the users or groups by the search criteria.

Directory service providers

137

Novell eDirectory
IBM FileNet P8 supports Novell eDirectory for providing directory services.
Overview (Novell eDirectory)
Support matrix (Novell eDirectory)
Directory Configuration Properties (Novell eDirectory) on page 139
Get and search operations (Novell eDirectory) on page 141

Overview (Novell eDirectory)

One instance of Novell eDirectory directory server can have multiple contexts.
Because each context immediately under the ROOT DSE (tree Object) is mapped to
a Content Engine realm, one eDirectory server can be mapped to multiple Content
Engine realms.
For each realm, you must create an application server authentication provider and
a DirectoryConfigurationNovell object, so that there is a one-to-one relationship
between Realm object and authentication provider, and also a one-to-one
relationship between Realm object and DirectoryConfigurationNovell object.
For example:
v If the user base DN is "dc=filenet.com, ou=eng, o=cedev1" then o=cedev1 will be
the context for all the objects under it, and it is the first level under the ROOT
DSE, which is the name of Content Engine Realm object.
v If the user based DN is "dc=filenet.com, ou=eng, c=US" then c=US will be the
context for all the objects under it, and it is the first level under the ROOT DSE,
which the name of Content Engine Realm object.
For each DirectoryConfigurationNovell object, FileNet P8 uses the specified
UserBaseDN property value to lookup context.
Important: It is a best practice to configure SSL between your application server
that hosts Content Engine and your Novell eDirectory servers. This will include
making changes in the application server to the authentication provider's
DirectoryConfigurationNovell object that was created while running Configuration
Manager. Consult your application server's documentation for instructions.

Support matrix (Novell eDirectory)

Use this support matrix as a quick lookup of supported directory features.
Table of Novell eDirectory features that are identified as being supported or not supported by Content Engine.
Novell eDirectory Features

Supported By Content Engine

One-way Secure Sockets Layer (SSL)

Yes

Two-way SSL

No

Transport Layer Security (TLS)

No

Container types supported

Country (C), Organization (O), Organizational Unit (OU),

Domain (DC)

Static Groups

Yes

Nested Groups

Yes (requires eDirectory 8.8 SP3 or later)

Dynamic Groups

No

Supported User type (objectClass)

Person

138

Security Extract

Table of Novell eDirectory features that are identified as being supported or not supported by Content Engine.
Novell eDirectory Features

Supported By Content Engine

Supported Static Group types (objectClass)

groupOfNames

Roles

No

Follow referrals for Search (for example, User and Group

retrieval)

No

Support multiple realms

Yes

Chaining

Yes

Directory aliases

No

Restrict to single realm

Yes - Just configure one realm in application server

Configurable user short name attribute

Yes - Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Yes

Configurable group display name attribute

Yes

Configurable group name attribute for persisting

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Multiple authenticating attributes support

Yes - See Configure multiple authenticating attributes for

details.

Use email attribute as short name

Yes - If you set this property as the user short name, you
must create an index for the eDirectory Internet Email
Address attribute.
Do not use email for group short name

Sorting

Yes - Return users and groups in sorted order (ascending

only)

Paging/Continuation

Yes - Return users and groups page by page. Page

continuation happens automatically in the back end.

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engineto perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. Note that SSS is normally
enabled by default but is sometimes disabled due to
concerns with performance.

Typeful and type less name display

Typeful name display only

LDAP attributes to read in a group entry when resolving

member users and member groups

member

Directory Configuration Properties (Novell eDirectory)

A list of the properties in the DirectoryConfigurationNovell class.
v For authentication, use Configuration Manager's Configure LDAP screen to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.

Directory service providers

139

List of properties for the DirectoryConfigurationNovell class, whether it can be edited, and a description for each
property.
Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the fixed

description of the class from which a given object is
instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is running the

directory server product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate to

a given directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server.

The value of this property defaults to port 389 for
all supported directory server types.

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.EDirectoryProvider

DirectoryServerType

No

Specifies the type of directory server: Novell

DirectoryServerUserName

Yes

Specifies the user name for authenticating to the

directory server.

DisplayName

Yes

The user-readable, provider-specific name of an

object. This property is usually the designated
Name property of the object's class.

GroupBaseDN

Yes

The base DN for searching for groups in the

directory server.

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider's configuration.

GroupMembership SearchFilter

Yes

The search filter for group membership queries.

GroupNameAttribute

Yes

Defines the directory server attribute to be used as

the short name for a group.

GroupSearchFilter

Yes

Specifies search filter for groups. Example:

(&(objectclass=group)(cn={0}))
where cn has been set as the short name.
GroupSearchFilter must use the same LDAP
attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each group. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the UserUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Id Property

No

An object's globally unique ID (GUID).

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer (SSL)

protocol is enabled for a given
DirectoryConfiguration object. The default value is
false, indicating that SSL is disabled.

140

Security Extract

List of properties for the DirectoryConfigurationNovell class, whether it can be edited, and a description for each
property.
Name

Editable?

Description

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms only.

A user can be in a configured realm but belong to a
group in an unconfigured realm. If set to Yes, that
user cannot log in because the system cannot look
up all the user's group memberships. If set to No,
group memberships in unconfigured realms are
ignored.

UserBaseDN

Yes

The base DN for searching for users in the

directory server.

UserDisplayNameAttribute

Yes

Specifies the display name for a User object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider's configuration.

UserShortNameAttribute

Yes

The directory service attribute that has been

configured as the Logon Attribute.

UserSearchFilter

Yes

Specifies search filter for users. Example:

(&(objectclass=user)(cn={0}))
where cn has been set as the short name.
UserSearchFilter must use the same LDAP attribute
as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each user. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the GroupUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Get and search operations (Novell eDirectory)

Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user or group by DN.
Get User or Group by SID
Directory service providers

141

Iterate through all realms. For each realm:

1. Connect to corresponding host.
2. Search for the user or group by SID.
3. If found, return.
Search Users or Groups in a Given Realm
1. Connect to the host corresponding to the specified realm.
2. Search for the users or groups by the search criteria.

Oracle Internet Directory

IBM FileNet P8 supports Oracle Internet Directory Server for providing directory
services.
Overview (Oracle Internet Directory)
Support matrix (Oracle Internet Directory)
Directory Configuration Properties (Oracle Internet Directory) on page 143
Get and search operations (Oracle Internet Directory) on page 145

Overview (Oracle Internet Directory)

Oracle Internet Directory (OID) is an LDAP directory that leverages features of the
Oracle Database and is supported for use as a central user repository by IBM
FileNet P8.
Important: It is a best practice to configure SSL between your application server
that hosts Content Engine and your directory server. This will include making
changes in the application server to the authentication provider's
DirectoryConfigurationOID object that was created while running Configuration
Manager. Consult your application server's documentation for instructions.

Support matrix (Oracle Internet Directory)

Use this support matrix as a quick lookup of supported directory features.
Table of Oracle Internet Directory features that are identified as being supported or not supported by Content Engine.
Oracle Internet Directory Features

Supported By Content Engine

One-way Secure Sockets Layer (SSL)

Yes

Two-way SSL

No

Transport Layer Security (TLS)

No

Static Groups

Yes

Nested Groups

Yes

Dynamic Groups

No

Supported User type (objectClass)

person,organizationalPerson,inetOrgPerson

Supported Static Group types (objectClass)

groupOfUniqueNames, groupOfNames

Follow referrals for Search (for User and Group retrieval)

No

Support multiple realms

Yes

Chaining

No

Roles

No

Directory aliases

No

Restrict to single realm

Yes

142

Security Extract

Table of Oracle Internet Directory features that are identified as being supported or not supported by Content Engine.
Oracle Internet Directory Features

Supported By Content Engine

Configurable user short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Yes

Configurable group short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable group display name attribute

Yes

Multiple authenticating attributes support

Yes- can authenticate against the same OID server by

multiple attributes, such as uid or distinguishedName

Use email attribute as shortname

Yes - for user short name

Do not use email for group short name

Sorting

Yes- Return users/groups in sorted order: either

ascending or descending order

Paging/Continuation

Yes- Return users/groups page by page. Page

continuation happens automatically in the back end

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engine to perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. Note that SSS is normally
enabled by default but is sometimes disabled due to
concerns with performance.

LDAP attributes to read in a group entry when resolving

member users and member groups

uniqueMember, member

Directory Configuration Properties (Oracle Internet Directory)

A list of the properties in the DirectoryConfigurationOID class.
v For authentication, use Configuration Manager's Configure LDAP screen to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
List of properties for the DirectoryConfigurationOID class, whether it can be edited, and a description for each
property.
Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the fixed

description of the class from which a given object
is instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is running the

directory server product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate

to a given directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server.

The value of this property defaults to port 389 for
all supported directory server types.
Directory service providers

143

List of properties for the DirectoryConfigurationOID class, whether it can be edited, and a description for each
property.
Name

Editable?

Description

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.OIDProvider

DirectoryServerType

No

Specifies the type of directory server: OID

DirectoryServerUserName

Yes

Specifies the user name for authenticating to the

directory server. Example:
cn=ceadmin,dc=users,dc=foo,dc=com

DisplayName

Yes

The user-readable, provider-specific name of an

object. This property is usually the designated
Name property of the object's class.

GroupBaseDN

Yes

The base DN for searching for groups in the

directory server.

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider's configuration.

GroupMembership SearchFilter

Yes

The search filter for group membership queries.

GroupNameAttribute

Yes

Defines the directory server attribute to be used

as the short name for a group.

GroupSearchFilter

Yes

Specifies search filter for groups. Example:

(&(cn={0})(|(objectClass=groupOfNames)
(objectClass=groupOfUniqueNames)))
where cn has been set as the short name.
GroupSearchFilter must use the same LDAP
attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each group. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the UserUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Id Property

No

An object's globally unique ID (GUID).

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer (SSL)

protocol is enabled for a given
DirectoryConfiguration object. The default value
is false, indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms only.

A user can be in a configured realm but belong to
a group in an unconfigured realm. If set to Yes,
that user cannot log in because the system cannot
look up all the user's group memberships. If set to
No, group memberships in unconfigured realms
are ignored.

UserBaseDN

Yes

The base DN for searching for users in the

directory server.

144

Security Extract

List of properties for the DirectoryConfigurationOID class, whether it can be edited, and a description for each
property.
Name

Editable?

Description

UserDisplayNameAttribute

Yes

Specifies the display name for a User object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider's configuration.

UserShortNameAttribute

Yes

The directory service attribute that has been

configured as the Logon Attribute.

UserSearchFilter

Yes

Specifies search filter for users. Example:

(&(objectclass=user)(cn={0}))
where cn has been set as the short name.
UserSearchFilter must use the same LDAP
attribute as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each user. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the GroupUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Get and search operations (Oracle Internet Directory)

Explains how Content Engine performs LDAP searches by various attributes.
This section describes some of the interactions between Content Engine and OID.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user or group by DN.
Get User or Group by SID
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by SID.
3. If found, return.
Search Users or Groups in a Given Realm
Directory service providers

145

1. Connect to the host corresponding to the specified realm.

2. Search for the users or groups by the search criteria.

Oracle Directory Server Enterprise Edition

IBM FileNet P8 supports Oracle Directory Server Enterprise Edition (formerly
known as Sun Java System Directory Server) for providing directory services.
Overview (Oracle Directory Server Enterprise Edition)
Support matrix (Oracle Directory Server Enterprise Edition)
Directory Configuration Properties (Oracle Directory Server Enterprise
Edition) on page 148
Get and search operations (Oracle Directory Server Enterprise Edition) on
page 149

Overview (Oracle Directory Server Enterprise Edition)

One instance of Oracle Directory Server Enterprise Edition can have multiple data
naming contexts. Because each Oracle Directory Server Enterprise Edition data
naming context is mapped to a Content Engine realm, one Oracle Directory Server
Enterprise Edition can be mapped to multiple Content Engine realms.
For each realm, you need to create an application server authentication provider
and a DirectoryConfigurationSunOne object, so that there is a one-to-one
relationship between Realm object and authentication provider, and also a
one-to-one relationship between Realm object and DirectoryConfigurationSunOne
object.
For each DirectoryConfiguration object, FileNet P8 extracts the realm name from
the specified UserBaseDN property value by comparing it with each data naming
context. For example, if the UserBaseDN for this DirectoryConfiguration object is
"ou=people, o=isp ", and there are two data naming contexts: "o=isp" and
"dc=filenet,dc=com", then you know the realm name for this
DirectoryConfiguration object is "o=isp".
Important: It is an IBM best practice to configure SSL between your application
server that hosts Content Engine and your directory server. This will include
making changes in the application server to the authentication provider's
DirectoryConfigurationSunOne object that was created while running
Configuration Manager. Consult your application server's documentation for
instructions.

Support matrix (Oracle Directory Server Enterprise Edition)

Use this support matrix as a quick lookup of supported directory features.
Table of Oracle Directory Server Enterprise Edition features that are identified as being supported or not supported by
the Content Engine.
Oracle Directory Server Enterprise Edition Features

Supported By Content Engine

One-way SSL

Yes

Two-way SSL

No

Transport Layer Security (TLS)

No

Static Groups

Yes

Nested Groups

Yes

146

Security Extract

Table of Oracle Directory Server Enterprise Edition features that are identified as being supported or not supported by
the Content Engine.
Oracle Directory Server Enterprise Edition Features

Supported By Content Engine

Dynamic Groups

No

Universal Groups

No

Supported User type (objectClass)

inetOrgPerson

Supported Static Group types (objectClass)

groupOfUniqueNames

Follow referrals for Search (for example, User and Group

retrieval)

No
Restriction: Earlier releases of FileNet P8 were able to
follow referrals, but this is not supported in the present
release due to problems with how Oracle Directory Server
Enterprise Edition performs sorting. Use Oracle Directory
Server Enterprise Edition server chaining instead of
referrals.

Support multiple realms

Yes

Chaining

Yes

Roles

No

Directory aliases

No

Restrict to single realm

Yes - Just configure one realm in application server

Configurable user short name attribute

Yes - Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable group short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Yes

Configurable group display name attribute

Yes

Multiple authenticating attributes support

Yes - Can authenticate against the same Oracle Directory

Server Enterprise Edition server with multiple attributes,
such as uid or distinguishedName. See Configure
multiple authenticating attributes.

Use email attribute as short name

Yes - for user short name

Do not use email for group short name

Sorting

Yes - Return users and groups in sorted order: either

ascending or descending order.

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engine to perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. Note that SSS is normally
enabled by default but is sometimes disabled due to
concerns with performance.

Paging/Continuation

Y - Return users and groups page by page. Page

continuation happens automatically in the back end.

LDAP attributes to read in a group entry when resolving

member users and member groups

uniqueMember, member

Directory service providers

147

Directory Configuration Properties (Oracle Directory Server

Enterprise Edition)
A list of the properties in the DirectoryConfigurationSunOne class.
v For authentication, use Configuration Manager's Configure LDAP screen to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
List of properties for the DirectoryConfigurationSunOne class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the fixed description of the

class from which a given object is instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is running the directory

server product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate to a given

directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server. The value of

this property defaults to port 389 for all supported directory
server types.

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.SunOneProvider

DirectoryServerType

No

Specifies the type of directory server: SunOne

DirectoryServerUserName

Yes

Specifies the user name for authenticating to the directory

server. Example:
uid=admin,ou=administrators,
ou=topologymanagement,o=netscaperoot

DisplayName

Yes

The user-readable, provider-specific name of an object. This

property is usually the designated Name property of the
object's class.

GroupBaseDN

Yes

The base DN for searching for groups in the directory server.

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object generated by the

authentication provider. The default property value is
dependent on the authentication provider and is specified by
the provider's configuration.

GroupMembership SearchFilter

Yes

The search filter for group membership queries.

GroupNameAttribute

Yes

Defines the directory server attribute to be used as the short

name for a group.

GroupSearchFilter

Yes

Specifies search filter for groups. Example:

(&(objectclass=group)(uid={0}))
where uid has been set as the short name. GroupSearchFilter
must use the same LDAP attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the security

identifier (SID) for each group. Select an attribute whose values
are unique and do not change over time. Typically, this
attribute is the same as the UserUniqueIDAttribute.
You must use only those LDAP attributes that return Java
String in the LDAP Java API.

Id

148

No
Security Extract

An object's globally unique ID (GUID).

List of properties for the DirectoryConfigurationSunOne class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer (SSL) protocol is

enabled for a given DirectoryConfiguration object. The default
value is false, indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms only. A user can

be in a configured realm but belong to a group in an
unconfigured realm. If set to Yes, that user cannot log in
because the system cannot look up all the user's group
memberships. If set to No, group memberships in unconfigured
realms are ignored.

UserBaseDN

Yes

The base DN for searching for users in the directory server.

UserDisplayNameAttribute

Yes

Specifies the display name for a User object generated by the

authentication provider. The default property value is
dependent on the authentication provider and is specified by
the provider's configuration.

UserShortNameAttribute

Yes

The directory service attribute that has been configured as the

Logon Attribute.

UserSearchFilter

Yes

Specifies search filter for users. Example:

(&(objectclass=user)(uid={0}))
where uid will serve as the short name. UserSearchFilter must
use the same LDAP attribute as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the security

identifier (SID) for each user. Select an attribute whose values
are unique and do not change over time. Typically, this
attribute is the same as the GroupUniqueIDAttribute.
You must use only those LDAP attributes that return Java
String in the LDAP Java API.

Get and search operations (Oracle Directory Server Enterprise

Edition)
Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user or group by DN.
Get User or Group by SID
Directory service providers

149

Iterate through all realms. For each realm:

1. Connect to corresponding host.
2. Search for the user or group by SID.
3. If found, return.
Search Users or Groups in a Given Realm
1. Connect to the host corresponding to the specified realm.
2. Search for the users or groups by the search criteria.

Windows Active Directory

IBM FileNet P8 supports Active Directory for providing directory services.
Important: It is a best practice to configure SSL between your application server
that hosts Content Engine and your Active Directory servers. This will include
making changes in the application server to the authentication provider
DirectoryConfigurationAD object that was created while running Configuration
Manager. Consult your application server documentation for instructions.
Support matrix (Active Directory)
Directory Configuration Properties (Active Directory) on page 152
Realm Configuration (Active Directory) on page 154
Failover Support (Active Directory) on page 155
Get and search operations (Active Directory) on page 158

Support matrix (Active Directory)

Use this support matrix as a quick lookup of supported directory features.
Table of Active Directory features that are identified as being supported or not supported by Content Engine.
Active Directory Features

Supported By Content Engine

One-way SSL

Yes

Two-way SSL

No

Universal Groups

Yes

Security Groups

Yes

Distribution Groups

Yes

Nested Groups

Yes

Builtin Groups

No

Users and groups belonging to custom Active Directory

objects

Yes

Supported User type (objectClass)

user

Supported Static Group types (objectClass)

group

Follow referrals for Search (for User/Group retrieval)

No

Roles

No

Directory aliases

No

Native Mode Active Directory

Yes

Mixed Mode Active Directory

Yes - No support for NT4.

Restrict to single realm

Yes - By configuring just one realm.

Support multiple realms and domains

Yes

150

Security Extract

Table of Active Directory features that are identified as being supported or not supported by Content Engine.
Active Directory Features

Supported By Content Engine

Support multiple forests

Yes

Support users and groups migrate from domain to

domain within a forest

No

Support domains across multiple forests

Yes

Configurable user short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable group short name attribute

Yes. Because the short name does not contain realm

information, short names must be unique across all your
configured domains and realms.

Configurable user display name attribute

Configurable group display name attribute

Configurable principal Name - Boolean flag

Yes
If true: [email protected]
If false: full DN

DNS Site

Yes Resolve domain controllers in a given DNS site.

Multiple authenticating attributes support

Yes Can authenticate against the same Active Directory

server using multiple attributes, such as
samAccountName, userPrincipalName, or
distinguishedName. See Configure multiple
authenticating attributes.

Use userPrincipalName (UPN) or email as shortname

Yes - for user short name. See Configure Content Engine

to use UPN or email for login.
Do not use email for group short name

Sorting

Yes Return users and groups in sorted order: either

ascending or descending order.

Paging/Continuation

Yes Return users and groups page by page. Page

continuation happens automatically in the back end.

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engine to perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. SSS is normally enabled by
default but is sometimes disabled due to concerns with
performance.

Windows NT domains (versions 4.0 and earlier).

No

Group search returns Domain Local Groups

Yes

LDAP attributes to read in a group entry when resolving

member users and member groups

member

Look up previous user and group SID (objectSID) value

in ACLs

Yes if sIDHistory is maintained

Directory service providers

151

Directory Configuration Properties (Active Directory)

A list of the properties in the DirectoryConfigurationAD class.
v For authentication, use Configuration Manager Configure LDAP task to view or
modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
List of properties for the DirectoryConfigurationAD class, whether it can be edited, and a description for each property.
Property Name

Editable?

AllowEmailOrUPNShortNames

Yes

Description
Set this property to Y to allow the at sign (@) in
user names. This property is available only in
Enterprise Manager.
Set this property the same way on all Active
Directory directory configurations.

ClassDescription

No

A ClassDescription object containing the fixed

description of the class from which a given object
is instantiated.

ConnectionTimeout

Yes

Specifies the Active Directory Service provider

connection timeout in milliseconds. The default is
500 ms. If the connection is across a WAN,
consider increasing the value.

DirectoryServerHost

Yes

Specifies the name of the host that is running the

directory server product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate

to a given directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server.

The value of this property defaults to port 389 for
all supported directory server types.

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.ActiveDirectoryProvider

DirectoryServerType

No

Specifies the type of directory server: AD

DirectoryServerUserName

Yes

Specifies the user name for authenticating to the

directory server. Example:
"CN=test1,CN=Users,DC=myCompany,DC=com"

DisplayName

Yes

The user-readable, provider-specific name of an

object. This property is usually the designated
Name property of the object class.

GroupBaseDN

Yes

The base DN for searching for groups in the

directory server.

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider configuration.

GroupMembershipSearchFilter

Yes

The search filter for group membership queries.

GroupNameAttribute

Yes

Defines the directory server attribute to be used as

the short name for a group.

152

Security Extract

List of properties for the DirectoryConfigurationAD class, whether it can be edited, and a description for each property.
Property Name

Editable?

GroupSearchFilter

Yes

Description
Specifies search filter for groups. Example:
(&(objectclass=group)(samAccountName={0}))
where samAccountName will serve as the short
name. GroupSearchFilter must use the same LDAP
attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each group. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the UserUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Id

No

The globally unique ID (GUID) of the object.

IsSSLEnabled

Yes

Defines whether Secure Sockets Layer (SSL)

protocol is enabled for a given
DirectoryConfiguration object. The default value is
false, indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

Restricts group lookups to configured realms only.

A user can be in a configured realm but belong to
a group in an unconfigured realm. If set to Yes,
that user cannot log in because the system cannot
look up all the user's group memberships. If set to
No, group memberships in unconfigured realms
are ignored.

ReturnNameAsDN

Yes

Specifies whether to return the user or group

name in Distinguished Name (DN) format. By
default, the Active Directory Service provider
returns the user and group names in UPN format.
If you set AllowEmailOrUPNShortNames to Y
(true), Content Engine will automatically treat the
ReturnNameAsDN property as Y (true) on all
configured Active Directories, regardless of how it
is set.

SearchCrossForest GroupMembership Yes

Specifies whether the Active Directory Service

provider performs cross-forest group membership
searches. The default is false. To enable
cross-forest group membership searches, set this
property to true.

UserBaseDN

Yes

The base DN for searching for users in the

directory server.

UserDisplayNameAttribute

Yes

Specifies the display name for a User object

generated by the authentication provider. The
default property value is dependent on the
authentication provider and is specified by the
provider configuration.

UserShortNameAttribute

Yes

The directory service attribute that has been

configured as the Logon Attribute.

Directory service providers

153

List of properties for the DirectoryConfigurationAD class, whether it can be edited, and a description for each property.
Property Name

Editable?

UserSearchFilter

Yes

Description
Specifies search filter for users. Example:
(&(objectclass=user)(samAccountName={0}))
where samAccountName will serve as the short
name. UserSearchFilter must use the same LDAP
attribute as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each user. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the GroupUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Realm Configuration (Active Directory)

Active Directory authentication can be configured in three different levels:
single-realm, multi-realm, and entire forest. In an Active Directory forest, if a
cross-domain group membership involves any Domain Local Group, the group
membership is one-way, and it is not replicated to the Active Directory Global
Catalog. The forward group membership search presents no problems: given a
group in one domain, FileNet P8 can easily find all its members in other domains.
However, the backward group membership search can be very resource intensive.
FileNet P8 would have to iterate through all other domains to find all the parent
groups of which this group is a member. Since large enterprises might have 30 or
more domains in a single forest, this iterative approach for cross-domain backward
group membership search can be unacceptably slow.
In order to address this problem, you can split the cross-domain group
membership and add a new group in between. For example, a Domain Local
Group in Domain A might contain a Global Group in Domain B. The following
figure shows a Universal Group in Domain A that has been configured as a
member of the Domain Local Group. Then the Global Group in Domain B has
been configured to be a member of the newly created Universal Group.
Root
Domain

Domain
A

Domain
B

Domain Local
Group

Global
Group

Universal
Group

To summarize:
v Group membership in the same domain is two-way, regardless the group scope.

154

Security Extract

v If the cross-domain group membership does not involve a Domain Local Group,
it is two-way in the Global Catalog.

Failover Support (Active Directory)

Content Engine supports LDAP failover for authorization when Active Directory is
the configured directory server. You can configure Active Directory failover using
host:post pairs or by using domain names.

Active Directory failover support for authorization

Connections between Content Engine and Active Directory fail if the configured
domain controller is not available. Therefore, you should provide Active Directory
failover for authorization if your IBM FileNet P8 system requires continuous
availability and a high degree of reliability. Active Directory failover eliminates a
single point of failure by switching automatically to another domain controller
when the current domain controller becomes unavailable. The Content Engine
server can be unavailable for a variety of reasons, including system failure,
decommissioning the directory server, stopping the server for maintenance, or
changing its host name. Because failover happens automatically and no application
restart is necessary, users usually do not experience service disruption. Of the three
types of Active Directory configurations (single-realm, multi-realm, and entire
forest), you can configure failover for single-realm and multi-realm, but not for the
entire forest.
Active Directory consists of two types of repositories:
v Domain Controllers (DC) that hold domainwide data
v Global Catalog servers (GC) that hold forestwide data
You can configure Content Engine for Active Directory failover by specifying a list
of host:port pairs or by using domain names.
v The failover list method is useful if you have a preferred order of servers for
your failover sequence.
v The domain name or multiple-IP address method uses the services of the DNS
server and can require less maintenance.
v Both types can be configured programmatically through the API or in Enterprise
Manager.
For performance reasons, you should create your failover list by using Active
Directory and Content Engine servers that are local, that is, at the same network
site. If you must specify remote Active Directory servers and you are using the
host:port pair method, place the remote servers at the end of the failover list.
To provide failover support for authentication, that is, for login, use the features of
the Content Engine application server. Consult your application server
documentation. For a more detailed procedure on how to configure a failover in
Enterprise Manager, see Administering IBM FileNet P8 > Administering Content
Engine Administration > FileNet P8 Domains > Configure directory server
failover (Microsoft Active Directory).

Active Directory failover that uses a list of host:port pairs

One way to configure Active Directory failover support is by specifying a failover
list. A failover list consists of one or more host:port pairs, for example, dc1:389
dc2:389 dc3:389. The host can be a host name or an IP address. The host name
Directory service providers

155

can be either a short name such as dc1 or a fully-qualified DNS name such as
dc1.mydomain.com. Although you can specify only one pair in the failover list, you
should have two or more pairs to create a true failover sequence.
When Content Engine is started, it attempts to connect to each pair in order from
left to right until it finds a working pair. Content Engine then uses this pair for
LDAP access until the server that is specified by this pair becomes unavailable for
some reason. Content Engine then starts the failover process again by going back
to the beginning of the failover list and trying each pair from left to right. If it
cannot connect to any pair in the list, various types of errors can be generated on
the client, depending on the point of failure. For example it might be a DNS error
such as UnknownHost, a network error, or a connection refused error.
Specify a failover list in the DirectoryServerHost property of the
DirectoryConfiguration class. Because each pair contains a port number, Content
Engine ignores any value in the DirectoryServerPort property. Separate each pair
with a space character. The following table shows examples of a DC failover list:
Table 5. Failover configuration example that uses host:port pairs
Properties in Enterprise Manager

Value

Host

dc1:389 dc2:389 dc3:389 (for nonsecured

connection)
dc1:636 dc2:636 dc3:636 (for SSL
connection)

Port

Content Engine ignores any value in the Port

property

GCHost

gc4:3268 gc5:3268 gc6:3268 (for nonsecured

connection)
gc4:3269 gc5:3269 gc6:3269 (for SSL
connection)

GCPort

Content Engine ignores any value in the

GCPort property

Active Directory failover using domain name or multiple IP

addresses
An alternative method to the host:port pair method that you can use to configure
Active Directory failover support is to specify one of the following options for the
values of the DCHostName and GCHostName properties:
v Active Directory domain and global catalog names
v DNS A record that represents multiple IP addresses
The benefit of using domain names for failover is that you do not need to modify
a failover list when you decommission a domain controller or change its host
name. Instead, the DNS data will be updated by the DNS Server, and Content
Engine will read the latest DNS data when it needs to fail over to another domain
controller.
A DNS A (address) record is a DNS record that associates a DC or GC host name
with one or more IP addresses. For example, you could create an A record named

156

Security Extract

my_dc that will associated with three local domain controllers: 9.39.50.155,
9.39.50.157, and 9.39.50.159. Content Engine pings these domain controllers until
one is available.
In some cases, this method is preferable to the host:port pairs method. For
example, if you have many applications communicating with many directory
servers and a directory server is decommissioned or its host name is changed, you
remove it from the DNS server and all applications will use the updated DNS data
to perform failover. No application restart is necessary.
You can maintain a list of directory servers that is associated to a DNS name on
your DNS server. All applications point to this DNS name instead of specific server
names. The DNS name can be either an AD domain name or an arbitrary host
name that is associated to multiple IP addresses of AD servers.
Content Engine follows these general steps during failover when the failover
support is configured to use domain name or multiple IP addresses:
1. Retrieves the AD domain name or a multiple-IP address host name from GCD.
If Content Engine finds only one host name in the Host field and not a pair or
several pairs and if this host name resolves to more than one IP in DNS server,
then Content Engine interprets it as a domain name or multiple-IP host name
and not as a host:port configuration.
2. Searches DNS server for all A records whose name is this domain name or
multiple-IP address host name.
3. Gets back a list of IP addresses and pings them all at the same time.
4. Uses the first IP address that responds and ignores the others.
The following table provides examples of domain names that are configured for
failover and set in Enterprise Manager. The examples are based on the following
assumptions:
v The Active Directory domain name is mydomain.com.
v More than one domain controller (in this domain) has Global Catalog server
running on it.
v Port 3268 is used for the global catalog server.
In Enterprise Manager, you would set the following fields.
Table 6. Failover configuration example that uses domain names
Properties in Enterprise Manager

Value

Host

mydomain.com

Port

389

GCHost

mydomain.com

GCPort

3268

The following example shows how to configure failover using multiple IP

addresses. The example is based on the following assumptions:
v You have at least two domain controllers for your Active Directory domain in
your local site.
v Global Catalog server is installed on each domain controller.
v The IP addresses of the two DCs are 10.10.10.11 and 10.10.10.12.
v The multiple-IP address host name is localAD.
Directory service providers

157

v You created the following A records in your DNS server:

Name
Type
Data
==========================================
localAD
Host (A)
10.10.10.11
localAD
Host (A)
10.10.10.12

Then, in Enterprise Manager, you can set the following fields.

Table 7. Failover configuration example using DNS A records
Properties in Enterprise Manager

Value

Host

localAD

Port

389

GCHost

localAD

GCPort

3268

For more information about DNS A records, see your Active Directory
documentation.

Get and search operations (Active Directory)

Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all forests. For each forest:
Connect to GC and search for DN by the short name.
Resolve the domain name from the DN.
Connect to the domain and search for the user or group by DN.
If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches for it again in the GC. In the end, it combines
the results.
v If the multi-forest support flag is on and the group membership is asked
for, FileNet P8 searches for it in all other forests.
v
v
v
v

If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains and forests.
Get User or Group by DN
v Resolve the domain name from the DN.
v Connect to the domain and search for the user or group by DN.
v If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches for it again in the Global Catalog. In the end,
FileNet P8 combines the results.
v If the multi-forest support flag is turned on and the group membership
is asked for, FileNet P8 searches all forests.
Get User by UPN when AllowEmailOrUPNShortNames is disabled
v
v
v
v

158

Security Extract

Resolve the domain name from the UPN.

Get short name from UPN.
Connect to the domain and search for the user by short name.
If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches again in the Global Catalog. In the end,
FileNet P8 combines the results.

v If the multi-forest support flag is turned on and the group membership

is asked for, FileNet P8 will search for it in all other forests.
Get User by UPN when AllowEmailOrUPNShortNames is enabled
Iterate through all forests. For each forest:
v Connect to GC and search for DN by the UPN.
v Resolve the domain name from the DN.
v Connect to the domain and search for the user or group by DN.
v If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches for it again in the Global Catalog. In the end,
it combines the results.
v If the multi-forest support flag is on and the group membership is asked
for, FileNet P8 searches for it in all other forests.
If more than one user is found, Content Engine logs an error and returns
the first user found.
Microsoft defines the user principal name (UPN) format to consist of the
user name, the at sign (@), and a user principal name suffix. In Content
Engine, the user name part is always the short name, and the suffix part is
always the DNS domain name of the domain the user belongs to.
Get User or Group by Email Address (AllowEmailOrUPNShortNames on)
Iterate through all forests. For each forest:
v Connect to GC and search for DN by the email address.
v Resolve the domain name from the DN.
v Connect to the domain and search for the user or group by DN.
v If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches for it again in the Global Catalog. In the end,
it combines the results.
v If the multi-forest support flag is on and the group membership is asked
for, FileNet P8 searches for it in all other forests.
If more than one user or group is found, Content Engine logs an error and
returns the first user found.
Get User or Group by SID
v Resolve the domain name from the SID, where the SID can be either the
current or historical SID. Part of user and group SID is its domain SID.
FileNet P8 maintains a mapping between domain SID and domain
name.
v Connect to the domain and search for the user or group by SID.
v If group membership is asked for, FileNet P8 searches for it in the local
domain first; then searches for it again in the Global Catalog. In the end,
FileNet P8 combines the results.
v If the multi-forest support flag is turned on and the group membership
is asked for, FileNet P8 searches all forests.
Search Users or Groups in a Given Realm
v Connect to the domain specified by the realm name.
v Search for the users or groups by the search criteria.
v For each user or group, if group membership is asked for, FileNet P8
searches for it in the local domain first; then searches for it again in the
Global Catalog. In the end, FileNet P8 combines the results.
Directory service providers

159

v If the multi-forest support flag is turned on and the group membership

is asked for, FileNet P8 searches all forests.

Windows Active Directory Lightweight Directory Services (AD LDS)

IBM FileNet P8 supports Windows Active Directory Lightweight Directory Services
for providing directory services.
Overview (Active Directory Lightweight Directory Services)
Support matrix (Active Directory Lightweight Directory Services) on page 162
Directory Configuration Properties (Active Directory Lightweight Directory
Services) on page 163
Get and search operations (Active Directory Lightweight Directory Services)
on page 165

Overview (Active Directory Lightweight Directory Services)

Microsoft has changed the name of Active Directory Application Mode (ADAM) to
Active Directory Lightweight Directory Services (AD LDS). You might still find
references in documentation to ADAM.
One instance of AD LDS can have multiple application partitions, each of which
can be mapped to a Content Engine realm. Therefore one instance of AD LDS can
be mapped to multiple Content Engine realms.
For each realm, you must create an application server authentication provider and
a DirectoryConfigurationADAM object, to establish a one-to-one relationship
between Realm object and authentication provider, and also a one-to-one
relationship between Realm object and DirectoryConfigurationADAM object. The
initial set of these objects is created during Content Engine configuration.
For each DirectoryConfiguration object, FileNet P8 extracts the realm name from
the specified UserBaseDN property value by comparing it with each application
partition. For example, if the UserBaseDN for this DirectoryConfiguration object is
"ou=people, o=isp ", and there are two application partitions: "o=isp" and
"dc=filenet,dc=com", the realm name for this DirectoryConfiguration object is
"o=isp".
The following graphic shows Content Engine authenticating with AD LDS:
Login
GCD

Application server
IBM FileNet Content Engine
GCD directory
configuration objects

Object
store
Authorization

Application server
authentication
configuration

Authentication

AD LDS
Native AD LDS user objects
(IBM FileNet Content Engine supports AD LDS-only
authentication if user login credentials are found in a
native AD LDS user object)

The next graphic shows the optional configuration of Content Engine

authenticating with AD LDS configured for proxy login and search to Active

160

Security Extract

Directory. When a user logs in using an ID found in a the AD LDS object, AD LDS
redirects authentication to Active Directory.
Login
GCD

Application server
IBM FileNet Content Engine
GCD directory
configuration Objects

Object
store

Application server
authentication
configuration

Authorization

Authentication

AD LDS
Native AD LDS user objects

Synchronizing AD LDS with

Active Directory is optional

AD to AD LDS
Synchronizer

Active Directory
AD User accounts

(IBM FileNet Content Engine supports AD LDS-only

authentication if user login credentials are found in a
native AD LDS user object)

Proxy objects
(IBM FileNet Content Engine supports use of AD
LDS proxy objects to map to regular AD accounts)

Authentication
redirect

You can optionally use the Synchronizer tool, a built-in feature of AD LDS, to pull
user account information from Active Directory. In this scenario, AD LDS user
accounts are proxy users. P8 provides support for native and proxy users in AD
LDS as follows:
v If a user class is based on userProxyFull, which stores the user ID in AD LDS
while the account password remains in Active Directory, AD LDS will re-direct
bind requests to Active Directory.
v If a class lists msds-BindProxy as its auxiliary class, then it is a proxy user, and
AD LDS will re-direct bind requests to Active Directory.
v If a class such as organizationalPerson lists msds-bindableObject as its auxiliary
class, then AD LDS processes the bind request directly as a native AD LDS user.
v P8 does not support users based on userProxy, which does not contain the
required e-mail address attribute.
When properly configured this provides one-way data flow from Active Directory
to AD LDS. You could continue to provision AD LDS-only accounts in AD LDS,
and both types of accounts could authenticate to a FileNet P8 application,
following normal configuration of Content Engine classes' Default Instance Security
tabs in Enterprise Manager. The application does not need to be aware of this
Active Directory interaction.
Consult your AD LDS documentation for how to use the userProxyFull object and
the msds-bindableObject auxiliary class.
Important: It is a best practice to configure SSL between your application server
that hosts Content Engine and your AD LDS servers. This will include making
changes in the application server to the authentication provider's
DirectoryConfigurationADAM object that was created while running Configuration
Manager. Consult your application server's documentation for instructions.

Directory service providers

161

Support matrix (Active Directory Lightweight Directory

Services)
Use this support matrix as a quick lookup of supported directory features.
Table of Active Directory LDS features that are identified as being supported or not supported by Content Engine.
AD LDS Features

Supported by Content Engine

One way SSL

Yes

Two way SSL

No

Static Groups / Security Groups

Yes

Nested Groups

Yes

Dynamic Groups

Not applicable

Universal Groups

Not applicable

Roles

No - Roles are not used by FileNet P8 services and are

not part of the LDAP standard. Do not confuse this Roles
with the AD LDS Roles container which is just a
container of groups.

Referrals for Logon

No

Referrals for Search (for User and Group retrieval)

No

Chaining

No

Directory aliases

No

Native Mode Active Directory

Not applicable

Mixed Mode Active Directory

Not applicable

Support multiple realms

Yes - Each realm corresponds to one AD LDS application

partition.

Restrict to single realm

Yes - By configuring just one authentication provider and

one directory configuration.

Support domains across multiple forests

Not applicable

Login to any W2k domain in the forest (implies 2-way

trust)

Not applicable

Login to NT 1 way trust domains in the forest

Not applicable

Configurable user name for login

Yes - The short or common name does not contain realm

information. Short names must be unique across all of
your configured application partitions and realms.

Configurable user display name

Yes

Configurable group display name

Yes

Configurable group name for persisting

Yes - Group names are not persisted in the Content

Engine database, even though they are persisted in stored
searches and workflow definitions. Because the short
name does not contain realm information, short names
must be unique across all your configured domains and
realms.

Use email attribute as short name

Yes - for user short name

Do not use email for group short name

162

Security Extract

Table of Active Directory LDS features that are identified as being supported or not supported by Content Engine.
AD LDS Features

Supported by Content Engine

Server side sorting

Yes (Required) - Server Side Sorting (SSS) must be

enabled. This is because Process Engine and other FileNet
P8 components call on Content Engine to perform
searches using a sorted paging mechanism. Without SSS,
you will experience errors such as in Workplace when
retrieving a document, when trying to open Process
Designer via Workplace, or when starting a Connection
Point on Application Engine. Note that SSS is normally
enabled by default but is sometimes disabled due to
concerns with performance.

MaxTempTableSize

AD LDS descending sort property MaxTempTableSize has

upper limit of 100,000. If the result set for descending sort
is larger than the limit, AD LDS server returns LDAP
error code 12.

Support AD LDS users (for login and Search)

Yes

Support use for login and search of userProxyFull class

Yes
and objects such as the organizationalPerson class, with a
static auxiliary class of msds-bindableObject
Support Windows (domain & local) users (login and
Search)

No

Users in Application Partitions

Yes

Users in Configuration and Schema partitions

No - There is a patch from Microsoft that allows AD LDS

users to reside in the Configuration partition. However,
FileNet P8 does not support this.

LDAP attributes to read in a group entry when resolving

member users and member groups

member

Directory Configuration Properties (Active Directory

Lightweight Directory Services)
A list of the properties in the DirectoryConfigurationADAM class.
v For authentication, use Configuration Manager's Configure LDAP screen to view
or modify editable properties.
v For authorization, use Enterprise Manager to view or modify editable properties.
See FileNet P8 domain properties (Directory config tab) for information.
List of properties for the DirectoryConfigurationADAM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

ClassDescription

No

A ClassDescription object containing the fixed

description of the class from which a given object
is instantiated.

DirectoryServerHost

Yes

Specifies the name of the host that is running the

directory server product.

DirectoryServerPassword

Yes

Specifies the user password used to authenticate

to a given directory server.

DirectoryServerPort

Yes

Specifies the port number of the directory server.

The value of this property defaults to port 389 for
all supported directory server types.

Directory service providers

163

List of properties for the DirectoryConfigurationADAM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

Description

DirectoryServerProviderClass

Yes

Specifies the directory server provider class name:

com.filenet.engine.security.AdamDirectoryProvider

DirectoryServerType

No

Specifies the type of directory server: AD LDS

DirectoryServerUserName

Yes

Specifies the user name for authenticating to the

directory server. Example:
cn=ceadmin,ou=people,o=isp

DisplayName

Yes

The user-readable, provider-specific name of an

object. This property is usually the designated
Name property of the object's class.

GroupBaseDN

Yes

The base DN for searching for groups in the

directory server. Example: ou=people,o=isp

GroupDisplayNameAttribute

Yes

Specifies the display name for a Group object

generated by the authentication provider: cn

GroupMembershipSearchFilter

Yes

The search filter for group membership queries.

Example:
(&(objectClass=group)(member={0}))

GroupNameAttribute

Yes

GroupSearchFilter

Yes

Defines the directory server attribute to be used as

the short name for a group: cn
Specifies search filter for groups. Example:
(&(objectclass=group)(cn={0}))
where cn has been set as the short name.
GroupSearchFilter must use the same LDAP
attribute as GroupNameAttribute.

GroupUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each group. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the UserUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Id

No

An object's globally unique ID (GUID).

IsSSLEnabled

Yes

Defines whether or not Secure Sockets Layer (SSL)

protocol is enabled for a given
DirectoryConfiguration object. The default value is
false, indicating that SSL is disabled.

RestrictMembershipTo
ConfiguredRealms

Yes

This property has no effect because AD LDS does

not support cross-domain group membership.

UserBaseDN

Yes

The base DN for searching for users in the

directory server. Example: ou=people,o=isp

UserDisplayNameAttribute

Yes

Specifies the display name for a User object

generated by the authentication provider: cn

UserShortNameAttribute

Yes

The directory service attribute that has been

configured as the Logon Attribute.

164

Security Extract

List of properties for the DirectoryConfigurationADAM class, whether it can be edited, and a description for each
property.
Property Name

Editable?

UserSearchFilter

Yes

Description
Specifies search filter for users:
(&(objectClass=person)(cn={0}))
where cn has been set as the short name. This
filter finds both native AD LDS accounts and
Active Directory accounts referenced by the
userProxyFull object or objects configured with
msDS-bindableObject as a static auxiliary class.
UserSearchFilter must use the same LDAP
attribute as UserNameAttribute.

UserUniqueIDAttribute

Yes

The directory service attribute that serves as the

security identifier (SID) for each user. Select an
attribute whose values are unique and do not
change over time. Typically, this attribute is the
same as the GroupUniqueIDAttribute.
You must use only those LDAP attributes that
return Java String in the LDAP Java API.

Related information:
Directory configuration (FileNet P8 domain properties)

Get and search operations (Active Directory Lightweight

Directory Services)
Explains how Content Engine performs LDAP searches by various attributes.
Get User or Group by Short Name
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by short name.
3. If found, return.
If more than one user or group is found, Content Engine will log an error
and return the first user found. Content Engine requires that short names
be unique across domains.
Get User or Group by DN
1. Resolve the realm name from the DN.
2. Connect to corresponding host.
3. Search for the user/group by DN.
Get User or Group by UPN
AD LDS does not support the UserPrincipalName attribute (that attribute
is only supported by Active Directory). However, it does support the email
attribute, in which case the email address is treated as a short name.
Get User or Group by SID
Iterate through all realms. For each realm:
1. Connect to corresponding host.
2. Search for the user or group by SID.
Directory service providers

165

3. If found, return.
Search Users or Groups in a Given Realm
1. Connect to the host corresponding to the specified realm.
2. Search for the users or groups by the search criteria.

Directory service performance

There are certain things you can do to improve the performance of a FileNet
P8-initiated search of the directory service for users and groups.
Configuring sorting for Oracle Directory Server Enterprise Edition
Configuring sorting for Novell eDirectory on page 174

Configuring sorting for Oracle Directory Server Enterprise

Edition
You can configure your Oracle Directory Server Enterprise Edition or your Sun
Java System Directory Server to better support FileNet P8, especially in the area of
sorting.
Sun Java System Directory Server glossary definitions, for easy reference
All IDs Threshold
A size limit which is globally applied to every index key managed
by the server. When the size of an individual ID list reaches this
limit, the server replaces that ID list with an All IDs token.
browsing index
Otherwise known as the virtual list view index, speeds up the
display of entries in a targeted directory branch. Browsing indexes
can be created on any branch in the directory tree to improve
search performance.
filter

A constraint applied to a directory query that restricts the

information returned.

nsslapd-sizelimit (Size Limit)

A globally applied size limit that specifies the maximum number
of entries to return from a search operation. If this limit is reached,
ns-slapd returns any entries it has located that match the search
request, as well as an exceeded size limit error.
nsLookthroughLimit
Specifies the maximum number of entries that the directory will
check when examining candidate entries in response to a search
request. If entries to be checked exceeds this limit, an error is
returned.
substring index
Allows for efficient searching against substrings within entries.
virtual list view index
Otherwise known as a browsing index, speeds up the display of
entries in a targeted directory branch. Virtual list view indexes can
be created on any branchpoint in the directory tree to improve
search performance.
Recommendations

166

Security Extract

Consult the Sun Java System Directory Server documentation for more
information on the features mentioned here, particularly the chapter on
Directory Server Indexing in the Administration Guide.
v There is a performance cost associated with a wide range search such as
using a single character search pattern or no-pattern. When possible, use
a narrowed search pattern. For example, use a more complete
searchPattern string: stan instead of s.
v Create substring indexes for the uid and cn fields that typically map to
Content Engine's UserShortNameAttribute, GroupShortNameAttribute,
UserDisplayNameAttribute, and GroupDisplayNameAttribute
properties. (To view these properties in Enterprise Manager, right-click
the Root Domain node, select Properties, and then click the Directory
Config tab.).
v Increase the All Ids Threshold from its default of 4000, as appropriate.
For example, if its value is 4,000 and if there are more than 4,000 entries
in the Directory Server that start with sys, then the Directory Server
will no longer maintain that index. This means that Directory Server will
return an error if you do a sorted query for StartsWith sys, even if you
set the maximum results parameter to less than 4,000. According to Sun's
documentation, you should try to maintain this threshold at no less than
5% of your total directory. That is, the default of 4,000 assumes an
authentication directory containing approximately 80,000 entries. If your
directory contained 150,000 entries, you would probably want to increase
the All Ids Threshold to at least 7500.
v Increase the Look Through Limit from its default of 5000 to -1 (no limit)
so that there is no maximum number of accounts that will be checked in
any given search. An alternative would be to set this value to such a
large number that virtually no search would reach the maximum.
Important: The Directory Server might return an error when the
Directory Server entry count is over this limit, regardless of whether the
query is sorted.
v Increase the Size Limit parameter (default of 2000) to a value larger than
the maximum-results entry set for any associated FileNet P8 user
interface (for example, the FileNet P8 Workplace Site Preference setting
called Group and User Maximum Filter Size). This ensures that the
expected maximum number of results will be returned. Otherwise, users
could get back the number of records determined by the size limit
parameter and not be aware that there are in fact more entries that meet
the search criteria.
v Set a browsing index in your Sun Java System directory to improve the
performance of a no-pattern query.
Important: Queries without a search pattern are used to retrieve all
entries. if there is no matching browsing index and the resultant entries
count is greater than the All IDs Threshold Limit, Directory Server
returns an error such as:
[LDAP: error code 12 - Sort Response Control]

More information about the recommendations

Simply increasing the All IDs Threshold by itself is not advisable, given the
Sun Java System Directory Server recommendation to keep the All IDs
Threshold value at about 5% of the Directory Server total entry count.
Also, handling single-character searches without using a substring index
could incur performance problems. Therefore it is recommended that you
Directory service providers

167

select an approach combining browsing index, substring index, and

manipulating the All IDs Threshold. The following sections describe some
of the issues to be resolved while implementing the recommendations.
Create a substring index for sorting attributes
For each attribute to be sorted, create a substring index in order to support
the FileNet P8 pattern search. Remember that the Directory Server will still
return an error if the entry count for a specific index is over the setting of
All IDs Threshold.
You should enable a substring index for each attribute you assigned as
Content Engine's UserShortNameAttribute, GroupShortNameAttribute,
UserDisplayNameAttribute, and GroupDisplayNameAttribute. They are
shown on the Directory Config tab of the Root Domain node in Enterprise
Manager. For Content Engine, these attributes are normally uid and cn. For
Process Engine, the sort attribute is cn (display attribute in peboot.ini.)
The substring index does not support the case of querying all users (which
is done by leaving the FileNet P8 search string empty). This problem can
be resolved by creating a browsing index, because the filter is static so only
a few browsing indexes are needed.
Change the All IDs Threshold value
With the substring index enabled, a multi-character pattern search works
as long as the targeted pattern's entry count is less than All IDs Threshold.
Change the All IDs Threshold to a number greater than the Directory
Server entry count to ensure that single-character pattern searches work.
There are, however, some costs of doing so. For example, when an index
for a specific attribute value is over the All IDs Threshold value, the
Directory Server will not maintain the index list for that value. In order to
resolve this problem, the All IDs Threshold should be increased. The Sun
recommendation is to keep the All IDs Threshold value at about 5% of the
Directory Server total entry count, but even this percentage might have to
be adjusted.
Example
Assume the Directory Server has 80,000 entries and the threshold is 4000.
Also assume there are 5000 entries that start with pw and 1000 entries
that start with au. When you query for au* you get 1000 entries, no
error. But when you query pw* you would get an error because there are
more than 4000 entries that start with pw (in fact there are 5000 entries)
and Sun Java System Directory Server stops sorting for this case. You
would have to increase the threshold to a number over 5000 in order to get
back all entries that fulfill the query's specifications.
Effects of changing the All IDs Threshold without enabling a substring index
v When the Directory Server entry count is over the setting of All IDs
Threshold, Directory Server returns an error such as
[LDAP: error code 12 - Sort Response Control]

This could happen when searching using a broad search scope such as
with a single-character search pattern .
v All substring queries work as long as the All IDs Threshold is greater
than the Directory Server entry count.
v If you do not use a substring index, the search might complete without
error because the entries are within the limit, but you might experience
poor search performance.

168

Security Extract

Recommendation
v Change sizeLimit at the global config entry (dn: cn=config) to -1 (no
limit).
v Change nsslapd-lookthroughlimit to -1 (no limit).
v Set the All IDs Threshold to a value no less than 5% of the Directory
Server entry count, but monitor and test user and group account
searches carefully to determine whether a higher value might be more
appropriate.
How to create a browsing index on Sun One Directory Server (For Sun Java
System Directory Server, see procedure below.)
The substring index does not help queries without pattern. A query
without pattern returns an error when the Directory Server entry count is
over the All IDs Threshold value. You can avoid this error by creating a
browsing index for that specific search.
Consult the Administration Guide for Sun One Directory Server for more
details on managing browsing indexes.
Here are steps to create a browsing index. The following example uses the
following assumptions:
v dc=eng,dc=filenet,dc=com is a Directory suffix and is the base DN
v eng is the database name for this Directory suffix.
v the Short name and Display name of user entries is uid
v the Short name and Display name of group entries is cn
1. Create a file BrowsingIndex.txt with the following contents:
dn: cn="dc=eng,dc=filenet,dc=com:(objectClass=person)",
cn=eng,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: vlvSearch
cn: "dc=eng,dc=filenet,dc=com:(objectClass=person)"
vlvbase: dc=eng,dc=filenet,dc=com
vlvscope: 2
vlvfilter: (&(objectClass=person)(uid=*))
dn: cn=sort uid,cn="dc=eng,dc=FileNet,
dc=com:(objectClass=person)", cn=eng, cn=ldbm database,
cn=plugins,cn=config
objectClass: top
objectClass: vlvIndex
cn: sort uid
vlvSort: uid
dn: cn=rev sort uid, cn="dc=eng,dc=filenet,
dc=com:(objectClass=person)", cn=eng, cn=ldbm database,
cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: rev sort uid
vlvSort: -uid
dn: cn="dc=eng,dc=filenet,
dc=com:(objectClass=groupOfUniqueNames)", cn=eng,
cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvSearch
Directory service providers

169

cn: "dc=eng,dc=filenet,dc=com:(objectClass=groupOfUniqueNames)"
vlvbase: dc=eng,dc=filenet,dc=com
vlvscope: 2
vlvfilter: (&(objectClass=groupOfUniqueNames)(cn=*))
dn: cn=sort cn,cn="dc=eng,dc=filenet,
dc=com:(objectClass=groupOfUniqueNames)", cn=eng,
cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: vlvIndex
cn: sort cn
vlvSort: cn
dn: cn=rev sort cn,cn="dc=eng,dc=filenet,
dc=com:(objectClass=groupOfUniqueNames)", cn=eng,
cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: rev sort cn
vlvSort: -cn
dn: cn=sort_users_cn,cn="dc=eng,dc=filenet,
dc=com:(objectClass=person)", cn=eng,
cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: vlvIndex
cn: sort_users_cn
vlvSort: cn
dn: cn=rev_sort_users_cn,cn="dc=eng,dc=filenet,
dc=com:(objectClass=person)", cn=eng,
cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: rev_sort_users_cn
vlvSort: -cn

The first three entries are browsing-index entries for querying users.
The next three entries are browsing- index entries for querying
groups. The last two are sort indexes on objectClass=person, based
on cn instead of uid. Each vlvSearch entry is tied to a specific base
DN and a specific filter.
The vlvBase must be the same as specified in the User/Group Base
DN in Enterprise Manager's Directory Configuration. The vlvFilter
must match the User/Group Search Filter as well. For instance, if the
following User Search Filter is specified in Directory Configuration:
(&(objectClass=person)(uid={0}))

then the vlvFilter should be (&(objectClass=person)(uid=*)).

The valid values for vlvScope are:
0

the base entry alone

the immediate children of the base

the entire subtree rooted at the base

However, only 2 should be used since Content Engine's search query

always implies a subtree search.
Both vlvSearch and vlvIndex entries should be named. In this
example, the vlvSearch name is formed by concatenating the base DN

170

Security Extract

and the filter as a unique name. For the user case, one vlvIndex is
named "sort uid" and the second one is named "rev sort uid". It is
assumed that the user Short name attribute and Display name
attribute are the same attribute: uid. If they are not the same, then two
more vlvIndex entries should be added for another attribute. In this
example, these vlvSearch and vlvIndex entries are specific to the base
DN dc=eng,dc=filenet,dc=com. If there are more realms on the server,
a new set of entries should be added for each realm.
2. Run the ldapmodify utility to create vlvSearch and vlvIndex entries
using the above file as input:
<SUNONE_INSTALL_DIR>\shared\bin\ldapmodify -a -h
<SUNONE_HOST_NAME> -p <SUNONE_PORT_NUMBER> -D
<USER_ID> -w <PASSWORD> -f <full path of BrowsingIndex.txt>

For example,
Ldapmodify -a -h hq-sunds -p 1389 -D "cn=Directory Manager"
-w -Directory Manager" -f C:\temp\BrowsingIndex.txt

3. Stop the directory server:

In the Sun One Directory Server console, under Tasks tab, click Stop
Directory Server.
4. Create browsing indexes on Sun One Directory Server:
<SUNONE_INSTALL_DIR>\bin\slapd\server\slapd db2index -D
"<SUNONE_INSTALL_DIR>\slapd- <SUNONE_SERVER_NAME>"
-n <DB_NAME> -T "sort uid"
<SUNONE_INSTALL_DIR>\bin\slapd\server\slapd db2index -D
"<SUNONE_INSTALL_DIR>\slapd- <SUNONE_SERVER_NAME>"
-n <DB_NAME> -T "rev sort uid"
<SUNONE_INSTALL_DIR>\bin\slapd\server\slapd db2index -D
"<SUNONE_INSTALL_DIR>\slapd- <SUNONE_SERVER_NAME>"
-n <DB_NAME> -T "sort cn"
<SUNONE_INSTALL_DIR>\bin\slapd\server\slapd db2index -D
"<SUNONE_INSTALL_DIR>\slapd- <SUNONE_SERVER_NAME>"
-n <DB_NAME> -T "rev sort cn"

Repeat the process above if there are more indexes added to the
BrowsingIndex.txt file.
Note that <DB_NAME> is the cn name under cn=idbm
database,cn=plugins,cn=config. For example,
Slapd db2index -D "C:\Program Files\Sun\MPS\slapd-myserver"
-n eng -T "sort uid"

5. Start the directory server.

6. Run the Sun One Directory Server Console, and open a server
window.
7. Click the Directory tab.
8. Expand config in the left pane, then expand plugins and ldbm
database.
9. Click <DB_Name> entry, such as eng in this example and verify that
there are vlvSearch entries (for both user and group) created by the
earlier step.
10. Right-click the <DB_NAME> entry, and select Set Access
Permissions.
11. Add a new ACI as anonymous user. This will allow all users to access
these vlvSearch entries in the database.

Directory service providers

171

How to create a browsing index on Sun Java System Directory Server

The substring index does not help queries without pattern. A query
without pattern returns an error when the Directory Server entry count is
over the All IDs Threshold value. You can avoid this error by creating a
browsing index for that specific search.
Consult the Administration Guide for Sun Java System Directory Server for
more details on managing browsing indexes.
Here are steps to create a browsing index. The following example uses the
following assumptions:
v dc=eng,dc=filenet,dc=com is a Directory suffix and is the base DN
v eng is the database name for this Directory suffix.
v the Short name and Display name of user entries is uid
v the Short name and Display name of group entries is cn
1. Create a file BrowsingIndex.txt with the following contents:
dn: cn="dc=eng, dc=filenet, dc=com:(objectClass=person)",
cn=eng, cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvSearch
cn: "dc=eng,dc=filenet,dc=com:(objectClass=person)"
vlvbase: dc=eng,dc=filenet,dc=com
vlvscope: 2
vlvfilter: (&(objectClass=person)(uid=*))
dn: cn=sort uid, cn="dc=eng, dc=FileNet, dc=com:(objectClass=person)",
cn=eng, cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: sort uid
vlvSort: uid
dn: cn=rev sort uid, cn="dc=eng,dc=filenet,dc=com:(objectClass=person)",
cn=eng, cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: rev sort uid
vlvSort: -uid
dn: cn="dc=eng, dc=filenet, dc=com:(objectClass=groupOfUniqueNames)",
cn=eng, cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvSearch
cn: "dc=eng,dc=filenet,dc=com:(objectClass=groupOfUniqueNames)"
vlvbase: dc=eng,dc=filenet,dc=com
vlvscope: 2
vlvfilter: (&(objectClass=groupOfUniqueNames)(cn=*))
dn: cn=sort cn, cn="dc=eng, dc=filenet,
dc=com:(objectClass=groupOfUniqueNames)",
cn=eng, cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: sort cn
vlvSort: cn
dn: cn=rev sort cn,cn="dc=eng,dc=filenet,
dc=com:(objectClass=groupOfUniqueNames)",

172

Security Extract

cn=eng, cn=ldbm database, cn=plugins, cn=config

objectClass: top
objectClass: vlvIndex
cn: rev sort cn
vlvSort: -cn
dn: cn=sort_users_cn, cn="dc=eng, dc=filenet,
dc=com:(objectClass=person)", cn=eng, cn=ldbm database,
cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: sort_users_cn
vlvSort: cn
dn: cn=rev_sort_users_cn, cn="dc=eng, dc=filenet,
dc=com:(objectClass=person)", cn=eng,
cn=ldbm database, cn=plugins, cn=config
objectClass: top
objectClass: vlvIndex
cn: rev_sort_users_cn
vlvSort: -cn

The first three entries are browsing-index entries for querying users.
The next three entries are browsing- index entries for querying groups.
The last two are sort indexes on objectClass=person, based on cn
instead of uid. Each vlvSearch entry is tied to a specific base DN and a
specific filter.
The vlvBase should be the same as specified in the User/Group Base
DN in Enterprise Manager's Directory Configuration. The vlvFilter
should match the User/Group Search Filter as well. For instance, if the
following User Search Filter is specified in Directory Configuration:
(&(objectClass=person)(uid={0}))

then the vlvFilter should be (&(objectClass=person)(uid=*)).

The valid values for vlvScope are:
0

the base entry alone

the immediate children of the base

the entire subtree rooted at the base

However, only 2 should be used since Content Engine's search query

always implies a subtree search.
Both vlvSearch and vlvIndex entries should be named. In this example,
the vlvSearch name is formed by concatenating the base DN and the
filter as a unique name. For the user case, one vlvIndex is named "sort
uid" and the second one is named "rev sort uid". It is assumed that the
user Short name attribute and Display name attribute are the same
attribute: uid. If they are not the same, then two more vlvIndex entries
should be added for another attribute. In this example, these vlvSearch
and vlvIndex entries are specific to the base DN
dc=eng,dc=filenet,dc=com. If there are more realms on the server, a
new set of entries should be added for each realm.
2. Run the ldapmodify utility to create vlvSearch and vlvIndex entries
using the above file as input:
<SUNONE_INSTALL_DIR>\shared\bin\ldapmodify -a -h
<SUNONE_HOST_NAME> -p <SUNONE_PORT_NUMBER> -D
<USER_ID> -w <PASSWORD> -f <full path of BrowsingIndex.txt>
Directory service providers

173

For example,
Ldapmodify -a -h hq-sunds -p 1389 -D "cn=Directory Manager"
-w -Directory Manager" -f C:\temp\BrowsingIndex.txt

3. Stop the directory server:

In the Sun Directory Service Control Center, navigate to the Server
Operation > Main tab and click Stop.
4. Create browsing indexes on Sun Java System Directory Server:
<SJDS_INSTALL_DIR>\bin\dsadm reindex l b t <vlvIndex Name>
<LDAP_SERVER_INSTANCE> <SJDS_SERVER_NAME>

Repeat the command above for all vlvIndexes. For example,

Note that <DB_NAME> is the cn name under cn=idbm
database,cn=plugins, cn=config. For example,
Dsadm reindex l b t sort uid ..\local\instance1 hq-sunds

5. Start the directory server.

6. Run the Sun Directory Server Control Center, then select the directory
server Entry Management > Access Control.
7. Click New ACI from Wizard and follow the steps to create an ACI that
grants access rights to all users to search using the vlvSearch entries
just created. On the Choose Target step, use the browse button to select
the entry that is the parent of the vlvSearch entries created earlier. For
example,
cn=eng,cn=ldbm database,cn=plugins,cn=config

In the Options dropdown box, select ACI Applies to All Entries

Below This Entry.

Configuring sorting for Novell eDirectory

For best sorting performance, create an index for each user and group short name
and display name attribute. For example, add an index for cn and choose rule:
substring.
Also you must have a copy of all objects within the user and group search scope.
If the search scope starts at the top of the directory tree, Novell eDirectory must
have a copy of every replica. The replica must be Master, read/write, and
read-only. Consult Novell eDirectory documentation and support for complete
information and assistance.
To
1.
2.
3.

use ConsoleOne:
In ConsoleOne, right-click the Server object.
Click Properties > Indexes > Add
Enter the Index Name. If you do not enter an index name, the attribute is
automatically assigned as the index.

4. Select an attribute.
5. Select the index rule.
v Value matches the entire value or the first part of the value of an attribute.
For example, value matching could be used to find entries with a LastName
that is equal to "Jensen" and entries with a LastName that begins with "Jen".
v Presence requires only the presence of an attribute rather than specific
attribute values. A query to find all entries with a Login Script attribute
would use a presence index.

174

Security Extract

Substring matches a subset of the attribute value string. For example, a

query to find a LastName with "der" would return matches for Derington,
Anderson, and Lauder.

A substring index is the most resource intensive index to create and

maintain.
6. Click OK to update the index table.
7. Click Apply to restart Limber as a background process and initiate the change.
v

Directory service providers

175

176

Security Extract

Users and groups required by FileNet P8

Most of the account required by FileNet P8 are created during system installation.
Use this help section as a look-up reference of the users, groups, security access
roles, and security-related responsibilities required by FileNet P8 and its family of
applications.
Accounts are referred to in documentation in the following ways:
v By a display name; for example, Database User Name. An account's display
name is how the IBM FileNet P8 user interface, such as a setup program or
dialog box, refers to the account. Many accounts have both a display name and
a variable.
v By a variable designator; for example ce_db_user, using lower-cased italics and
underscores. The variable is intended to show that you must designate your
own account to act in the role described by the variable. The variable is the
unique identifier for a particular account.
Operating system accounts
Directory server accounts on page 190
Database accounts on page 201
Application server accounts on page 207
FileNet P8 internal accounts on page 209

Operating system accounts

The operating system accounts required by FileNet P8 components are listed here.
Accounts are referred to in documentation in the following ways:
v By a display name; for example, Database User Name. An account's display
name is how the IBM FileNet P8 user interface, such as a setup program or
dialog box, refers to the account. Many accounts have both a display name and
a variable.
v By a variable designator; for example ce_db_user, using lower-cased italics and
underscores. The variable is intended to show that you must designate your
own account to act in the role described by the variable. The variable is the
unique identifier for a particular account.
Application Engine or Workplace XT installer account on page 178
Application Engine or Workplace XT deploy account on page 180
Content Engine application server installation administrator on page 181
Content Engine application server installation group on page 181
Content Engine installer account on page 182
Content Engine operating system user account on page 182
Content Engine installer account on page 183
Configuration Manager user on page 184
Content Engine user account for DB2 for Linux, UNIX and Windows on page
184
Content Engine user account for DB2 for z/OS on page 185
Content Engine instance accounts for DB2 for z/OS on page 185
Copyright IBM Corp. 2006, 2011

177

Process Engine installer account on page 185

Process Engine database user for DB2 for Linux, UNIX and Windows on page
186
Process Engine database user for DB2 for z/OS on page 187
IBM Legacy Content Search Engine operating system user on page 187
IBM Legacy Content Search Engine security group on page 188
IBM Legacy Content Search Engine security user on page 189
IBM Content Search Services operating system account on page 189
IBM Content Search Services installer account on page 189

Application Engine or Workplace XT installer account

An operating system account that you use to run the installation program for
Application Engine or Workplace XT.
Application Engine or Workplace XT installer account (Windows)
Unique identifier
ae_install_user or wpxt_install_user
Description
The operating system account you will use to log on to a Windows
machine and launch the Application Engine or Workplace XT
installation program.
Minimum required permissions
This account must be a Windows Local administrator or a user
with equivalent permissions.
If the P8TASKMAN_HOME environment variable exists, you must
grant read and write permission to the ../Common
Files/taskmaninstances.xml file. The default location for Common
Files for Windows: C:\Program Files\IBM\FileNet\Common Files.
The installer account (ae_install_user or wpxt_install_user) must be
granted read/write/execute permission to these directories and
files:
Installation paths (ae_install_path or wpxt_install_path)
Grant ae_install_user read and write permission to the
ae_install_path.
Grant wpxt_install_user read and write permission to the
wpxt_install_path.
WebSphere Application Server
WAS_HOME/profiles/default/installedApps/
node_name/app_engine_war.ear/app_engine.war
WAS_HOME/profiles/default/config/cells/
machine_name/Node01cell/nodes/machine_name/
Node01/serverindex.xml
WebLogic 9.x
BEA_Home/bea/user_projects/domains/
domain_name/bin/startWebLogic.sh or
startWebLogic.cmd
BEA_home/bea/user_projects/domains/
domain_name/config/config.xml

178

Security Extract

WebLogic 10.x
BEA_Home/bea/wlserver_10.0/server/bin/
startWLS.sh or start WLS.cmd
BEA_home/bea/user_projects/domains/
domain_name/config/config.xml
JBoss

JBOSS_home/bin/run.sh or run.bat
JBOSS_home/server/default/conf/loginconfig.xml (on both Content Engine and
Application Engine servers)

Installation paths (BPMClient_directory)

Grant ae_install_user read and write permission to the
BPMClient_directory.
Grant wpxt_install_user read and write permission to the
BPMClient_directory.
Default BPMClient directory (Windows):
c:\Program Files\IBM\FileNet\BPMClient
Application Engine or Workplace XT installer account (UNIX)
Unique identifier
ae_install_user or wpxt_install_user
Description
The operating account you will use to log on to a UNIX machine
and launch the Application Engine or Workplace XT installation
program.
Minimum required permissions
If the P8TASKMAN_HOME environment variable exists, you must
grant read and write permission to the ../Common
Files/taskmaninstances.xml file. The default location for Common
Files for UNIX: /opt/IBM/FileNet/CommonFiles.
The installer account (ae_install_user or wpxt_install_user) must be
granted read/write/execute permission to these directories and
files:
Installation paths (ae_install_path or wpxt_install_path)
Grant ae_install_user read and write permission to the
ae_install_path.
Grant wpxt_install_user read and write permission to the
wpxt_install_path.
WebSphere Application Server
WAS_HOME/profiles/default/installedApps/
node_name/app_engine_war.ear/app_engine.war
WAS_HOME/profiles/default/config/cells/
machine_name/Node01cell/nodes/machine_name/
Node01/serverindex.xml
WebLogic 9.x
BEA_Home/bea/user_projects/domains/
domain_name/bin/startWebLogic.sh or
startWebLogic.cmd

Users and groups required by FileNet P8

179

BEA_home/bea/user_projects/domains/
domain_name/config/config.xml
WebLogic 10.x
BEA_Home/bea/wlserver_10.0/server/bin/
startWLS.sh or start WLS.cmd
BEA_home/bea/user_projects/domains/
domain_name/config/config.xml
JBoss

JBOSS_home/bin/run.sh or run.bat
JBOSS_home/server/default/conf/loginconfig.xml (on both Content Engine and
Application Engine servers)

Installation paths (BPMClient_directory)

Grant ae_install_user read and write permission to the
BPMClient_directory.
Grant wpxt_install_user read and write permission to the
BPMClient_directory.
Default BPMClient directory (UNIX):
/opt/IBM/FileNet/BPMClient

Application Engine or Workplace XT deploy account

An operating system account that you use to deploy Application Engine or
Workplace XT.
Application Engine or Workplace XT deployment account
Unique identifier
ae_deploy_user or wpxt_deploy_user
Description
This account will have permissions to deploy an application. It can
be the same as the Application Engine or Workplace XT installer
account.
Minimum required permissions
The deployment account (ae_deploy_user or wpxt_deploy_user) must
be granted read/write/execute permission to these directories and
files:
WebSphere Application Server
WAS_HOME/profiles/default/installedApps/node_name/
app_engine_war.ear/app_engine.war
WAS_HOME/profiles/default/config/cells/machine_name/
Node01cell/nodes/machine_name/Node01/serverindex.xml
WebLogic 9.x
BEA_Home/bea/user_projects/domains/domain_name/bin/
startWebLogic.sh or startWebLogic.cmd
BEA_home/bea/user_projects/domains/domain_name/config/
config.xml
WebLogic 10.x
BEA_Home/bea/wlserver_10.0/server/bin/startWLS.sh or
start WLS.cmd

180

Security Extract

BEA_home/bea/user_projects/domains/domain_name/config/
config.xml
JBoss

JBOSS_home/bin/run.sh or run.bat
JBOSS_home/server/default/conf/login-config.xml (on
both Content Engine and Application Engine servers)

Content Engine application server installation administrator

An operating system account you used to install the Content Engine's application
server.
Content Engine application server installation administrator
Unique identifier
ce_appserver_install_user
Description
The ce_appserver_install_user account is needed during the
installation process to perform the following tasks:
v Create and configure the application server/domain/profile for
Content Engine.
v Start or stop the application server when needed.
If you are prompted for credentials (which might happen if
WebSphere Global security is enabled or if WebLogic is in
Production Mode), pass in the credentials of the appserver_admin
or appserver_console_user. See those entries for more information.
v Modify the application server files or directories as needed for
deploying Content Engine using the Configuration Manager tool.
v Provide create, read and write permissions for directories on
devices or drives that are used for external Content Engine file
storage.
ce_appserver_install_user must belong to the
ce_appserver_install_group.
Minimum required permissions

Content Engine application server installation group

An operating system group account to which several Content Engine accounts
must belong.
Content Engine application server installation group
Unique identifier
ce_appserver_install_group
Description
An operating system group account. You will be instructed to grant
certain permissions to this group during Content Engine
installation and configuration.
The user accounts in ce_appserver_install_group will perform the
following tasks:
v Give operating system privileges to the directories used for
Content Engine installation and for the application server's
instance/domain/profile.

Users and groups required by FileNet P8

181

v Configure and deploy the Content Engine EAR files which

require access to the application server's instance/domain/
profile directories.
v Have permissions on devices/drives to read and write that are
designated for external Content Engine file storage.
Minimum required permissions
Use your local machine's administrative tools to add the following
accounts to this group:
v ce_appserver_install_user
v ce_install_user
v config_mgr_user

Content Engine installer account

An operating system account you use to install Content Engine.
Content Engine installer account (Windows)
Unique identifier
ce_install_user
Description
An operating system account used to run the Content Engine
installation program.
Minimum required permissions
Use Windows administrative tools to add ce_install_user to the
Local Administrators group and to the ce_appserver_install_group.
Content Engine installer account (UNIX)
Unique identifier
ce_install_user
Description
An operating system account used to run the Content Engine
installation program.
Minimum required permissions
Use your UNIX administrative tools to grant ce_install_user at least
the following permissions:
v Read, write, and execute permissions to the device or location
where:
Content Engine is to be installed.
The application server instance/domain/profile has been
installed.
v Write permission to the directories where you create file storage
areas, index areas, and content caches.
v Write permission on the /tmp directory.
v Membership in the ce_appserver_install_group.

Content Engine operating system user account

The account you use to create and configure the shared root directory of a file
storage area or content cache area.
Content Engine operating system user

182

Security Extract

Unique identifier
ce_os_user
Description
An operating system account you must log on as to create and
configure the shared root directory of a file storage area or content
cache area.
The operating system 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 in using the same ce_os_user account to secure the
folders and files in the file system that Content Engine will use for
a file storage area.
Minimum required permissions
Windows
For Windows-based Content Engine and file storage areas,
ce_os_user must reside in the same Windows domain or in
trusted Windows domains as the servers that host Content
Engine and the file storage area.
For Windows-based file storage areas and using
WebSphere: you must set the WebSphere service to logon
as the ce_os_user.
UNIX For UNIX-based Content Engine and file storage areas,
configuring security requires the use of NFS.

Content Engine installer account

An operating system account you use to install Content Engine.
Content Engine installer account (Windows)
Unique identifier
ce_install_user
Description
An operating system account used to run the Content Engine
installation program.
Minimum required permissions
Use Windows administrative tools to add ce_install_user to the
Local Administrators group and to the ce_appserver_install_group.
Content Engine installer account (UNIX)
Unique identifier
ce_install_user
Description
An operating system account used to run the Content Engine
installation program.
Minimum required permissions
Use your UNIX administrative tools to grant ce_install_user at least
the following permissions:

Users and groups required by FileNet P8

183

v Read, write, and execute permissions to the device or location

where:
Content Engine is to be installed.
The application server instance/domain/profile has been
installed.
v Write permission to the directories where you create file storage
areas, index areas, and content caches.
v Write permission on the /tmp directory.
v Membership in the ce_appserver_install_group.

Configuration Manager user

An operating system account you use to run Configuration Manager.
Configuration Manager user
Unique identifier
config_mgr_user
Description
An operating system account you will use to run Configuration
Manager.
Minimum required permissions
config_mgr_user must belong to the ce_appserver_install_group.
(Windows only) Using Active Directory tools, add config_mgr_user
to either the Power Users group or the Local Administrators group.
At several points in the installation process you will be instructed
to grant additional permissions to config_mgr_user, including the
following permissions:
v Execute permission to the Configuration Manager executable file,
configmgr.exe (Windows) or configmgr.sh (UNIX).
v Read and write permission to the directory where Configuration
Manager will create the configuration XML files. For example:
the directory you specify using the optional -path parameter
when you run Configuration Manager.
the default directory, ce_install_path/tools/
configurationmanager/tasks, if you do not specify a path
parameter.

Content Engine user account for DB2 for Linux, UNIX and
Windows
An operating system account on the database server that Content Engine uses to
access DB2 for Linux, UNIX and Windows.
Content Engine database user (DB2 for Linux, UNIX and Windows)
Unique identifier
ce_db_user
Description
This user account is granted database permissions for Content
Engine access to the DB2 database. Separate accounts can be used
for each object store, but are not required.

184

Security Extract

Additional database-specific permissions must be added by the

DBA.
Minimum required permissions
Access to the DB2 for Linux, UNIX and Windows GCD database
and each object store database.
See the DBA section for the database permissions required by this
account.

Content Engine user account for DB2 for z/OS

An operating system user account that Content Engine uses to connect to DB2 for
z/OS databases containing the GCD and object stores.
Content Engine database user (DB2 for z/OS)
Unique identifier
ce_db_user
Description
Operating system user accounts on the database server. Use one
account for the GCD (for example, ce_db_user1) and one for each
object store (for example, ce_db_user2, ce_db_user3, and so on)
A single ce_db_user can be granted access to multiple object stores,
depending on your installation requirements.
DB2 for z/OS does not allow underscores in account names.
Minimum required permissions
The DBA grants this account permissions for Content Engine
access to the DB2 database.

Content Engine instance accounts for DB2 for z/OS

Operating system and database user and group accounts that Content Engine uses
to connect to DB2 for z/OS.
Instance owner and instance owner primary group (DB2 for Linux, UNIX and
Windows)
Unique identifiers
ce_db_db2_ instanceowner and ce_db_db2_group
Description
Operating system user and group that must exist on the database
server. The ce_db_db2_ instanceowner will create databases and set a
number of configuration parameters.
Minimum required permissions
The DBA grants these accounts permissions for Content Engine
access to DB2 for Linux, UNIX and Windows.

Process Engine installer account

An operating system account you use to install Process Engine.
Process Engine installer account
Unique identifier
pe_install_user

Users and groups required by FileNet P8

185

Description
An operating system user account you log on as to run the Process
Engine installation program.
Minimum required permissions (Windows)
Use your Windows administrative tools to grant this account at
least the following permissions:
v Read, write, and execute permissions to the device or location
where Process Engine is to be installed, by default C:\Program
Files\IBM\FileNet\ProcessEngine.
v Read, write, and execute permissions to the device or location
where Process Engine common files are to be installed, by
default C:\Program Files\IBM\FileNet\Common Files
v Write permission on the .\Common Files\taskmaninstances.xml
file, if the P8TASKMAN_HOME environment variable exists.
v Write permission on the %tmp% directory
If you install as a non-administrative user you must log on after
the installation as an administrator to run a script to edit the
registry and create the Process Engine Manager service.
Minimum required permissions (UNIX)
Use your UNIX administrative tools to grant this account at least
the following permissions:
v Read, write, and execute permissions to the device or location
where Process Engine is to be installed, by default
/opt/IBM/FileNet/ProcessEngine.
v Read, write, and execute permissions to the device or location
where Process Engine common files are to be installed, by
default /opt/IBM/FileNet/CommonFiles.
v Write permission on the ./CommonFiles/taskmaninstances.xml
file, if the P8TASKMAN_HOME environment variable exists.
v Write permission on the %tmp% directory
If you want to configure Process Engine to automatically start, this
user must also have root permission to modify the /etc/inittab
file.

Process Engine database user for DB2 for Linux, UNIX and
Windows
A database account on the database server that Process Engine uses to access DB2
for Linux, UNIX and Windows. This account is initially created as an operating
system account.
Process Engine database user for DB2 for Linux, UNIX and Windows
Unique identifier
pe_db_user
Description
This user is required to configure the Process Engine database. The
IT administrator (ITA) creates this operating system account, after
which the database administrator (DBA) grants it additional
database permissions.
In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.

186

Security Extract

Do not create databases with the RESTRICTIVE option.

Minimum required permissions
Use your database tools to grant the following database
permissions to this user account:
v CONNECT ON DATABASE
v CREATETAB
v USE OF TABLESPACES
v SELECT on SYSIBM.SYSVERSIONS
v SELECT on SYSCAT.DATATYPES (Object Store creation only)
v SELECT on SYSCAT.SYSINDEXES, SYSIBM.SYSDUMMY1
(Upgrade only)
v USAGE on workload SYSDEFAULTUSERWORKLOAD
v IMPLICIT_SCHEMA on DATABASE
For added security in a shared database environment, you can
remove the Connect privilege from the Public group.

Process Engine database user for DB2 for z/OS

An operating system account on the database server that Process Engine uses to
access DB2 for z/OS. This account is also granted database permissions by the
DBA.
Process Engine database user for DB2 for z/OS
Unique identifier
pe_db_user
Description
DB2 for z/OS does not allow underscores in account names.
This user does not need to have a separate file system for a home
directory. After creating the user and setting group memberships,
log off as root user, log on as the new user, and change the
password to avoid connection problems the first time the
pe_db_user is used.
In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.
Minimum required permissions
After creating this account on the operating system, database
permissions are granted by the DBA.

IBM Legacy Content Search Engine operating system user

The operating system account that IBM Legacy Content Search Engine runs as.
K2 Operating System User
Unique identifier
k2_os_user
Description
Windows services will run as k2_os_user. This user account must be
given administrator privileges for Windows on all machines on
which the IBM Legacy Content Search Engine software will be
installed.

Users and groups required by FileNet P8

187

If IBM Legacy Content Search Engine is to be in a Windows

workgroup, k2_os_user must be given the Log on as a service right
in the Local Security Policy. If IBM Legacy Content Search Engine
is to be in a Windows domain, k2_os_user must be given the Log
on as a service right in the Domain Security Policy.
UNIX processes will run as this user. k2_os_user can be an
unprivileged user; however, if your system is using SHADOW
PASSWORDS then the vspget process must run as the root user.
Minimum required permissions
Windows-based file storage areas: k2_os_user must have Read
access to the file storage area root directory and to the file storage
area's UNC path.
Unix-based file storage areas: one way to grant access to the
k2_os_user is to set the Set UID bit of all the K2 program files, and
then also set the owner of each program file to the k2_os_user,
which must also have Read/Execute access to the file storage area
root directory and to the file storage area's NFS path.
k2_os_user requires Read and Write permissions to the K2
collections directory and the collections temp directory. The IBM
Legacy Content Search Engine software needs to read the file
storage areas and write the full text index collections as part of the
full text indexing operation.

IBM Legacy Content Search Engine security group

An operating system group account used by IBM Legacy Content Search Engine to
secure K2 collections.
K2 security group
Unique identifier
k2_sec_group
Description
Specify this group in the User Group field of the Verity Domain
Configuration tab when you configure CBR in the Enterprise
Manager root domain property sheet. Enterprise Manager
automatically places the value assigned to the k2_sec_group on each
Verity Collection.
K2 security user accounts must be members of the k2_sec_group.
Only members of this group will have access to the collection.
Windows
k2_sec_group must be an Active Directory group when IBM Legacy
Content Search Engine is installed on a machine in a Windows
domain.
k2_sec_group must be a Windows local group when IBM Legacy
Content Search Engine is installed on a machine in a Windows
workgroup.
UNIX k2_sec_group must be a UNIX operating system group.

188

Security Extract

IBM Legacy Content Search Engine security user

An operating system user account used by Content Engine when logging onto the
IBM Legacy Content Search Engine Master Administration Server to perform
content-based retrieval (CBR).
K2 security user
Unique identifier
k2_sec_user
Description
Specify this account in the Verity Username field in the Verity
Domain Configuration tab when you configure CBR in Enterprise
Manager.
This user must be a member of the k2_sec_group. Only members of
this group will have access to the collection.
The k2_sec_user and k2_os_user can be the same user. If so, all
permissions listed for both users must be assigned to the single
account.
Content Engine logs on to IBM Legacy Content Search Engine
server using the credentials of the k2_sec_user account.
Minimum required permissions
Must be defined as an authorized K2 administrator in the K2
dashboard.

IBM Content Search Services operating system account

The operating system account that you use to start and stop the IBM Content
Search Services software.
IBM Content Search Services operating system account
Unique identifier
css_os_user
Description
Use this account to run the IBM Content Search Services startup
and shutdown commands.
Minimum required permissions
This account must be an operating system user with rights to run
the IBM Content Search Services startup and shutdown commands.
By default, the css_install_user can also run these commands.

IBM Content Search Services installer account

An operating system account you use to install IBM Content Search Services.
IBM Content Search Services installer account
Unique identifier
css_install_user
Description
Run the IBM Content Search Services installation program using
this account.
Minimum required permissions
On Windows, this account must be a Windows Local administrator
or a user with equivalent permissions.
Users and groups required by FileNet P8

189

Read/write/execute permission to the css_install_path.

Directory server accounts

The directory server, or LDAP, accounts required by FileNet P8 components are
listed here.
Accounts are referred to in documentation in the following ways:
v By a display name; for example, Database User Name. An account's display
name is how the IBM FileNet P8 user interface, such as a setup program or
dialog box, refers to the account. Many accounts have both a display name and
a variable.
v

By a variable designator; for example ce_db_user, using lower-cased italics and

underscores. The variable is intended to show that you must designate your
own account to act in the role described by the variable. The variable is the
unique identifier for a particular account.
Creating the application server administrative console user (WebSphere
Application Server)
Application Engine or Workplace XT administrator account on page 191
Content Engine upgrade user on page 191
Content Engine bootstrap account on page 192
GCD administrator on page 193
Object store administrator on page 193
Content Engine Service user (Active Directory) on page 194
Content Engine Service user (AD LDS) on page 195
Content Engine Service user (Oracle Directory Server Enterprise Edition) on
page 196
Content Engine Service user (Novell eDirectory) on page 197
Content Engine Service user (IBM Tivoli) on page 197
Content Engine Service user (Oracle Internet Directory) on page 198
Content Engine Service user (CA Directory) on page 199
Process Engine service user on page 199
Process Engine administrator group on page 200
Process Engine configuration group on page 200
Process Engine region administrator on page 200
Publishing user account on page 201
CFS for IS User on page 201

Creating the application server administrative console user

(WebSphere Application Server)
An LDAP account to which you have granted the WebSphere Application Server
administrative role.
1. Create the following directory service account:
WebSphere administrative console user
Unique identifier
appserver_console_user
Description
The appserver_console_user account is an LDAP account to which

190

Security Extract

you have granted the WebSphere Application Server

administrative role so that it can log in to the WebSphere
admin console.
If your WebSphere repository type is Stand-alone LDAP
registry, when you run the Configuration Manager Configure
LDAP task, enter the credentials of a valid LDAP user account
to be the appserver_console_user for the entry labeled
Administrative console user name. Configuration Manager
grants this account WebSphere admin console administrative
rights. Alternatively, you can enter an LDAP account that you
have already configured as a console administrator.
If your WebSphere Application Server LDAP repository type is
Federated repositories, you can use the same user account
defined as your appserver_admin. However, if you specify a user
for the Administrative console user name that is different from
appserver_admin, it must be unique across all federated realms
including the WebSphere Application Server local file-based
repository.
2.

Record this value in your customized Installation and Upgrade Worksheet.

To find this property, search the worksheet for instances of
appserver_console_user.

Application Engine or Workplace XT administrator account

A directory service account that you use to administer Application Engine or
Workplace XT.
Application Engine or Workplace XT admin account
Unique identifier
ae_admin_user or wpxt_admin_user
Description
This account serves in the role of Application Engine or Workplace
XT administrator. You will specify this account as a member of the
Application Engine or Workplace XT administrator role when you
set bootstrap preferences. The account must have a password.

Content Engine upgrade user

The directory service user account who runs the IBM FileNet P8 Content Engine
Upgrade Tool.
Content Engine upgrade user
Unique identifier
ce_upgrade_user
Description
The directory service user who runs the IBM FileNet P8 Content
Engine Upgrade Tool.
Minimum required permissions
v Read access to the Content Engine 3.5 directory (default location
is C:\Program Files\IBM\FileNet\Content Engine).
v Read access to the 3.5 version of sysinit.dat.
v Read/write access to the root directories for the file storage areas

Users and groups required by FileNet P8

191

v Full Control access to the FileNet P8 domain object (in other

words, a gcd_admin)
v Full Control access to all object stores in the FileNet P8 domain
(in other words, an object_store_admin for all object stores in the
FileNet P8 domain)
v (WebSphere only) Grant ce_upgrade_user the WebSphere
administrative Monitor role.
Related information:
Administrative roles (WebSphere Express (Distributed operating systems),
Version 7.0

Content Engine bootstrap account

A directory service account that Content Engine uses to establish a connection with
the application server, access the application server's JNDI tree, look up the data
sources for accessing the GCD, and start up Content Engine's background tasks.
Content Engine bootstrap account
Unique identifier
ce_bootstrap_admin
Description
The ce_bootstrap_admin, also known as the Content Engine system
user, is an LDAP account that is stored in the CEMPBoot.properties
file that is archived in the Content Engine EAR file. You enter the
bootstrap account's credentials while running the Configuration
Manager's Configure Bootstrap Properties task. Any deployments
of the EAR file for the same FileNet P8 domain must use the same
credentials for the bootstrap account.
Content Engine uses this account to authenticate to the application
server and access the datasources named in the GCDConnection
property. Content Engine will not be able to start if this user is not
able to authenticate.
In keeping with the principle of granting to an account only those
permissions necessary to accomplish its purpose, do not use the
ce_bootstrap_admin account to serve in the role of gcd_admin. This
can happen if you log in as ce_bootstrap_admin the first time you
start Enterprise Manager following initial installation. Doing this
places ce_bootstrap_admin on the security tab of the FileNet P8
domain object with Full Control access rights. The result is that the
ce_bootstrap_admin is functioning as the gcd_admin. This is not a
recommended configuration. If it is your configuration, consider
using Enterprise Manager to add a new gcd_admin account, making
sure to grant Full Control to the P8 domain, and then removing the
ce_bootstrap_admin from the security tab of the P8 domain.
To make sure it is not misused or locked out by accident, do not
use ce_bootstrap_admin as an all-purpose account. For example, if a
user tried to log on to some other application using the
ce_bootstrap_admin account and provided the wrong password
several times, thereby exceeding the number of allowable login
failures, this account could be locked out of the directory server,
depending on your local policies. This would mean that Content
Engine would not start.

192

Security Extract

If possible, exempt ce_bootstrap_admin from policies requiring

periodic password change.
If you change your system's login parameters so that the
ce_bootstrap_admin credentials are no longer valid, the result would
be that Content Engine will not be able to start. For example, if
you modified the User Short Name Attribute or User Search
Filter, in the application server's authentication provider and in
Enterprise Manager's P8 Domain Properties > Modify Directory
Configuration > User property sheet, from samAccountName to
distinguishedName, you would also need to make the same change
to the com.filenet.gcd.Username property in the
CEMPBoot.properties file.
Restriction: If you are deploying Content Engine on an application
server with federated user repositories and with multiple realms in
your FileNet P8 domain, be sure that no two realms contain the
same short name for this user; otherwise, this user will not be able
to create the GCD.
Minimum required permissions
The account must be a directory server account that resides in the
realm that has been configured for Content Engine authentication.

GCD administrator
A directory service account that has Full Control access to the Content Engine
domain object.
GCD administrator
Unique identifier
gcd_admin
Description
The gcd_admin is able to create, modify, and delete Content Engine
domain resources.
The gcd_admin account must reside in the directory service realm
specified in Configuration Manager's Configure LDAP task.
A GCD administrator can grant Full Control rights to additional
users and groups, thereby making them GCD administrators as
well. Being a GCD administrator does not automatically make you
an object_store_admin, which is assigned on the object store's own
property sheet.
Log on to Enterprise Manager as gcd_admin in order to:
v Create the GCD by launching the Configure New Domain
Permissions wizard the first time you start Enterprise Manager
to establish the FileNet P8 domain.
v Carry out administrative tasks for the FileNet P8 domain.
Minimum required permissions
Use Enterprise Manager to grant Full Control access to the Content
Engine domain object.

Object store administrator

A directory service account that has Full Control access to a Content Engine object
store.
Users and groups required by FileNet P8

193

Object Store administrator and group

Unique identifier
object_store_admin or object_store_admin_group
Description
A directory service account that can administer an object store by
having Full Control access to it. You can also grant Full Control to
an object store to group accounts, thereby making all members of
the group object store administrators.
Each time a gcd_admin runs the Object Store Wizard, you are asked
to specify the users and groups who should have administrative
access to the object store. Each object store could therefore have a
different set of object store administrators. Conversely, if you want
the same groups to administer all object stores in the FileNet P8
domain, you must add them while creating each new object store
using the Object Store Wizard. By default, the GCD administrator
creating the object store also becomes an object store administrator,
but you can remove it if your security design requires dedicated
accounts for each object store and GCD.
Object store administrative rights do not include the ability to add,
move, or remove object stores, fixed content devices, content cache
areas, or any of the other FileNet P8 domain resources. These
permissions are granted only to GCD administrators.
An object store administrator is not also a GCD administrator
unless also specifically granted those permissions. This means that
an object store administrator who is not also a GCD administrator
would have to request that a GCD administrator create a new
domain resource like an object store. Once these objects are created
by the GCD administrator, however, the object store administrator
can populate the object store with new classes and folders, store
content in the file storage area, assign markings, and so on.
The list of object store administrators is available for viewing and
modifying in Enterprise Manager's Object Store > Properties >
Security property page. You can add or remove users or groups
from this list at any time later on.
Tip: Keeping the number of accounts assigned as object store
administrators or object store users as small as possible will
improve performance and simplify administration. The best way to
do this is to use group accounts instead of large numbers of
individual users. Groups can have as many members as you wish
and can contain other groups.
Minimum required permissions
Use Enterprise Manager to grant an object_store_admin or
object_store_admin_group Full Control access to one or more object
stores.

Content Engine Service user (Active Directory)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (Active Directory)

194

Security Extract

Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the fully qualified distinguished name of ce_service_user as
the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
Use Active Directory tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each security realm that is configured for your FileNet
P8 domain:
v Read access rights (specifically the Read All Properties
permission) to the forest-wide configuration directory partition
and the domain directory partition in each desired domain in
the Active Directory forest. Because Authenticated Users by
default is a member of the Pre-Windows 2000 Compatible Access
group which has these permissions, you will need to assign the
permissions to ce_service_user only if the default is modified or
Authenticated Users access rights are restricted.

Content Engine Service user (AD LDS)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (Active Directory Lightweight Directory
Service) (AD LDS, formerly known as ADAM)
Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.

Users and groups required by FileNet P8

195

v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the fully qualified distinguished name of ce_service_user as
the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
An AD LDS user account that Content Engine uses to connect to a
single Microsoft AD LDS partition. To configure this, perform the
following steps:
1. Start ADAM ADSI Edit under Start > All Programs > ADAM.
2. Connect to the partition. Expand partition in left-hand pane
and click the CN=Roles node.) Be sure you have selected the
CN=Roles container in the partition not under the
CN=Configuration.)
3. In the right-hand pane right-click the CN=Readers group and
select Properties.
4. In the Attributes list double-click the member attribute.
5. Click Add ADAM Account.
6. Enter the full DN of the user to be designated as the service
user while running the Content Engine installation program,
and click OK.
7. Click OK and click OK again.
Related information:
Use ADSI Edit to Manage an AD LDS Instance

Content Engine Service user (Oracle Directory Server

Enterprise Edition)
A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (Oracle Directory Server Enterprise
Edition)
Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.

196

Security Extract

Provide the fully qualified distinguished name of ce_service_user as

the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
Use your directory server's tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each namingContext that is configured for your FileNet
P8 domain: Read, Search, Compare.

Content Engine Service user (Novell eDirectory)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (Novell eDirectory)
Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the fully qualified distinguished name of ce_service_user as
the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
Use your directory server's tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each namingContext that is configured for your FileNet
P8 domain: Read and Compare.
Related information:
Novell eDirectory 8.8 Rights

Content Engine Service user (IBM Tivoli)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (IBM Tivoli)

Users and groups required by FileNet P8

197

Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the fully qualified distinguished name of ce_service_user as
the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
Use your directory server's tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each namingContext that is configured for your FileNet
P8 domain: Read, Search, Compare.

Content Engine Service user (Oracle Internet Directory)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (Oracle Internet Directory)
Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the fully qualified distinguished name of ce_service_user as
the LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.

198

Security Extract

Minimum required permissions

Use your directory server's tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each namingContext that is configured for your FileNet
P8 domain: Read, Search, Compare.
Related information:
Managing Directory Access Control (Oracle Internet Directory 11g Release 1)

Content Engine Service user (CA Directory)

A directory service account that Content Engine uses to connect to the directory
server.
Directory service (bind) user account (CA Directory)
Unique identifier
ce_service_user
Description
Provide the fully qualified distinguished name of ce_service_user as
the directory service bind user name while running Configuration
Manager and also when you run the Enterprise Manager Directory
Configuration Wizard.
ce_service_user performs the following roles:
v Acts as the bind user specified by the application server to
search through realms to authenticate a user when the user logs
in to a Content Engine client such as Workplace.
v Acts as the user account that searches other users and groups in
the directory server for Content Engine authorization.
Provide the distinguished name of ce_service_user as the
LDAPBindDN while running Configuration Manager and also
when you run the Enterprise Manager Directory Configuration
Wizard. Available for viewing and modifying in the Enterprise
Manager's Directory configuration tab.
The Directory Service User cannot be accessed using referrals.
Minimum required permissions
Use your directory server's tools to grant ce_service_user at least the
following minimum rights to all entries (including user and group
entries) in each namingContext that is configured for your FileNet
P8 domain: Read, Search, Compare.

Process Engine service user

A directory server account that Process Engine uses to access Content Engine.
Process Engine service user
Unique identifier
pe_service_user
Description
Process Engine uses the pe_service_user when connecting to the
Content Engine server. This user must belong to the Process Engine
Administrator group.

Users and groups required by FileNet P8

199

Process Engine administrator group

A directory server group whose members can use Process Task Manager to manage
Process Engine.
Process Engine administrators group
Unique identifier
pe_admin_group
Description
Members of this group automatically have administrative
privileges for Process Engine.
Related concepts:
About workflow security

Process Engine configuration group

An optional directory server group whose members configure the Process Engine
workflow database.
Process Engine configuration group
Unique identifier
pe_config_group
Description
(Optional) Members of this group automatically have configuration
privileges for the Process Engine workflow database.
If this group is used to configure security on Process Task
Manager, members of this group or of the Process Engine
Administrator Group (pe_admin_group) can make configuration
changes to the workflow database. If the Process Engine
Configuration group is not used during this configuration, anyone
can make these changes.
Related concepts:
About workflow security

Process Engine region administrator

A directory server user account that is used by Process Engine to create isolated
regions.
Process Engine region admin
Unique identifier
pe_region_admin
Description
A directory server user account that has Full Control access rights
to the FileNet P8 domain, and has also been granted rights on the
Process Engine through its membership in the pe_admin_group. The
pe_region_admin therefore has permissions equivalent to the
gcd_admin but should be used only for Process Engine purposes.
Content Engine permissions can be granted by another gcd_admin
who uses Enterprise Manager to add the pe_region_admin to the
ACL of the FileNet P8 domain and grant it Full Control.

200

Security Extract

Process Engine permissions are granted by using your directory

server tools to add the pe_region_admin to the pe_admin_group. The
pe_admin_group's permissions on the Process Engine are configured
while running the Process Task Manager. Subsequently, the
pe_region_admin credentials are entered in Process Task Manager
and in PEInit, to create or modify Process Engine isolated regions.
Minimum required permissions
Full Control access rights on the FileNet P8 domain.
Membership in the Process Engine pe_admin_group.

Publishing user account

The account you use to run the Rendition Engine installation program.
Publishing user account
Unique identifier
FNRE_admin
Description
If installing Rendition Engine, a Windows domain user account
that must be added to the local Windows Administrators group on
all Rendition Engine servers.
On all servers where you intend to install Publishing components
(Publishing Plug-in servers and Rendition Engine servers that will
contain the publishing software), log in as a local administrator
and add the domain_name\FNRE_admin account to the local
Administrators group. Then log in as this user to run the Rendition
Engine installation program.
Minimum required permissions
Domain privileges in the Windows domain that contains the
FileNet P8 domain and local administrator privileges on the
machine where Rendition Engine is installed.

CFS for IS User

The FileNet Image Services account used by Content Engine to log on to and
access Image Services resources as part of Content Federation Services
configuration.
CFS for IS User
Description
Used whenever Content Engine accesses the Image Services system
as part of Content Federation Services configuration. Create the
account any time prior to creating a CFS fixed content device.
Refer to IBM FileNet Content Federation Services for Image Services
Planning and Configuration Guide for full reference information.

Database accounts
The database accounts required by FileNet P8 components are listed here.
Accounts are referred to in documentation in the following ways:

Users and groups required by FileNet P8

201

By a display name; for example, Database User Name. An account's display

name is how the IBM FileNet P8 user interface, such as a setup program or
dialog box, refers to the account. Many accounts have both a display name and
a variable.
v By a variable designator; for example ce_db_user, using lower-cased italics and
underscores. The variable is intended to show that you must designate your
own account to act in the role described by the variable. The variable is the
unique identifier for a particular account.
Content Engine SQL Server account
v

Content Engine Oracle account on page 203

Content Engine DB2 for Linux, UNIX and Windows account on page 203
Content Engine DB2 for z/OS account on page 204
Process Engine database user for DB2 for Linux, UNIX and Windows on page
205
Process Engine database user for DB2 for z/OS on page 205
Process Engine database user for Oracle on page 206
Process Engine database user for SQL Server on page 207

Content Engine SQL Server account

A database user account that Content Engine uses to connect to SQL Server
databases containing the GCD and object stores.
Content Engine database user (SQL Server)
Unique identifier
ce_db_user
Description
The database accounts that Content Engine uses to access SQL
Server. You can use the same account for the GCD and object store
databases. Or you can use one (for example, ce_db_user1 ) for the
GCD database and different accounts for each object store (for
example, ce_db_user2 , ce_db_user3 , and so on).
ce_db_user must be a SQL Server account. It does not have to be an
account in the configured directory service.
Minimum required permissions
Use your database tools to grant each ce_db_user at least the
following database access permissions:
v db_datawriter
v db_datareader
v db_ddladmin
v public
Add these accounts to SQL Server's master database and grant the
public role to each. When you perform the procedure Configuring
the JDBC distributed transaction components, these accounts will
also be granted the SqlJDBCXAUser role.

202

Security Extract

Related tasks:
Configuring the JDBC distributed transaction components

Content Engine Oracle account

A database user account that Content Engine uses to connect to Oracle databases
containing the GCD and object stores.
Content Engine database user (Oracle)
Unique identifier
ce_db_user
Description
The tablespace owner accounts that Content Engine uses to access
Oracle. Use one account for each object store tablespace and one
for the GCD tablespace.
Minimum required permissions
Grant each ce_db_user at least the following permissions:
v CREATE SESSION
v ALTER SESSION
CREATE TABLE
CREATE VIEW
CREATE SEQUENCE (Object Store creation only)
Alter user set QUOTA UNLIMITED on all tablespaces used by
db user
v SELECT on pending_trans$
v SELECT on dba_2pc_pending
v SELECT on dba_pending_transactions
v
v
v
v

v SELECT on DUAL
v SELECT on product_component_version
v SELECT on USER_INDEXES (Upgrade CE only)
In addition:
v On Oracle 10.2.0.4, Oracle 11.1.0.6.0 or later (where both the
JDBC client and the database server are at those levels), grant
the following:
EXECUTE on dbms_xa
v For Oracle releases earlier than 10.2.0.4, see Oracle Metalink
document ID 436362.1 for required patches, or grant this instead:
EXECUTE on dbms_system
Several of these permissions are required by Content Engine JDBC
XA transactions.

Content Engine DB2 for Linux, UNIX and Windows account

An operating system account on the database server that Content Engine uses to
access DB2 for Linux, UNIX and Windows databases containing the GCD and
object stores.
Content Engine database user (DB2 for Linux, UNIX and Windows)
Unique identifier
ce_db_user
Users and groups required by FileNet P8

203

Description
The IT administrator (ITA) creates this operating system account,
after which the database administrator (DBA) grants it additional
database permissions. Separate accounts can be used for each
object store, but are not required.
Do not create databases with the RESTRICTIVE option.
Minimum required permissions
Use your database tools to grant the following database
permissions to this user account:
v CONNECT ON DATABASE
v
v
v
v
v

CREATETAB
USE OF TABLESPACES
SELECT on SYSIBM.SYSVERSIONS
SELECT on SYSCAT.DATATYPES (Object Store creation only)
SELECT on SYSCAT.SYSINDEXES, SYSIBM.SYSDUMMY1
(Upgrade only)

v USAGE on workload SYSDEFAULTUSERWORKLOAD

v IMPLICIT_SCHEMA on DATABASE
For added security in a shared database environment, you can
remove the Connect privilege from the Public group.

Content Engine DB2 for z/OS account

An operating system and database user account that Content Engine uses to
connect to DB2 for z/OS databases containing the GCD and object stores.
Content Engine database user (DB2 for z/OS)
Unique identifier
ce_db_user
Description
Operating system user accounts on the database server. Use one
account for the GCD (for example, ce_db_user1) and one for each
object store (for example, ce_db_user2, ce_db_user3, and so on)
A single ce_db_user can be granted access to multiple object stores,
depending on your installation requirements.
DB2 for z/OS does not allow underscores in account names.
Minimum required permissions
Grant the following database permissions to this user:
v
v
v
v
v

GRANT
GRANT
GRANT
GRANT
GRANT

SYSADM TO ce_db_user
USE OF STOGROUP storagegroupname TO ce_db_user
USE OF BUFFERPOOL buffer_pool_name TO ce_db_user
SELECT ON SYSCAT.DATATYPES TO ce_db_user
SELECT ON SYSIBM.SYSVERSIONS TO ce_db_user

where:
ce_db_user
is the operating system user name created for the Content
Engine database user

204

Security Extract

storagegroupname
is the name of the storage group
buffer_pool_name
is the name of the buffer pool

Process Engine database user for DB2 for Linux, UNIX and
Windows
A database account on the database server that Process Engine uses to access DB2
for Linux, UNIX and Windows. This account is initially created as an operating
system account.
Process Engine database user for DB2 for Linux, UNIX and Windows
Unique identifier
pe_db_user
Description
This user is required to configure the Process Engine database. The
IT administrator (ITA) creates this operating system account, after
which the database administrator (DBA) grants it additional
database permissions.
In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.
Do not create databases with the RESTRICTIVE option.
Minimum required permissions
Use your database tools to grant the following database
permissions to this user account:
v CONNECT ON DATABASE
v CREATETAB
v USE OF TABLESPACES
v SELECT on SYSIBM.SYSVERSIONS
v SELECT on SYSCAT.DATATYPES (Object Store creation only)
v SELECT on SYSCAT.SYSINDEXES, SYSIBM.SYSDUMMY1
(Upgrade only)
v USAGE on workload SYSDEFAULTUSERWORKLOAD
v IMPLICIT_SCHEMA on DATABASE
For added security in a shared database environment, you can
remove the Connect privilege from the Public group.

Process Engine database user for DB2 for z/OS

A database account on the database server that Process Engine uses to access DB2
for z/OS. This account is initially created as an operating system account.
Process Engine database user for DB2 for z/OS
Unique identifier
pe_db_user
Description
The pe_db_user must have DBADM authority of the DB2 instance
that will be used by the Process Engine software.

Users and groups required by FileNet P8

205

DB2 for z/OS does not allow underscores in account names.

In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.
Minimum required permissions
Grant the following permissions to each user you created:
v GRANT DBADM ON DATABASE databasename TO
operatingsystemuser
v GRANT USE OF STOGROUP storagegroupname TO
operatingsystemuser
v GRANT USE OF BUFFERPOOL buffer_pool_name TO
operatingsystemuser
v GRANT SELECT ON SYSCAT.DATATYPES
v GRANT SELECT ON SYSIBM.SYSVERSIONS
where:
databasename
is the name of the Process Engine database
operatingsystemuser
is the name of the operating system user, pe_db_user
storagegroupname
is the name of the storage group assigned to the Process
Engine database
buffer_pool_name
is the name of the buffer pool

Process Engine database user for Oracle

A database user account that Process Engine uses to connect to Oracle.
Process Engine database user (Oracle)
Unique identifier
pe_db_user
Description
The tablespace owner accounts that Process Engine uses to access
Oracle.
In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.
Minimum required permissions
Grant each pe_db_user at least the following permissions:
v CREATE SESSION
v ALTER SESSION
CREATE TABLE
CREATE VIEW
CREATE SEQUENCE (Object Store creation only)
Alter user set QUOTA UNLIMITED on all tablespaces used by
db user
v SELECT on pending_trans$
v SELECT on dba_2pc_pending
v SELECT on dba_pending_transactions
v
v
v
v

206

Security Extract

v SELECT on DUAL
v SELECT on product_component_version
In addition:
v On Oracle 10.2.0.4, Oracle 11.1.0.6.0 or later (where both the
JDBC client and the database server are at those levels), grant
the following:
EXECUTE on dbms_xa
v For Oracle releases earlier than 10.2.0.4, see Oracle Metalink
document ID 436362.1 for required patches, or grant this instead:
EXECUTE on dbms_system

Process Engine database user for SQL Server

A database user account that Process Engine uses to connect to SQL Server.
Process Engine database user (SQL Server)
Unique identifier
pe_db_user
Description
The database account that Process Engine uses to access SQL
Server.
In a farmed or cluster configuration, each Process Engine must be
configured to use the same database user name.
Minimum required permissions
Use your database tools to grant each pe_db_user at least the
following database access permissions:
v db_datawriter
v db_datareader
v db_ddladmin
v public

Application server accounts

The application server accounts required by FileNet P8 components are listed here.
Accounts are referred to in documentation in the following ways:
v By a display name; for example, Database User Name. An account's display
name is how the IBM FileNet P8 user interface, such as a setup program or
dialog box, refers to the account. Many accounts have both a display name and
a variable.
v By a variable designator; for example ce_db_user, using lower-cased italics and
underscores. The variable is intended to show that you must designate your
own account to act in the role described by the variable. The variable is the
unique identifier for a particular account.
Application server administrator

Application server administrator

An application server administrator used while configuring Content Engine.
Application server administrator

Users and groups required by FileNet P8

207

Unique identifier
appserver_admin
Description
WebSphere Application Server
In Configuration Manager, when you run the Set Properties for
WebSphere Application Server task, enter the credentials of the
appserver_admin account in the field labeled Application server
administrator user name. Configuration Manager uses the
appserver_admin account to run configuration tasks.
WebSphere administrative security is enabled
You have two options for creating the appserver_admin user
account. You can use the local file-based account usually
defined while creating the WebSphere profile. Or, you can
use WebSphere tools to grant administrative rights to an
LDAP account and optionally remove the file-based
account created earlier.
The appserver_admin user account must have WebSphere
administrator permissions throughout the Content Engine
installation process. Afterwards, you can reduce the
account to a lesser role, such as Configurator.
WebSphere administrative security is not enabled
If you decide not to enable WebSphere administrative
security during profile creation, then no special credentials
are required to log in to the WebSphere admin console. You
can enter any string into the Configuration Manager field
labeled Application server administrator user name.
However, remember that to run Content Engine,
WebSphere administrative security must be enabled. When
you do enable it and the WebSphere admin console
requests an account to use as the admin user, enter the
appserver_admin.
Oracle WebLogic Server
In Configuration Manager, when you run the Set Properties for
Oracle WebLogic Server task, enter the credentials of the
appserver_admin account in the field labeled Application server
administrator user name. Configuration Manager uses the
appserver_admin account to run configuration tasks.
This user is defined when you create a new WebLogic domain.
The WebLogic Configuration wizard requires you to enter the
Administrator user name and password. This user is created as
an internal WebLogic application, file-based account. (It is not
an LDAP or operating system account.) Use the
appserver_admin account to log in to the Oracle WebLogic
Server administration console.
JBoss
JBoss does not require an administrative account.

208

Security Extract

FileNet P8 internal accounts

The accounts created and conferred with privileges by FileNet P8 are listed here.
PSConsole
PSDesigner
PWAdministrator on page 210
PWConfiguration on page 210
PWDesigner on page 210
PWDiagram on page 211
#AUTHENTICATED-USERS on page 211
#CREATOR-OWNER on page 212

PSConsole
Access role whose members can access Simulation Console from the Advanced
Author page.
PSConsole
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
You can restrict the ability to run Simulation Console by assigning
a group to the corresponding role in the Access roles preferences. If
a group is assigned to the role, only members of that group can
run Simulation Console.
Related concepts:
About workflow security
Related information:
Access roles preferences

PSDesigner
Access role whose members can access Simulation Designer from the Advanced
Author page.
PSDesigner
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
You can restrict the ability to run Simulation Designer by assigning
a group to the corresponding role in the Access roles preferences. If
a group is assigned to the role, only members of the group can run
Simulation Designer.

Users and groups required by FileNet P8

209

Related concepts:
About workflow security
Related information:
Access roles preferences

PWAdministrator
Access role whose members can access Process Administrator from the Admin
page in Workplace or the Tools menu in Workplace XT.
PWAdministrator
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
Must belong to the Process Engine Administrator Group
pe_admin_group. You can restrict the ability to run Process
Administrator by assigning a group to the corresponding role in
the Access roles preferences. If a group is assigned to the role, only
members of the group can run Process Administrator.
Related concepts:
About workflow security
Related information:
Access roles preferences

PWConfiguration
Access role whose members can access Process Configuration Console from the
Admin page in Workplace or the Tools menu in Workplace XT.
PWConfiguration
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
Must belong to the Process Engine Configuration Group
(pe_config_group). You can restrict the ability to run Process
Configuration Console by assigning a group to the corresponding
role in the Access roles preferences. If a group is assigned to the
role, only members of the group can run Process Configuration
Console.
Related concepts:
About workflow security
Related information:
Access roles preferences

PWDesigner
Access role whose members can access Process Designer in design and diagram
mode and the Workflow Subscription wizard from the Advanced Author page in
Workplace or the Tools menu in Workplace XT.

210

Security Extract

PWDesigner
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
You can restrict the ability to run Process Designer in design and
diagram mode by assigning a group to the corresponding role in
the Access roles preferences. If a group is assigned to the role, only
members of the group can run Process Designer.
Related concepts:
About workflow security
Related information:
Access roles preferences

PWDiagram
Access role whose members can access Process Designer in diagram mode from
the Advanced Author page in Workplace or the Tools menu in Workplace XT.
PWDiagram
Description
Created while defining site privileges. Access roles are stored as
values in custom objects in the object store.
Minimum required permissions
You can restrict the ability to run Process Designer in diagram
mode by assigning a group to the corresponding role in the Access
roles preferences. If a group is assigned to the role, only members
of the group can run Process Designer.
Related concepts:
About workflow security
Related information:
Access roles preferences

#AUTHENTICATED-USERS
A Content Engine logical group whose members are any authenticated user
principal. Any user account that who can successfully log in belongs to this group.
#AUTHENTICATED-USERS
#AUTHENTICATED-USERS is similar to the special groups Everyone in
Windows NT 4 and Authenticated Users in Windows 2000. It does not
have specific memberships that you can modify, and it does not include
anonymous users or guests.
If you specify #AUTHENTICATED-USERS to be a default user or group of
an object store, then all users who log in to the FileNet P8 domain are
automatically made members of this group. It will appear on the Default
Instance Security ACL of all classes. Therefore each instance of the class
will include #AUTHENTICATED-USERS on its own ACL. If you do not
change the default, the net effect will be that any user who can log in to
the FileNet P8 domain will be able to:
v View all object stores (default level = Use stores and services)
Users and groups required by FileNet P8

211

v View all folders (default level = View properties)

v View all documents, both properties and content (default level = View
content)
v View all custom objects (default level = View properties)
If this is not what you want, you could:
v Remove #AUTHENTICATED-USERS from the particular class or classes.
(You can, of course, remove it from individual objects, but this is not a
recommended method for efficiently administering security across many
classes and objects.)
v Add deny groups to the class' Default Instance ACL; this will
effectively remove the members of the deny group from the
#AUTHENTICATED-USERS group.
v Use a non-security method such as exploiting the IsHiddenContainer
property which Workplace and other applications use to hide a folder.
#AUTHENTICATED-USERS and #CREATOR-OWNER are referred to as
Special Accounts in Enterprise Manager's Select Users and Groups dialog
box.

#CREATOR-OWNER
The special Content Engine account granted to the user who creates an object.
#CREATOR-OWNER
#CREATOR-OWNER is a placeholder in an access control entry (ACE) and
is used for copying a defined set of permissions to the individual user who
is creating a new object. This copying takes place:
v When applying default instance security from a class to an instance of
the class.
v Whenever a security template places ACEs on an object.
v When performing inheritance propagation to a target ACE (such as from
a parent folder to a child folder).
By default, #CREATOR-OWNER appears on the Security and Default
Instance Security tabs of all instantiable classes, and is granted Full
Control, with an inheritable depth of This object only. This account
functions just like a normal user account, and its default permissions can
be edited according to normal rules (that is, by users with appropriate
permission).
When the ACE is inherited, the permissions granted to the
#CREATOR-OWNER become the permissions granted to the object's
current owner. For example, when a user creates a document based on a
document class, that user takes on the #CREATOR-OWNER's permissions.
Actually, two target ACEs result whenever the #CREATOR-OWNER is
copied onto an object - a substituted ACE and a non-substituted ACE:
v The substituted ACE is always created but is forced to be non-inheritable
(its inheritable depth becomes This object only regardless of the source
value).
v The unsubstituted ACE is a complete copy of the source ACE except that
if performing inheritance propagation the inheritable depth value can be
decremented (if it is not 0 or -1), and in all cases the unsubstituted ACE
will be suppressed if the (resulting) inheritable depth is zero.
Windows Authentication: the user attribute used is the samAccountName.

212

Security Extract

Oracle Directory Server Enterprise Edition and eDirectory: the user

attribute is configurable to the LogonAttribute in the GCD.
#AUTHENTICATED-USERS and #CREATOR-OWNER are referred to as
Special Accounts in Enterprise Manager's Select Users and Groups dialog
box.
Related tasks:
Take or change ownership

Users and groups required by FileNet P8

213

214

Security Extract

Security tools and procedures

Security administrators use a combination of component and IBM FileNet P8 tools
to carry out security configurations.
Table of security procedures and the IBM FileNet P8 tools used to carry out the procedure.
To do this...

Use this tool...

Comments

Define users and groups

The resources of your

directory server.

Users and groups reside in

the directory service of your
authentication provider, and
are cached on Content
Engineservers.

Add users and groups to

object stores, classes, and
security policies.

Enterprise Manager

See Start Enterprise Manager.

Define security policies

Security Policy wizard, on

either Enterprise Manager or
in the Workplace or
Workplace XT applications

In Enterprise Manager, use

the Security Policy Wizard.
To assign the security policy
to a document class you
must use Enterprise
Manager.
Workplace or Workplace XT
users can use the Security
Policy Wizard.

Assign access rights to

Process Configuration
workflow queues and rosters Console

Start Process Configuration

Console from the Workplace
Admin page or the
Workplace XT Tools menu.

Set site preferences

Site Preferences

Start Site Preferences from

the Workplace Admin page
or the Workplace XT Tools
menu.

Create document classes and

folders, configure folders to
serve as security parents to
contained documents

Enterprise Manager

By default, all users can

create top-level folders. As
the administrator, you can
modify the root folder's
security if you wish to
prevent users from creating
top-level folders.

Content Engine bootstrap properties on page 216

Digital signing on page 219
Displaying security on page 219
Logging on and using Enterprise Manager on page 222
Network security on page 223
Encryption on page 224
TLS, SSL, and data privacy on page 227

Copyright IBM Corp. 2006, 2011

215

Related information:
Start Enterprise Manager
Create a security policy
Assign a security policy
Site preferences

Content Engine bootstrap properties

Content Engine needs bootstrap information in order to create the Global
Configuration Database (GCD), and thereafter to provide the resources it needs to
boot up. During Content Engine configuration, Configuration Manager configures
the bootstrap file with information supplied by the user. Once Content Engine is
configured and the new FileNet P8 domain is created and functioning, the
bootstrap file continues to provide the information below to allow Content Engine
to load. The bootstrap file is named CEMPBoot.properties and is contained in the
Content Engine EAR file.
There are two reasons why you would edit the bootstrap file:
v The value of the Username property has to be changed. The account defined in
the Username property is referred to in documentation as the "Content Engine
system user" (ce_bootstrap_admin).
v The Java Naming and Directory Interface (JNDI) data sources are no longer
available.
With planning and normal precautions, you can typically avoid these situations so
that you never need to edit the bootstrap file. However, if these situations do
occur, you can use either the Configuration Manager tool or the command line
Bootstrap Configuration Utility (BCU) to edit the file, as described below. Note that
changing the bootstrap password is a more complex procedure. For complete
instructions on changing the password, see How to change Bootstrap admin
password.
All deployments of the EAR file, for the purpose of adding additional Content
Engine servers to the FileNet P8 domain, must use identical values for the
bootstrap properties. Therefore, any changes you make to the EAR file for a system
in production must be made to all such EAR files. Depending on how your Java
2 Enterprise Edition (J2EE) application server is configured, these changes could be
made as part of an automated deployment process.
Sample CEMPBoot.properties file
The following is a sample bootstrap file showing sample values for the properties.
In the example, the value for EncryptedPassword has already been set and
programmatically encrypted by the Master Key.
com.filenet.gcd.CipherKeyLength=128
com.filenet.gcd.Username=CEMPAdmin
com.filenet.gcd.DigestAlgorithm=SHA
com.filenet.gcd.GCDConnection=jndiname\=Domain1DS;jndinamexa\=Domain1DSXA
com.filenet.gcd.EncryptedPassword=8dd56a9d9331b9cbe43536a42ce8146d
com.filenet.gcd.CipherAlgorithm=AES

These properties are defined in the following table:

216

Security Extract

Table of bootstrap properties and definition

CEMPBootstrap properties

Definition

CipherKeyLength

Default length of the cipher key that will be used to

encrypt GCD credentials.

Username

A directory service account that is granted the role of

application server administrator while running
Configuration Manager's Configure Bootstrap Properties
task. This account will be used to log in to the application
server and access the datasources named in the
GCDConnection property. Content Engine runs as this
account, and it is therefore referred to in documentation
as the "Content Engine system user" or ce_bootstrap_admin.
The value for this property is entered while running
Configuration Manager's Configure Bootstrap Properties
task, which refers to this account as the "Bootstrap user".
See the entry for "Content Engine system user" in Users
and Groups.

DigestAlgorithm

Default digest algorithm used to perform encryption

using the Master Key. See Content Engine Encryption for
information about the Master Key.

GCDConnection

The two datasource names that will be used in the

creation of the GCD. Entered while running
Configuration Manager's Configure Bootstrap Properties
task.

EncryptedPassword

The encrypted password of the user identified by the

Username property. Entered while running Configuration
Manager's Configure Bootstrap Properties task. The
encryption was carried out using the Master Key.

CipherAlgorithm

Default algorithm used to perform encryption using the

Master Key.

Edit Content Engine Bootstrap properties with the Bootstrap Configuration

Utility
The Bootstrap Configuration Utility is a tool that edits the CEMPBoot.properties
file. The bootstrap tool is contained in the BootstrapConfig.jar file, which is
installed by the Content Engine installation program into the Program
Files\FileNet\ContentEngine\lib folder.
Use the command as follows:
java -jar BootstrapConfig.jar ...
-h
-v
-e file -l
-e file -rf
-e file -j file
-e file [-fnq] [-b bits] [-c algorithm] ...
[-g name] [-i name] [-k key] [-m algorithm] ...
[-p password] [-s name] [-u name] [-x name] ...
[-y class] [-o Boolean] [-w port] [-j file]
where

-b bits
Cryptographic key length (in bits)
Security tools and procedures

217

-c algorithm
Cryptographic cipher algorithm
-e file
Filename and optional path of the EAR file
-f Forces the utility to ignore warnings
-g name
Cryptographic message digest provider
-h Displays this help message
-i name
Cryptographic cipher provider
-j file
File path of the EAR file to be patched with bootstrap info
-k key
Optional. The seed string used to generate the Master cryptographic key. Using
a seed is not FIPS-140 compliant. If there is no seed string the key will be
generated randomly.
-l Lists the current configuration
-m algorithm
Cryptographic message digest algorithm
-n Forces the utility to store a plaintext password
-o Boolean
Forces master key safe mode
-p password
Password associated with username
-q Suppresses text output
-r Restores the configuration to default values
-s name
JNDI datasource name (non-XA)
-t filepath
Inserts the specified file into the EAR file
-u name
Username of an app server administrator
-v Displays version and copyright information
-w port
HTTP Port for WSI (wasp.servlet.httpport)
-x name
JNDI datasource name (XA)
-y class
Keystore handler class name (with package)

Example
The following example shows how you would upgrade a new
CEMPBoot.properties file by copying the CEMPBoot.properties file from a source

218

Security Extract

(old) EAR file's props.jar file to a target (new) EAR file. The properties in the
target will be overwritten. (The example shows WebSphere as the application
server.)
java -jar BootstrapConfig.jar -e /opt/FileNet/ContentEngine/lib/
bootstrap_path/Engine-ws.ear -j /temp_device/Engine-ws.ear.

where:
-e introduces the source (old) EAR file
-j introduces the target (new) EAR file
ws denotes WebSphere
wl denotes WebLogic
jb denotes single JBoss
jbc
denotes the cluster installation of JBoss
If the props.jar or CEMPBoot.properties files do not exist in the target, they will
be created based on the source. Creating the files can fix some cases of malformed
target EAR files.
To run the example command, perform the following steps:
1. Backup the old EAR file (the file referenced by the -e switch in the above
example).
2. Run the command shown in the example.
3. Copy the new EAR file (the file referenced by the -j switch in the example) in
the temp_device. Paste it so that it overwrites the old EAR file in the current
bootstrap directory.
4. Use the Configuration Manager tool to create a new profile, or open an existing
profile, that includes the Deploy Application task. Run that task to re-deploy
the updated EAR file. Alternatively, you can manually redeploy the EAR file.

Digital signing
Java applets are digitally signed using an IBM certificate recognized by all
supported browsers.
When that certificate is periodically renewed, an Application Engine fix pack is
made available with newly signed applets. If you do not install that fix pack to
refresh the digital signatures, users will see additional confirmation dialog pop-ups
warning them of problems with the expired certificate.

Displaying security
Security is displayed in various ways by various FileNet P8 components.
Enterprise Manager security editor on page 220
Enterprise Manager's Select Users and Groups dialog box on page 221
Workplace and Workplace XT security editor on page 221
Site and user preferences on page 221

Security tools and procedures

219

Enterprise Manager security editor

Administrators can use Enterprise Manager to view and modify the security of an
object by opening its property sheet and going to the Security tab.
The Security tab contains several fields:
v Name: The display name of the user or group. If you hover your mouse above
the display name, you see the following information, depending on your
directory service provider and depending on how you have configured it for
login:

v
v
v

v
v

220

Security Extract

For Active Directory: The user principal name (UPN), for example,
[email protected].
For other directory service providers: The distinguished name (DN), for
example, uid=shawking,cn=users,dc=filenet,dc=com.
Source: ACEs can have different source types. If an ACE is editable (which is the
case if the permissions are Direct), you can tell because the various regions are
not disabled. An ACE whose Source is Template or Inherited are not editable,
and when selected the rest of the security editor becomes disabled.
Level: The possible levels for the object type are listed with radio buttons. The
users and groups who are specified as object store administrative groups while
running the object store wizard appear on all ACLs with Full Control. You can
change the level by selecting one of the radio buttons associated with the Levels.
Apply to: Also called inheritable depth, you can change the value using the
Apply to control box if the ACE is editable.
Type: Displays whether the ACE is allowed or denied, and also lets you change
the value if the ACE is editable.
(list of) Levels: List of security levels appropriate to the object. Different objects
have different sets of security levels. For documents, it includes such things as
the ability to publish and to create minor and major versions. A folder would
have a different set of security levels. When Full Control is selected all the other
lower levels are marked with an asterisk. The asterisk next to a Level means
that it is included in the Level currently selected; this behavior is the meaning of
all required bits are set.
(list of) Rights: When Full Control is selected as the Level, all Rights are
selected. If you were to clear just one of them, View all properties, for example,
the Level would automatically be changed to Custom, which means that the
collection of all selected Rights does not exactly match the requirements of the
predefined Levels. If you were to reselect View all properties so that all the
Rights were selected, the Full Control level would again be automatically
selected.
Add: Click to add users and groups.
Remove: Click to remove the selected ACE from the ACL. This does not remove
the user or group from the directory server or from any other ACL the ACE
might be present on.
Active Marking/Owner: Click to view or edit the ownership of this object.

Related information:
Security tab
Select users and groups
Access control settings (Owner tab)

Enterprise Manager's Select Users and Groups dialog box

Enterprise Manager contains a search function that runs a query against the
configured directory server to find users and groups.
When you click Add while displaying an Access Control List (ACL) in one of
Enterprise Manager's Security dialog boxes, it starts the Select Users and Groups
dialog box. This dialog box lets you search for accounts in the FileNet P8 domain's
configured directory service. When you find the users or group accounts you want
to add to the ACL, click OK to add them to the ACL
Related information:
Select users and groups

Workplace and Workplace XT security editor

Workplace and Workplace XT display ACLs and ACEs using a different interface
than Enterprise Manager but with many of the same features.
Users with sufficient access can use the security editor to assign users and groups
to the ACL of the object, and to grant specific levels of access. The default level of
access that users of an object store get when they are added while running the
object store wizard (in its Specify Initial User Groups page), is View Properties on
folders and View Content documents. A user must have View Properties access
rights to see an item in an object store. If the user can see the item, the user can
also see the item's properties and security.
To open an object store, users must have View Properties access to the root folder.
Related information:
Manage security

Site and user preferences

Site preferences configure the appearance, behavior, and connectivity of the
Workplace and Workplace XT applications.
A site preference determines whether users can view and modify security while
adding a new document. Application users can optionally configure their own user
preferences which will override the corresponding site preferences. Not all site
preferences have a matching user preference.
The first user to log in to the Application Engine after installation sets the
bootstrap preferences and is added as a member of the Application Engine
Administrators group. The settings entered during bootstrap initialization can be
changed later in Site Preferences. Bootstrap initialization creates a preference file
for the site and saves it in the /Preferences folder of the designated object store. It
also updates the bootstrap.properties file and saves it to Application Engine on a
network file server. The table below describes the preferences that have security
implications.

Security tools and procedures

221

Table that lists the site preferences for security and the associated security options that can be set.
Site Preference

Security options

Allow guests

Identify a guest account. Enter any valid user name (but

not the domain Guest account or, if authenticating with
Oracle Directory Server Enterprise Edition, a user with a
blank password) and password to identify a guest
account. When defined, the sign-on page allows a user to
log in by clicking Sign In as Guest.

Security info

Redirect logins to an SSL server to secure user IDs and

passwords between the Application Engine server and
the client.

Security page visibility

Show or hide the security page when application users

add folders, add documents, or check in documents. If
shown, users can see and modify security settings when
performing these tasks. If using an Entry Template which
specifies whether to show or hide the security page, it
will override the preference setting.

Access roles preferences

Assign access roles.

Keep-alive interval

Set the Session Timeout to limit the length of an inactive

session.

Related information:
Site preferences files
Guest info
Security info
General settings for Author
Access roles preferences
Keep alive interval

Logging on and using Enterprise Manager

Enterprise Manager is the system administrator's primary tool for working with
FileNet P8 security. By design, FileNet P8 applications like Workplace or
Application Integration expose a subset of the full security interface required to
completely understand and maintain FileNet P8 security.

Starting Enterprise Manager

Enterprise Manager installs and runs only on machines running the Windows
operating system. Anyone who can log in to the machine containing Enterprise
Manager can start Enterprise Manager. But Enterprise Manager itself will check the
user's credentials by presenting a login window. The default and saved values in
this dialog box are contained in a settings file named EMDomainConfig.xml.
So that users can roam and log in to Enterprise Manager from different
workstations and also work with individualized, private copies of the settings file,
the installed EMDomainConfig.xml is automatically copied to the logged in user's
application data area. For example, in Windows XP and assuming Content Engine
is installed to the default location, the file would be copied to C:\Documents and
Settings\billg\Application Data\FileNet\ContentEngine\EMDomainConfig.xml,
where billg is the user's login name. (Microsoft Vista uses a different location.)

222

Security Extract

When Enterprise Manager loads and tries to read connection information from
EMDomainConfig.xml, it looks first in the user's ...\Application Data\ directory. If
the file is not found, then EMDomainConfig.xml is copied from Enterprise Manager
installation area to the user's ...\Application Data\ directory where it is read
from the new location.
Important: EMDomainConfig.xml also stores configuration settings for FileNet
Publishing Style Template Manager which also supports roaming logins.

Logging on to an object store

Each object store has its own ACL, comprised of the administrative users
(object_store_admin) added to the Object Store Wizard's Specify Administrators
page. Since each object store could have a different set of administrators, each
object store requires a login before Enterprise Manager will make its features
available, as explained below.
However, each object store displayed in Enterprise Manager will check the user's
access rights before making its full feature set available, as follows:
Table that maps the access rights necessary to access the listed object store menu items.
To access these menu items ...

... you need this access right

Expand object store tree

Object store: Full Control

Object Store > object store name > Logon

menu

Object store: Connect to store

Object Stores > New Object Store menu

Object Store > Object Store name > New
Storage Area menu

Domain root: Create new stores

Sites > Site_name > Content Cache Area >

New Content Cache area menu
Object Store > Delete menu

Domain root: Delete child objects

Storage Areas > Delete menu

Domain root: Delete child objects

Content Cache Areas > Delete menu

Related information:
Log on to a domain
Specify object store administrators
Log on to the object store

Network security
The security of your FileNet P8 installation on your corporate network is the
responsibility of the security administrator and is not described here.
The topics in this help section are only intended to explain what the relationship of
FileNet P8 technology is in regard to issues like firewalls, digital signing, and SSL,
and do not fully explain how to configure and maintain these important security
components.

Security tools and procedures

223

Encryption
IBM FileNet P8 provides methods for encrypting the credentials and network
communications.
Content Engine credential encryption
Encrypting Credentials
Resetting keys on page 226
Content encryption on page 227

Content Engine credential encryption

Content Engine encrypts credentials that are stored in the Global Configuration
Database (GCD).
Content Engine encrypts the following credentials that are stored in the Global
Configuration Database (GCD).
v The Verity domain passwords.
v The Image Services password used for CFS content federation.
v The CFS-IBM Content Integrator password used for CFS content federation.
v The Tivoli Storage Manager (TSM) password.
v Third-party fixed storage device credentials (Centera, Snaplock).
v Rendition Engine passwords.
v The password for the Directory service user (ce_service_user) for each Directory
Configuration.
v The CMOD password used for CFS content federation.
v The isolated region key that is shared between Content Engine and Process
Engine.
Tip: You can view and modify all of these IDs and passwords in Enterprise
Manager.
The following credentials are also encrypted but are not stored in the GCD:
v The P8 Identity Tokens that are generated as a part of Process Engine
authentication via Content Engine (same as isolated region key). These are
generated dynamically, and never persisted.
v Passwords used in publishing to password protect PDF files. These are stored in
the object store database, with a Publish Style Template. To edit these passwords,
use the Publish Style Template Manager application.
Any attempt to retrieve these password fields via any public API returns zero
length binary data. This results in a null value when any object containing a
password field is exported. You must reset the password before you can use the
imported object.
Related information:
View and modify FileNet P8 domain properties

Encrypting Credentials

FileNet P8 provides methods for encrypting credentials that are passed over an
internet connection.

|
|

224

Security Extract

Content Engine

|
|
|
|
|

Content Engine uses a single 128-bit Master Key for encrypting and decrypting all
credentials. The Master Key is generated while running Configuration Manager's
Configure Bootstrap Properties task, using a FIPS 140-compliant key generation
algorithm. The Master Key is stored in the Content Engine EAR file where it can
be used by the Content Engine server, but is not available via any API.

|
|
|

Content Engine uses symmetric key encryption to encrypt sensitive password data
at rest in the GCD. It uses a single encryption algorithm and strength using the
FIPS-140 compliant 128-bit AES encryption.

|
|
|
|
|
|

The Master Key is a part of the bootstrap properties that are encoded into an EAR
file by Configuration Manager's Configure Bootstrap Properties task. As long as the
original bootstrapped EAR file (or a backup of it) is available, Configuration
Manager's Configure Bootstrap Properties task (or the Bootstrap Configuration
Utility) can be used to transfer these properties to a new EAR file, when installing
a Content Engine patch or upgrade.

|
|
|
|
|

However, if the bootstrapped EAR file is lost and no backup exists, it is not
possible to generate a new version with the same Master Key. A new EAR file with
a different Master Key would have to be generated, and all passwords (as well as
the Isolated Region key) would have to be reset. For this reason, it is important to
keep a backup of your EAR file once it has been bootstrapped.

|
|
|

All EAR files deployed across all servers in a FileNet P8 domain must use the
same Master Key. It is a best practice to use TLS or SSL when deploying the
Content Engine EAR file.

Process Engine

|
|
|
|
|
|

The default transport for Process Engine is IIOP. However, by using a FIPS-140
certificate, you can configure the Process Engine API to communicate with Process
Engine using the HTTPs protocol. HTTPs signals the browser to use an added
encryption layer of SSL (also called TLS) to protect network traffic.The 140 series of
Federal Information Processing Standards (FIPS) are United States government
computer security standards that specify requirements for cryptography modules.

|
|
|
|
|
|
|
|

Here are some examples of the Process Engine API communicating with Process
Engine:

|
|
|
|
|

The Process Engine installer automatically generates a default SSL certificate, using
the ktgen script. This script is located in the Process Engine installation directory. It
generates a self-signed certificate stored in the data directory, JPEDATA_DIR\
p8pekeys. When HTTPS is enabled, the certificate is sent to the Process Engine API
which uses it to secure the communications channel. The certificate lasts 3650 days.

|
|

To enable FIPS, the startpesvr script must contain the following line:

v When Content Engine launches a workflow.

v When Workplace or Workplace XT accesses the Tasks page, BPM applets, or
works with workflows.
v When IBM Case Manager uses Case Builder or Case Client.
v When a custom application uses Process Engine API, Process Engine REST API,
or Process Engine web Services.

-Djpeserver.useHTTPTunneling=true -Djpeserver.httptunnel.ssl=true
Security tools and procedures

225

|
|
|
|
|
|
|

To generate a new self-signed certificate and private key, delete the existing
p8pekeys file and then run the ktgen script. The ktgen script accepts an optional
argument for the keystore password. If you do not specify a keystore password, it
will use the default value of P8PESSLTOKEN. If the ktgen script was invoked with
a password parameter, you should modify the startpesvr script to reflect that
password by adding the following JVM system property:

|
|

To encrypt the password, run the genseed script located in the Process Engine
install directory, as shown in the following example:

install_path/FileNet/ProcessEngine/genseed password_string

|
|

The script will encrypt the password string. Use the encrypted password for the
-Djpeserver.httptunnel.ssl.storepass command previously mentioned.

Consider the following example:

||

Command to run Sample output

|
|
|
|

ktgen
mynewstorepw

Generating 1,024 bit RSA key pair and self-signed certificate

(MD5WithRSA)for: CN=PEServer, OU=P8BPM, O=IBM, L=Costa Mesa,
ST=CA, C=us[Storing C:\Program Files\IBM\FileNet\ProcessEngine\
data\p8pekeys]

|
|
|

genseed.bat
mynewstorepw

mynewstorepw=encrypted_password

|
|
|

Add the encrypted_password to the startpesvr script, as shown in the following

example:

-Djpeserver.httptunnel.ssl.storepass=@encrypted_password

-Djpeserver.httptunnel.ssl.storepass=@encrypted_password

Resetting keys

If the Master Key is lost or corrupted, the credentials stored in the GCD must be
reset by the GCD administrator (gcd_admin).
Resetting the keys must be done by someone who knows the existing passwords
(for Verity, Liquent, Directory service user, fixed storage devices, and so on) or who
has the ability to reset those passwords. When the Master Key is lost, corrupted or
changed, follow these basic steps:
1. Rerun Configuration Manager's Configure Bootstrap Properties task (or the
bootstrap utility, BCU) to re-encrypt the credentials of the Bootstrap user (also
called the Content Engine System User, or ce_bootstrap_admin) that are stored in
the CEMPBoot.properties file.
2. Preferably using TLS or SSL, redeploy this EAR file to each Content Engine
server in the FileNet P8 domain.
3. Log in to Enterprise Manager as a GCD administrator (gcd_admin). Reset the
passwords for each of the following items:
v Each Directory Service Configuration.
v Each IsolatedRegion.
v Each CFS-IS or CFS-CS fixed device.
v Each Verity domain configuration.

226

Security Extract

v For each PublishStyleTemplate defined on the system for PDF documents,

that makes use of PDF passwords, have the person who created the template
go into the Publishing Style Template Manager application and re-enter or
reset the PDF passwords.

Content encryption
Content Engine does not provide features for encrypting the data contained in
content files being transmitted between Content Engine and the fixed content
storage device or file storage area. You should therefore consider whether and how
to provide this type of security.
Content Engine also does not provide for encryption of the content data at rest. See
the IBM FileNet P8 Hardware and Software Requirements for information about
support of third-party encryption solutions for data at rest
Also see File storage area and content cache area access rights.

TLS, SSL, and data privacy

Both HTTP and LDAP can use Transport Layer Security (TLS) or Secure Sockets
Layer (SSL) to secure authentication credentials and data sent over a network.
v Both TLS and SSL are supported. Any time an application server has been
configured to support TLS, it has also thereby been enabled for SSL 3.0. Whether
it actually uses SSL or TLS depends on the runtime negotiation between client
and server.
v TLS or SSL can be used to verify the identity of one or both of the parties
engaged in a network connection.
v TLS or SSL can also provide data integrity (proof that the data has not been
modified since the sender sent it).
v TLS can provide data confidentiality (obscuring the data from third parties
observing the dialog over the connection).
Related information:
About Application Engine security
Bootstrap site preferences
Setting up Application Engine SSL security
Setting up Content Engine and client transport SSL security

Security tools and procedures

227

228

Security Extract

How to...
tbd
In addition to the security procedures in this section, the following security-related
procedures are covered elsewhere in Help:
v Creating security policies.
v Using Enterprise Manager's security editor.
v Specifying object store administrators and users and administrators in the Object
Store wizard.
Add users and groups to a class
Add users and groups to a single object on page 230
Add or remove a GCD administrator on page 231
Add or remove an object store administrator on page 231
Allow or disallow security inheritance on page 232
Allow users to add items to a folder on page 232
Change Bootstrap admin password on page 232
Configure a folder's security inheritance on page 235
Configure security inheritance on page 236
Configure Content Engine to use email or UPN for login on page 239
Configure inheritable depth (Apply to) on page 243
Configure multiple authenticating attributes on page 243
Configure multiple realms on page 245
Deny an object store administrator access to a document on page 248
Modify an object's security on page 250
Restrict access to the root folder on page 250
Set security on workflow queues and rosters on page 250
Take or change ownership on page 251
Update object store with new users and groups on page 251
Related information:
Create a security policy
Security editor
Create an object store wizard

Add users and groups to a class

This procedure describes how to add additional accounts, users or groups, the
default security of a class.
Classes that are instantiable, like the document class, have two security tabs:
v The Default Instance Security tab contains the ACL that will be applied to new
instances of the class. (For example, a document is an instance of a particular
document class.) New users and groups who will be users of the objects based
on a class should be added to the Default Instance Security tab of the class: they
will need the Create Instance permission that is contained on the Security tab.
Copyright IBM Corp. 2006, 2011

229

v The Security tab governs the security of the class itself (who can subclass it,
delete it, change its properties, etc.). New users and groups who will be
administrators of the class should be added to the Security tab of the class.
To add new users/groups to the Default Instance Security ACL of a class:
1. Log on to Enterprise Manager as an object store administrator
(object_store_admin).
2. Use Enterprise Manager to open the property sheet of the class and go to the
Default Instance Security tab. Use the Add button and use the Select Users or
Groups dialog box. Click OK to close the dialog box.
3. Use the security editor to examine and if necessary change the default
permissions of the new grantees.
Important: The default security level of a new user or group is View
Properties. Full administrative control is conferred by having the Full Control
level. Make sure you should grant the new user or group the permissions they
will need.
4. Click OK when you are done. New instances of the class will include the
newly added grantee with the default access permissions you selected.
Remember: Modifying a class does not affect existing objects that are instances of
that class. For example, adding users to the Default Instance Security ACL of a
document class does not add those new users to existing documents based on that
class.
Related information:
Select users and groups
Security tab

Add users and groups to a single object

Securable objects like documents and folders get their initial security from the
Default Instance Security ACL of their class and possibly also from the class'
default security policy, if there is one. Authorized users can add to or change this
initial security. Directly changing a single object's security means that only that one
object will receive the changes. If the object is a document, these direct changes to
a single version will continue to appear on later versions of the same document.
To add new users and groups to a single object:
1. Ensure that the user or group already exists in the authentication Realm that
was configured while installing and configuring the FileNet P8 domain.
2. Log on to Enterprise Manager as an object store administrator
(object_store_admin).
3. Use Enterprise Manager to open the property sheet of the object and go to the
Security tab. Use the Add button and add the users or groups in the Select
Users or Groups dialog box. Click OK to close the dialog box.
4. Use the security editor to examine and if necessary change the default
permissions of the new grantees.
5. Click OK when you are done.

230

Security Extract

Related information:
Select users and groups
Security tab

Add or remove a GCD administrator

As part of installing and configuring Content Engine, at least one user name is
defined as the GCD administrator. You can view and edit the list of users and
groups at any time to add or remove GCD administrators using the procedure
below.
For more information, see the entry for GCD administrator (gcd_admin).
To
1.
2.
3.

add or remove GCD administrators:

Log in to Enterprise Manager as a GCD administrator (gcd_admin).
Right-click the FileNet P8 domain node and select Properties.
To add GCD administrators, select the Security tab and click Add. Use the
Select Users and Groups dialog box to find and add users and groups. Click
OK to return to the Security tab. Apply the Full Control permission level to all
the accounts you just added. Click OK when you are done
4. To remove GCD administrators, select the Security tab. Select the user or group
you want to remove and click Remove.
Since there must always be at least one GCD administrator, Enterprise Manager
will prevent you from removing all entries.
5. Click OK when you are done.

Add or remove an object store administrator

Each object store has its own list of object store administrators (object_store_admin),
initially created while running the object store wizard. You can view and edit this
list at any time later on.
For more information, see the entries for object store administrator and GCD
administrator.
To add or remove object store administrators:
1. Log in to Enterprise Manager as a GCD administrator (gcd_admin).
2. Right-click the object store whose list you want to edit and select Properties.
3. To add object store administrators, select the Security tab and click Add. Use
the Select Users and Groups dialog box to find and add users and groups.
Click OK to return to the Security tab. (To remove object store administrators,
select the Security tab. Select the user or group you want to remove and click
Remove. Click OK when you are done.)
4. Grant the Full Control permission level to all the accounts you just added.
Click OK when you are done. These new users and groups will have the rights
of an object store administrator for all new objects created in the object store
going forward.
5. Run the Security Script Wizard to provide these new object store administrators
access to existing objects. See Update object store with new users and groups.

How to...

231

Allow or disallow security inheritance

You can enable or disable inheritance from a parent folder to a child folder.
To allow or disallow inheritable parent permissions to a child folder, using
Enterprise Manager:
1. Log in to Enterprise Manager as an object store administrator
(object_store_admin).
2. Right-click the folder, select Properties, and select the General tab.
3. Select (to allow) or clear (to disallow) the check box labeled Inherit parent
permissions.
v Changing to selected: allows the inherited permissions from the parent folder
to propagate to this folder.
v Changing to clear: prevents the object from inheriting permissions from the
parent in the future.
Only those permissions in the parent folder that are inheritable will actually be
inherited by the child folder. See Understanding inheritance for information about
inheritance and inheritable depth.
For the Root folder, which by definition has no parent folder, selecting or clearing
the check box has no effect.
See Configure a document's security parent folder for configuring security
inheritance for documents and custom objects.

Allow users to add items to a folder

You can configure the security of a folder to allow users to add new folders,
documents, and other containable objects.
Use this procedure to check whether users or groups have the necessary access
rights to add items to a folder, and to grant them those rights if they do not.
1. Log in to Enterprise Manager as an object store administrator
(object_store_admin).
2. Display the folder's security by right-clicking the folder and selecting
Properties, and then clicking the Security tab.
3. Add new users or groups, or select existing users or groups. Grant them the
Modify Properties security level. This permits them to add subfolders to a
folder.
4. Refresh the folder.
5. Display the folder's security if it is not already displayed.
6. Select the same the users or groups and grant them the Add to Folder security
level. This permits them to add documents to the folder.
7. Refresh the folder.

Change Bootstrap admin password

This procedure describes how to change the password for the Content Engine
system user (also known as the bootstrap administrator, or ce_bootstrap_admin). The
credentials for this account are entered during Content Engine configuration.
Configuration Manager places this user name and its password into the Content

232

Security Extract

Engine bootstrap file. When Content Engine starts up, it uses the account and
password to authenticate against the user registry defined in the application server.
Here are the characteristics of the ce_bootstrap_admin account:
v It must reside in Content Engine's configured LDAP directory server.
v Configuration Manager's Configure Bootstrap Properties task places it in the
Content Engine's bootstrap file. In this location ce_bootstrap_admin is called the
Content Engine system user.
v During the initial P8 Domain creation and configuration, it is automatically
added to the Enterprise Manager's domain security property sheet as the default
GCD admin user (gcd_admin). After initial P8 domain configuration, it is a best
practice to replace it with a different gcd_admin account.
v Many installations will also enter this account into Configuration Manager's
Configure LDAP task as the Directory Service User account (sometimes known
as the bind user, or ce_service_user), the account that Content Engine's application
server uses to bind to the directory server. The Configure LDAP task places the
account into the application server's authentication configuration location.
v This account is sometimes also used as the LDAP bind user during P8 Domain
creation, by entering the account name and password in the Directory Service
User field in Enterprise Manager's Directory Configuration property sheet.
Changing ce_bootstrap_admin's password in the directory server means that you
must at the same time change it in these locations. If you do not, the bootstrap file
will not be able to authenticate to the LDAP and Content Engine will not be able
to start. You can also lock yourself out from Enterprise Manager. Follow this
procedure carefully to avoid this scenario.
This procedure requires access to the Content Engine location, to the application
server console, and to the directory server. Because of the relative complexity of
this procedure, unless there is an overriding reason to change the password of this
important account, you can consider exempting the Content Engine system user
account from your password change policy if this still meets your security
requirements.
Some steps below will be different for installations using JBoss, as JBoss does not
have an administrative console or the need to log in as an administrator.
To change the Content Engine system user password:
1. Backup the Engine-##.ear file, where ws denotes WebSphere, wl denote
WebLogic, and jb denotes JBoss. You can then revert to last good known EAR
file in case changing the password fails.
2. On the server containing Content Engine, start the Configuration Manager.
a. Load the Configuration Manager profile that describes your installation.
b. Click Configuration Bootstrap Properties. Do not change anything yet.
The Bootstrap user password is the field you will change later in this
procedure.
c. Leave this window open while doing the following steps.
3. Log in to Enterprise Manager as GCD administrator gcd_admin.
a. In Enterprise Manager, right-click the Root Folder, and then click
Properties
b. Click the Directory Configuration tab.

How to...

233

c. Select the row that represents the configuration parameters pointing to the
LDAP location that the Content Engine system user belongs to, and click
Edit.
d. When the Modify Directory Configuration dialog box opens, view the
value for the Directory Service User account.
v If this account is the same as the Content Engine system user
(ce_bootstrap_admin) identified in step 2, then continue with the next
step.
v If it is different, then continue but skip the steps that deal with changing
the Directory Service User (that is, Steps 5, 7, 8.
e. Do not change anything yet. Leave the dialog box open while doing the
remaining steps.
4. (WebLogic and WebSphere) Log in to your application server console and
search all the user registries for the Content Engine system user. Verify that
the Content Engine system user is defined in the directory server where the
password change will take place. This is to ensure that the application server
is indeed using the directory server for authentication, and not some other
custom authentication provider (WebLogic) or user registry repository
(WebSphere).
5. Locate the value for the Directory Service User account. This should be the
same value as described in step 3d.
a. Navigate to the authentication provider panel containing the ID and
password for the Directory Service User account.
v WebLogic: this will be the value of the Principal field in the
Authentication Provider for the WebLogic domain containing Content
Engine.
v WebSphere: this will be the bind user account in the Profile containing
Content Engine.
v JBoss: the Directory Service User account is contained in the
login-config.xml file.
b. Do not change anything yet. Leave the console open while doing the
remaining steps.
6. Log in to your directory server.
a. Navigate to the location containing the account for the Content Engine
system user.
b. Change its password.
c. Save and apply.
7. Return to your application server console.
a. Change the password of the Directory Service user account (also known as
the bind account) to the new password .
b. Save and apply.
c. Do not restart the application server until instructed to do so below.
8. Return to Enterprise Manager dialog box.
a. Change the Directory Service User's password to the new password.
b. Click Apply and OK to close the dialog box.
9. Return to the window containing Configuration Manager.
a. In the Configure Bootstrap Properties task, set the Bootstrap Operation
property to Modify Existing.
b. Confirm that the Bootstrapped EAR file property contains the path to the
bootstrap file you need to edit.

234

Security Extract

c. Change the Bootstrap user password. Use Configuration Manager's

features to save and run the task.
d. Run Configuration Manager's Deploy Application.
10. Restart the application server.
11. Verify the change by logging on to Enterprise Manager as a GCD
administrator (gcd_admin) and performing a user and group look up. See
Modify an object's security for one way to do this.

Configure a folder's security inheritance

Use this procedure to configure the security inheritance of a folder.
This topic explains how to configure a folder to be a security folder to documents
or custom objects. For information on how to configure those objects to inherit
permissions from the folder, see Configure security inheritance.
Run this procedure as part of your initial security configuration, after you have
added document classes and configured their Default Security Instance tabs. It is
best to establish security inheritance before putting an object store into production.
For more information about inherited security see:
v Understanding security inheritance
v About access rights
To use Enterprise Manager to configure a security folder:
1. Log in to Enterprise Manager as object store administrator (object_store_admin).
2. Open the Object Store node and select the Root Folder.
3. Right-click the folder whose security will be inherited and select Properties.
Click the Security tab. The users or groups whose security you want to be
inherited appear on the list of names.
a. Make sure the ACEs whose security will be inherited have an Apply to
setting of either This object and immediate children or This object and all
children.
b. If the users or groups are not already on the folder's list of names, click
Add to open the Select Users and Groups dialog box. Use the Find
capability to find the users or groups you want and then add them to the
folder's security list of names.
4. Select the user or group whose permissions you want to be inherited and make
one or more of the following changes:
a. Select Allow or Deny.
b. In Apply to, select This object and immediate children (for only one level
of inheritance) or This object and all children (for infinite levels of
inheritance).
c. Choose the security level or individual rights that will be inherited. In most
cases you will choose from the rights marked (Inherit only).
5. Click Apply or OK.
6. If necessary, configure the target documents and custom objects to inherit the
Inherit only permissions from this folder. See Configure security inheritance.

How to...

235

Configure security inheritance

FileNet P8 gives you tools to configure security inheritance, which is the passing of
permissions from a parent object to a child object.
Run these procedures as part of your initial security configuration, after you have
created document classes and configured their default security instance tabs. It is
best to establish security inheritance before putting an object store into production.
For more information about inherited security see:
v Understanding security inheritance
v About access rights
Tip: You can use the procedures for custom objects also. Just substitute "custom
object" wherever you see "document".
Designating a folder as a security parent by using Security Parent
Designating a folder as a security parent by using Security Folder on page
237
Configuring security inheritance by using a custom object-valued property on
page 238

Designating a folder as a security parent by using Security

Parent
You can configure a document or custom object to inherit permissions from a
folder. The folder can contain the document or custom object, but this is not
required. (Earlier versions of Content Engine did require that the security parent
folder contain the document or custom object, but this requirement has been
removed with the introduction of the SecurityFolder property.)
Run this procedure as part of your initial security configuration, after you have
created document classes and configured their default security instance tabs. It is
best to establish security inheritance before putting an object store into production.
To use Enterprise Manager to designate a folder as a security parent:
1. Log in to Enterprise Manager as object store administrator.
2. Open the Object Store node, select the Root Folder, and navigate to the folder
containing the document whose security inheritance you are configuring.
3. Click the folder's Security tab. Make sure the folder has ACEs whose Apply to
setting is either This object and immediate children or This object and all
children. See Configure a folder's security inheritance for reference.
4. Click OK to close the folder's property sheet.
5. Right-click the document, select Properties, and then select the property sheet's
General tab.
6. Select the Inherit Security from folder check box. Then select a folder from the
list.
(All folders containing the document will appear in the list. If the folder you
want is not in the list you will need to stop this procedure, file the document in
the folder, and then start again.)
Important: After the upgrade to Content Engine 4.0.1 and later versions, this
check box appears exactly as it did in earlier releases. However, selecting it
actually sets the new SecurityFolder property and not the SecurityParent

236

Security Extract

property as it did formerly and which is being deprecated. However, because

the SecurityParent feature is still supported, the dropdown box will display
only those folders that contain the document. This Enterprise Manager behavior
therefore mimics the SecurityParent behavior which depends on containment,
even though it is in fact using the SecurityFolder property which does not
require containment of the document by the folder. Custom applications that
have been coded using SecurityParent will continue to function without change.
7. Click Apply or OK.
8. Click the document's Security tab and confirm that it has inherited ACEs from
the security folder. The inherited ACEs will show a Source type of Inherited. If
the required rights do not appear, make sure that they are configured to be
inheritable on the folder. See Configure a folder's security inheritance.

Designating a folder as a security parent by using Security

Folder
You can configure a document or custom object to inherit permissions from a
folder using the Security Folder property, a standard property of every document
and custom object class.
Run this procedure as part of your initial security configuration, after you have
created document classes or custom object classes and you have configured their
default security instance tabs. It is best to establish security inheritance before
putting an object store into production.
To designate a folder as a security parent by using Security Folder:
1. Log in to Enterprise Manager as object store administrator (object_store_admin).
2. Open the Object Store node, select the Root Folder, and navigate to the folder
that will serve as the Security Folder.
3. Right-click the folder and select Properties. Click the folder's Security tab.
Make sure the folder has ACEs whose Apply to setting is either This object
and immediate children or This object and all children. See Configure a
folder's security inheritance for reference. Click Cancel or OK to close the
folder's property sheet. You should see the folder's icon listed in Enterprise
Manager's tree view.
4. Right-click the folder and select Copy Object Reference.
5. Now navigate to the folder containing the document whose security
inheritance you are configuring.
6. Right-click the document and select Properties. Select the property sheet's
Properties tab.
7. Scroll down the list of properties and find Security Folder. Its Property Value
cell will display <Value Not Set> if there is no value yet for this property.
8. Click the Property Value column. The Set Object Value dialog box will
appear. Click OK to set the value. The Select Object from Paste Buffer dialog
box will appear and will list the object reference you copied earlier under the
Object Name column.
9. Select the appropriate Object Name and click OK. You will see the name of
the folder appear as the Property Value for the Security Folder property.
10. Click Apply to apply the changes you just made and keep the document's
property sheet open.
11. Click the Security tab, and confirm that the Security Folder's inheritable ACEs
appear, with Source type of Inherited.

How to...

237

Configuring security inheritance by using a custom

object-valued property
Another way to configure inheritance is to use a custom object-valued property.
To designate a folder as a security parent by using a custom object-valued
property:
1. Log in to Enterprise Manager as object store administrator.
2. Copy the object reference of the object whose security will be inherited. (This
object will become a security parent as a result of this procedure.) This object
must have at least one inheritable ACE (one whose Apply to setting is either
This object and immediate children or This object and all children).
3. Start the Create a Property Template Wizard to create the property that will
establish the connection between the two objects. .
a. Give the new template a name.
b. Select Object for the data type.
c. On the Single or Multi-Value? step of the wizard, select Single. Click the
More button.
d. On the More tab of the dialog box that displays, for Security Proxy Type
select Inherited. (This value will appear as the integer 2 when viewed in
the document's property grid.) Click OK.
e. Click Next and Finish to complete the wizard.
4. Assign the new property template to a new or existing class. The following
procedure assumes the class already exists..
a. Right-click the class and select Add Properties to Class. This opens the Add
Properties to a Class Wizard. Click Next.
b. In the Select Properties panel, select the Show Object Type check box and
in the Available column select the property you just created above. Click
Add>> to add the property to the Selected column. Click Next.
c. In the Select Property Attributes panel, select the property you just added to
the class and then click More. The property template's property sheet opens.
d. In the property template's property sheet, click the More tab.
v For Required Class, use the list to select the class of the object whose
object reference you copied above. For example, if that proxying object is
a document, you would select its exact class or subclass.
e. Click Next and then click Finish to finish the Wizard.
5. (Optional) Assign a default value to the object-valued property. This step is
optional but can be used, if appropriate, to automate the process of establishing
the connection to the object providing security inheritance. If you do not set a
default value, Enterprise Manager will request an object reference each time
you create a new object that references that object-valued property for its
inherited security. (This step assumes that there is a single
inheritance-providing object for this particular custom property.)
a. Right-click the class you used in the step above and select Properties. Select
the Properties tab.
b. Scroll down and find the Property Definitions row. (This is not the same as
selecting the Property Definitions tab of the property sheet.)
c. Click the down arrow in the Property Value column. The list of all custom
properties drops down.
d. Select the object-valued property you just created. Its property sheet will
display. Click the Properties tab of that property sheet.

238

Security Extract

e. Scroll down and find the Property Default Object row and click its
Property Value cell. If you have not yet set the value, you will get a dialog
box asking you to select OK to set the value. Click OK and the Select
Object from Paste Buffer will appear.
f. Select the object that will be supplying the inherited security and click OK.
Click Close and OK to close the class property sheet.
If the object you need is not in the list, click Cancel and start this procedure
again, being careful to follow the step describing how to copy the object
reference of the object whose security will be inherited.
If the Propagate Metadata Changes dialog box opens, you must decide,
based on the requirements of your security design, whether the new
property you just added to a class should be propagated down to all
subclasses. We will not propagate for this procedure; therefore in the
Updated Property Definitions box do not select the property definition we
just created. Click OK to return to Enterprise Manager.
6. Create a new document using the class we have been using in this procedure.
(If you have not assigned a default value as optionally described above, you
will be prompted for an object reference. Set the reference using the object
reference you copied.)
7. Examine the new document's Security tab and confirm that it has inherited
ACEs from the security parent object. The inherited ACEs will show a Source
type of Inherited. In order to change the access rights of this inherited ACE,
you would change it on the source document; the changes will automatically be
updated on the target document.
8. Repeat this procedure as many times as required by your security design.
Related information:
Copy object reference
Create a property template
Assign properties to a class

Configure Content Engine to use email or UPN for login

Use this procedure to assign the directory server's email attribute or, for Active
Directory, the userPrincipalName (UPN) to be the user short name used for login.
Restriction: This topic applies only to new installations of Content Engine. Do not
perform this procedure on existing production installations, because of problems
that might arise when changing from one short name attribute to another. For
example, this procedure does not change the values of short names that are already
persisted in Content Engine, Process Engine, or other applications, including but
not limited to Process Engine workflows.
Important: Do not assign email as the short name for groups. The best practice
for group short name is to use sAMAccountName.
Attention: Do not restart the application server until the following procedure
tells you to.
The following steps are not a complete list of things to do to configure Content
Engine using Configuration Manager. For the complete procedure, refer to

How to...

239

Installing or upgrading IBM FileNet P8 Platform > Installing a distributed IBM

FileNet P8 Platform system > Installing and configuring Content Engine >
Configuring Content Engine.
To configure Content Engine to use email or UPN for login:
1. Open Configuration Manager's Configure LDAP task.
2. To use email for the short name:
a. Depending on your application server type, set the following properties to
configure the short name for email:
Table of attributes and values to configure for email for the listed application server types.
Application Server type
WebSphere Stand-alone LDAP registry

Configuration Manager attributes and values to set for

email (all directory server types)
Active Directory
User Filter:
(&(mail=%v)(objectClass=user))
User ID map:
user:mail
All other directory servers
User Filter:
(&(mail=%v)(objectClass=person))
User ID map:
person:mail

WebSphere Federated Repositories

WebLogic

Login Properties:
uid

Active Directory
User from name filter:
(&(mail=%u)(objectclass=user))
User name attribute:
mail
All other directory servers
User from name filter:
(&(mail=%u)(objectclass=person))
User name attribute:
mail

JBoss
To configure multiple JBoss Authentication Providers,
refer to Configure multiple realms to modify each
Authentication Provider entry.

240

Security Extract

All directory servers

Base Filter:
(mail={0})

b. Use Configuration Manager to Save and Run the Configure LDAP task.
c. (Websphere Federated Repositories only) Search the WebSphere application
server profile for wimconfig.xml. Edit wimconfig.xml in the following way:
1) Search for the propertyName="uid" entry (samAccountName in the
example is for Active Directory; other directory servers have values
such as cn or uid). (If the search does not find this entry, you might
have to create the following):
<config:attributes name="samAccountName" propertyName="uid">
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

2) Modify the propertyName="uid" entry for mail attribute:

<config:attributes name="mail" propertyName="uid">
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

3) Save wimconfig.xml.
3. (Active Directory only) To use UPN for the short name:
a. Depending on your application server type, set the following properties to
configure the short name for UPN:
Table of attributes and values to set for UPN for the listed Application Server types.
Application Server type

Configuration Manager attributes and values to set for

UPN (Active Directory only)

WebSphere Stand-alone LDAP registry

User Filter:
(&(userPrincipalName=%v)(objectClass=user))
User ID map:
user:userPrincipalName

WebSphere Federated Repositories

Login Properties:
uid

WebLogic

User from name filter:

(&(userPrincipalName=%u)(objectClass=user))
User name attribute:
userPrincipalName

JBoss

Base Filter:

To configure multiple JBoss Authentication Providers,

refer to Configure multiple realms to modify each
Authentication Provider entry.

(userPrincipalName={0})

b. Use Configuration Manager to Save and Run the Configure LDAP task.
c. (Websphere Federated Repositories only) Search the WebSphere application
server profile for wimconfig.xml. Edit wimconfig.xml in the following way:
1) Search for the propertyName="uid" entry (If the search does not find
this entry, you might have to create the following):
<config:attributes name="samAccountName" propertyName="uid">
<config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

2) Modify the propertyName="uid" entry for userPrincipalName attribute:

<config:attributes name="userPrincipalName" propertyName="uid">
<config:entityTypes>PersonAccount </config:entityTypes>
</config:attributes>

3) Save wimconfig.xml.
How to...

241

4. Open Configuration Manager's Configure Bootstrap Properties task. Set

Bootstrap Operation to Configure New.
5. Confirm that the Bootstrapped EAR file property contains the path to the
bootstrap file you need to edit.
6. Set the Bootstrap user name. The user name should be in this form:
[email protected].
Use Configuration Manager to Save the task.
Run Configuration Manager's Deploy Application task.
Manually restart the application server.
Log in to Enterprise Manager using the Bootstrap user name and password.
Enterprise Manager prompts for a P8 domain name and then starts the
Directory Configuration Wizard. If the P8 domain has already been created
and the Directory Configuration Wizard does not start automatically,
right-click the domain root node and select Properties. Select the Directory
Config tab, then click Add to add a new configuration or Modify to edit an
existing configuration.
11. Depending on which attribute you want to set and your application server
type, set the properties described in the following table.

7.
8.
9.
10.

Table of properties to set when running the Directory Configuration wizard for either email or UPN.
If running the Directory Configuration wizard for this
attribute ...
email

... set these properties for the short name

Active Directory
User Short Name Attribute:
mail
User Search Filter:
(&(mail={0})(objectClass=user))
All other directory servers
User Short Name Attribute:
mail
User Search Filter:
(&(mail={0})(objectClass=person))

UPN (Active Directory only)

In the third page of the wizard, set the property Allow

UPN Short Names to True.
If you have more than one Active Directory configuration,
you must set Allow UPN Short Names to True for all of
them. (Allow UPN Short Names is Enterprise Manager's
display name for the AllowEmailOrUPNShortNames
property.)
User Short Name Attribute:
userPrincipalName
User Search Filter:
(&(userPrincipalName={0})(objectClass=user))

12. Repeat #11 for any additional directory configurations that are required by
your installation.

242

Security Extract

13. Save your new settings.

Configure inheritable depth (Apply to)

Use this procedure to configure how far an object's inheritable permissions should
be inherited.
For each user and group listed in a security parent's ACL, the "Apply to" setting
determines the inheritable depth of the ACE.
1. Log on to Enterprise Manager as object store adminisrator (object_store_admin).
2. Display an object's Security page.
3. Select the user or group whose inheritable depth you wish to edit.
4. Make a selection from the Apply to pull-down menu and click Apply or OK
when you are done.

Configure multiple authenticating attributes

Use this procedure to configure your application server for more than one login
attribute.
The following procedure provides a general list of steps to follow for configuring
your application server so that users can log in using both shortname and
distinguished name. You must first configure the Content Engine application
server's authentication parameters, and then configure the Content Engine
authorization parameters. Then, in some cases, you must also configure the
Application Engine authentication parameters.
You can carry out this procedure before or after installing Content Engine and
Application Engine. If you have already installed and configured Content Engine,
then Configuration Manager has already configured your application server's
authentication parameters for one authenticating attribute, for example, using
shortname (cn).
The following procedures use the terms shortname and longname which typically
map to the following specific LDAP attributes:
Table of authenticating attributes (shortname and longname) which map to an LDAP attribute.
Directory Server

Typical shortname
equivalent

Typical longname
equivalent

Active Directory

sAMAccountName

userPrincipalName or DN

Active Directory Lightweight

Directory Server (AD LDS)

sAMAccountName

userPrincipalName or DN

Sun Java System Directory Server

uid

DN

Novell eDirectory

cn

DN

IBM Tivoli Directory Server

cn

DN

Oracle Internet Directory

cn

DN

To configure for multiple authenticating attributes (shortname and distinguished

name):
1. Log in to the Content Engine application server as an administrator.
2. If WebSphere is your application server, then in the profile containing Content
Engine, do the following:
How to...

243

a. Set the user filter to:

(&(|(shortname=%v)(longname=%v)) (objectcategory=user))

b. Set the User ID Map to:

user:shortname;user:longname

3. If WebLogic is your application server, then in profile containing Content

Engine, create two authentication providers, one using shortname and another
using longname.
4. If JBoss is your application server, then in profile containing Content Engine, do
the following:
a. Edit login-config.xml to allow both types of login. The following example
provides a general idea. Notice, in the two versions of the <authentication>
section, the different entries for baseFilter and roleFilter:
- <application-policy name="ibm">
- <authentication>
- <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="sufficient">
<module-option name="java.naming.provider.url">
ldap://yourURL:389</module-option>
<module-option name="java.naming.security.authentication">simple
</module-option>
<module-option name="allowEmptyPasswords">false</module-option>
<module-option name="bindDN">cn=test1,CN=Users,
DC=yourDC</module-option>
<module-option name="bindCredential">test1</module-option>
<module-option name="baseCtxDN">CN=Users,
DC=yourDC</module-option>
<module-option name="baseFilter">(longname={0})</module-option>
<module-option name="rolesCtxDN">CN=Users,
DC=yourDC</module-option>
<module-option name="roleFilter">(longname={0})</module-option>
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleRecursion">-1</module-option>
</login-module>
- <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="sufficient">
<module-option name="java.naming.provider.url">
ldap://yourURL:389</module-option>
<module-option name="java.naming.security.authentication">simple
</module-option>
<module-option name="allowEmptyPasswords">false</module-option>
<module-option name="bindDN">cn=test1,CN=Users,
DC=yourDC</module-option>
<module-option name="bindCredential">test1</module-option>
<module-option name="baseCtxDN">CN=Users,DC=yourDC</module-option>
<module-option name="baseFilter">(shortname={0})</module-option>
<module-option name="rolesCtxDN">CN=Users,DC=yourDC</module-option>
<module-option name="roleFilter">(shortname={0})</module-option>
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleRecursion">-1</module-option>
</login-module>
</authentication>
</application-policy>

When using JBoss 4.0.5, if CN=Users is missing from the rolesCtxDN tag, you
will not be able to log on to Enterprise Manager, which will throw an
incorrect user name/password exception.
5. Restart the application server.
6. Log in to Enterprise Manager as a GCD administrator (gcd_admin).
a. Right-click the Enterprise Manager root folder, and then select Properties.

244

Security Extract

b. Select the Directory Configuration tab.

c. Select the directory configuration entry and click Modify if you changed an
existing authentication configuration.
d. Click Add if you added a new authentication configuration and complete
the Create a Directory Configuration Wizard using the same values you just
entered into the application server's authentication configuration.
e. Make the same changes you made in your application server.
7. If your authentication design requires that the Application Engine application
server's authentication parameters exactly match those of the Content Engine
application server, log in to the Application Engine application server as an
administrator.
a. Make the same authentication changes on the Application Engine
application server that you made for the Content Engine server. If your
Application Engine software is installed on a different type of application
server than the Content Engine application server (only supported when
using Web Services transport) between Application Engine and Content
Engine, achieving an exact match of multiple login configuration might
require experimentation and careful testing.

Configure multiple realms

You can create multiple authentication realms on your application server. For each
authentication realm that you create, you must also create a corresponding
directory configuration in Content Engine so that the users and groups in the
authentication realm can be authorized.
Configure multiple realms (WebSphere and WebLogic)
Configure multiple realms (JBoss 4.x) on page 246
Configure multiple realms (JBoss 5.x) on page 246

Configure multiple realms (WebSphere and WebLogic)

You can create multiple authentication realms on your application server. For each
authentication realm that you create, you must also create a corresponding
directory configuration in Content Engine so that the users and groups in the
authentication realm can be authorized.
To configure additional realms:
1. The topic "Configuring the directory service provider (LDAP) settings" in IBM
FileNet P8 Platform Installation and Upgrade Guide describes how to use
Configuration Manager to configure an initial authentication realm. Repeat that
procedure for each additional authentication realm you need to create.
2. Log in to Enterprise Manager as GCD administrator (gcd_admin). Run the
Create Directory Configuration wizard. Enter the same directory service
configuration property values that you entered into Configuration Manager in
step 1.
3. Repeat steps 1 and 2 for each additional directory server naming context that
you want to configure as FileNet P8 realms. See "Adding an additional task to
your profile" in IBM FileNet P8 Platform Installation and Upgrade Guide for
information about how to repeat step 1.
4. In Enterprise Manager, logged in as an object store administrator
(object_store_admin) add the new users and groups to the object stores,
document classes, and any other required objects that they must be able to
access.
How to...

245

5. Test the new configuration by logging in to a client application with an account

residing in the newly configured realm.

Configure multiple realms (JBoss 4.x)

JBoss supports multiple authentication realms by allowing multiple authentication
login-module sections in its configuration file login-config.xml. This procedure
describes how to set up the configuration file for JBoss 4.x.
The easiest way to configure multiple realms is to use Configuration Manager to
create the initial authentication section in the JBoss file login-config.xml in the
server's \conf directory (for example: ..\server\myserver\conf\login-config.xml).
After initial configuration, you must directly edit the XML file to add additional
authentication login-module sections that point to additional naming contexts on
your directory server. The procedures are slightly different between JBoss 4.x and
JBoss 5.x.
To configure additional realms:
1. Open login-config.xml in an editor. Find the <application-policy name =
"FileNet"> section. It will look similar to the following sample:
<application-policy name = "FileNet">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="sufficient">
<module-option name="java.naming.provider.url">
ldap://yourserver:389</module-option>
<module-option name="java.naming.security.authentication">simple
</module-option>
...
</login-module>
</authentication>
</application-policy>

2. Make a copy of the <login-module

code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
... </login-module> section and paste it right after the first. Change the
required FileNet P8 values (e.g. java.naming.provider.url) in the new section so
that it points to the new realm. See the Directory service providers section for
information about each application server's attributes and values.
3. Restart the application server.
4. Log in to Enterprise Manager as GCD administrator (gcd_admin). Run the
Create Directory Configuration wizard. Enter the same directory service
configuration property values that you just added to the authentication
provider.
5. Repeat steps 1 and 2 for each additional directory server naming context that
you want to configure as FileNet P8 realms.
6. Test the new configuration by logging in to a client application with an account
residing in the newly configured realm.
7. Grant the new users and groups access to objects by logging on to Enterprise
Manager as object store administrator and adding the new accounts to
document classes.

Configure multiple realms (JBoss 5.x)

JBoss supports multiple authentication realms by allowing multiple authentication
login-module sections in its configuration file login-config.xml. This procedure
describes how to set up the configuration file for JBoss 5.x.

246

Security Extract

The easiest way to configure multiple realms is to use Configuration Manager to

create the initial authentication section in the JBoss file login-config.xml in the
server's \conf directory (for example: ..\server\myserver\conf\login-config.xml).
After initial configuration, you must directly edit the XML file to add additional
authentication login-module sections that point to additional naming contexts on
your directory server. The procedures are slightly different between JBoss 4.x and
JBoss 5.x.
To configure additional realms (WebSphere and WebLogic):
1. Open login-config.xml in an editor. Find the <application-policy name =
"FileNet"> section. It will look similar to the following sample:
<application-policy name = "FileNet">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="sufficient">
<module-option name="java.naming.provider.url">
ldap://yourserver:389</module-option>
<module-option name="java.naming.security.authentication">simple
</module-option>
...
</login-module>
</authentication>
</application-policy>

2. Make a copy of the <login-module

code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
... </login-module> section and paste it right after the first. Change the
required FileNet P8 values (e.g. java.naming.provider.url) in the new section so
that it points to the new realm. See the Directory service providers section for
information about each application server's attributes and values.
3. Find the <application-policy name = "CLIENT_LOGIN_MODULE"> section. Make a
copy of the <login-module
code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
... </login-module> section and paste it right after the first. Change the
required FileNet P8 values (e.g. java.naming.provider.url) in the new section so
that it points to the new realm.
4. Find the <application-policy name = "BYPASSED-SECURITY"> section. Make a
copy of the <login-module
code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
... </login-module> section and paste it right after the first. Change the
required FileNet P8 values (e.g. java.naming.provider.url) in the new section so
that it points to the new realm.
5. Restart the application server.
6. Log in to Enterprise Manager as GCD administrator (gcd_admin). Run the
Create Directory Configuration wizard. Enter the same directory service
configuration property values that you just added to the authentication
provider.
7. Repeat steps 1 and 2 for each additional directory server naming context that
you want to configure as FileNet P8 realms.
8. Test the new configuration by logging in to a client application with an account
residing in the newly configured realm.
9. Grant the new users and groups access to objects by logging on to Enterprise
Manager as object store administrator and adding the new accounts to
document classes.

How to...

247

Deny an object store administrator access to a document

Use this procedure to create a marking that denies an object store administrator
(object_store_admin) access to a document.
This procedure follows the general steps described in the procedure Create a
marking set.
Creating a marking set and applying it to a class of objects is a multi-step
procedure. Refer to Markings if you need more information about the options
mentioned below (and especially about how to set the marking's Constraint Mask
and Security). The following procedure is a sample, designed to accomplish one
simple task and could be modified to accomplish additional tasks required by your
security design.
Attention: Any time you deny basic administrative privileges, like to an object
store administrator (object_store_admin), you run the risk of unintended errors.
This procedure will deny access only to new documents based on the document
class to which you add the property template created below. It will not
automatically or instantly deny access to any existing documents.
To create a marking set that will deny an object store administrator access to a
document
1. Create the marking.
a. Right click Enterprise Manager's P8 domain root property sheet and select
the Marking Sets tab. All marking sets already defined for the P8 domain
appear in this list.
b. Click Create to open the Create a Markings Set Wizard. The Welcome page
of the wizard opens.
c. Click Next. The Select Markings Set type page opens.
d. Select List (non-ordered) and click Next. The Add Markings page appears.
e. Type a name for the marking set. For example, you could enter "Deny
Admin Access". Click New Marking. The Create New Marking property
sheet appears.
f. In the General tab, type a name for the Marking Value that will deny object
store administrators access to the affected documents. For example, you
could enter "Modify Owner" (since it is the Modify Owner right that will be
denied in the constraint mask).
g. Click the Constraint Mask tab and click Deselect All, then select only
Modify owner. This is the access right that will be denied by the marking.
h. Click the Security tab and then click Add. This opens the Select Users and
Groups dialog box.
1) Use the dialog box to find and and then add the names of all users and
groups that should be allowed access to the document. For these
accounts make sure the Use Marked Objects right is selected. The
marking's constraint mask will have no effect on these users and groups.
2) Use the dialog box to find and then add the names of all users and
groups that should be denied the Modify Owner right. For these
accounts make sure the Use Marked Objects right is deselected. The
marking's constraint mask will apply to these users and groups.
(The other two rights, Add Marking and Remove Marking, are
administrative permissions. For explanations, see Markings. )

248

Security Extract

i. Click OK to close the Select Users and Groups dialog box and return to the
Create New Marking property sheet's Security tab.
j. Click Next to proceed to the Completing the Create a Marking Set Wizard
page.
k. Click Finish to complete and close the wizard. Click OK if a dialog box
pops up to confirm that you have successfully created a Marking Set. The
marking set you just created shows up in the P8 domain property sheet's
Markings Set tab.
l. Click OK to close the property sheet return to the default view of Enterprise
Manager.
2. Create the Property Template.
a. Create a new property template. Right click Enterprise Manager's Property
Template node and select New Property Template. This opens the Create a
Property Template wizard.
b. In the Wizard's Welcome page, click Next.
c. In the Name and Describe the Property Template page, enter a name and
optional description. For example, you could enter "Marking Deny Admin
Access". Click Next.
d. In the Select the Data Type page, select String type. Click Next.
e. In the Select a Choice List page, select Assign marking set and pick the
marking set you created from the list. Click Next.
f. In the Single or Multi-Value? page, select Single for the purposes of this
sample. Optionally, you could click More and use the More tab to specify
the desired marking value as the default value of the string property, rather
than having to set it on each new document
g. Click Finish to complete and close the wizard. Click OK if a dialog box
pops up to confirm that you have successfully created a Property Template.
The property template you just created shows up in Enterprise Manager's
list of property templates.
3. Assign the property template to a class.
a. Select and expand Enterprise Manager's Document Class node. Select the
document class that should be associated with the new marking set and
select Add properties to class. This opens the Add Properties to a Class
Wizard which will let you add a property based on the new property
template you just created. The new custom property shows up on the right
side of Enterprise Manager when you select the class.
4. Create a document based on the class.
a. Run the Create a New Document wizard to create a document based on
that document class. Unless you set a default value for the property as
described above, the wizard you use to create the object will not set the
marking value for the marking-enabled property. You have to do that in the
next step.
b. Set the markings on the document (but see the Note below):
v Right-click the document and select Properties. Select the Properties tab.
v In the property grid's Property Name column, find the property you
added to the class in the step above.
v Click either the Property Value cell or the cell's arrow. Any markings that
have already been set as values for the property will appear in the list.
You will also see Edit List.

How to...

249

v Click Edit List to open the Add/Remove List Items window, which you
can use to add or remove markings. Note that you will only be able to
see those markings that you have permissions to apply.
v When you are done setting values, click OK to close the object's property
sheet. The object store administrators whose names were added to the
first marking above will be able to run Enterprise Manager but will not
be able to see the documents.
Tip: If you created a single marking and if you set the default value as
described above, you will not have to explicitly set the value as described in
this step.
Related information:
Create a marking set

Modify an object's security

Use this procedure to modify the security of an object like a document or folder.
1. Log on to Enterprise Manager as an object store administrator
(object_store_admin).
2. Navigate to the object.
3. Display the object's properties, and then select its Security tab.
4. Use the security editor to add or remove users or groups and to set their
security.
5. Click OK when you are done.
Related information:
Security tab

Restrict access to the root folder

Use this procedure if you want to keep some users from adding documents and
folders to the object store's root folder.
When a user opens an object store using Workplace or Workplace XT, the user sees
the contents of the object store's root folder. By default, the root folder's security
grants Modify Properties access rights to the non-administrative groups selected
during installation. This means that unless you change the root folder's security,
members of those groups can add folders at the top level of the folder tree. To
specify who can add documents and folders at the top level:
1. In Enterprise Manager, right-click the Root Folder and then select Properties.
2. Click the Security tab.
3. Add the groups who are allowed to add top-level folders, and set the Modify
Properties access right to Allow for those groups.
4. Set the Modify Properties to Deny for those groups who are not allowed to add
top-level folders.
5. Click OK when you are done.

Set security on workflow queues and rosters

The security of workflow queues and rosters can be set in the Process
Configuration Console.

250

Security Extract

You set access rights on workflow queues and rosters using Process Configuration
Console, from the Admin page in Workplace or the Tools menu in Workplace XT.
To use Process Configuration Console, you must be a member of the group defined
by the Access Role PWConfiguration. To make configuration changes to queues
and rosters, you must be a member of the Process Engine Configuration Group.
See Set security levels in Process Configuration Console online help for detailed
instructions.

Take or change ownership

An object store administrator (object_store_admin) might need to take or change
ownership of an object. For example, if a user has left documents in an exclusive
checkout state but is no longer available, the administrator could take ownership
of the document and cancel the checkout.
See Object ownership for reference information.
To take ownership of a document using Enterprise Manager:
1. Log on to Enterprise Manager as object store administrator (object_store_admin).
2. Navigate to the document. Right-click it, select Properties, and select the
Security tab.
3. Click Advanced, and then select the Owner tab.
4. To take ownership: select Take ownership of this object and click OK. The
account you are logged in as becomes the owner of the object.
5. To change the owner: select Change owner to and click Find to open the Select
Users and Groups dialog box and find the object's new owner.
6. Click OK when you are done.

Update object store with new users and groups

Use this procedure to add new accounts to an object.
You can easily add new users to an object store that is already in production, as
long as you only want them to have permissions on objects created subsequent to
their addition. See Add users and groups to a class for this procedure.
However, adding new users so that they have default permissions to all existing
objects requires a different procedure, and uses the script WizUpdateOSSecurity.vbs
installed by the Content Engine installation program. This script updates an
existing object store's security with users and groups as if they had been added
when the object store was originally created. These users and groups can be given
default permissions as users or as object store administrators.
The WizUpdateOSSecurity.vbs script can be run through the security script wizard,
or it can be run by itself. This script:
v Does not directly modify documents and custom objects. However, it does set
permissions on Enterprise Manager's root folder. Thereafter, you can configure
security parentage so that the root folder becomes the security parent of any
folders, documents and custom objects that should inherit the new permissions.
This applies the same effective security as if all these documents, custom objects,
and contained folders had been directly modified. Keep in mind, however, the
different behavior between directly applied security and inherited security.
v Does modify the security on all other securable objects.
How to...

251

v Does not remove or modify existing security permissions.

To update an object store with new users or groups:
1. Right-click the object store node and run the security script wizard.
2. When it asks you to select an XML security script information file, browse to
and select OSecurityUpdate.xml.
3. When it asks you to define security roles, you should see two roles under
Security Role: Object Store Administrators and Object Store Users. If you do not
see these roles, you have not loaded OSecurityUpdate.xml properly.
4. Click the Add button to add security participants for the selected role. The
Select Users and Groups dialog box will open. Click OK when you have added
the participants for that particular role.
5. Click Finish when you are done. The wizard will proceed to apply the security
permissions to the objects in the object store. This can take some time,
depending on the number of objects that need to be updated. The wizard will
inform you when the process of applying security is complete.
6. Examine the new permissions on Enterprise Manager's root folder. Depending
on how you have configured the inheritance from the root folder and all
generations of child folders, these new permissions might not yet have been
inherited. You should configure the folder security parentage as appropriate.
Related information:
About the Security Script wizard

252

Security Extract

Security example
This example describes a business process, analyzes the work performed by
various users, and describes how to create groups, document classes, and folders
to achieve appropriate security.
Imagine a credit card approval process where:
Clerk

A clerk adds new credit card applications to the object store. For each
application, the clerk selects the document class CCAppls and files the new
document in the /NewAppls folder. (The administrator has configured a
subscription to launch a workflow for each new document in the CCAppls
document class.) The workflow routes the application, as an attachment, to
an applications processor.

Applications processor
An applications processor reviews the application and approves it, denies
it, or refers it to the analyst for further review. The decision is noted in the
document properties. Depending on the decision, the workflow (using the
processor's access rights) refiles the application in the appropriate
/Approved, /Denied, or /Pending folder.
Analyst
The analyst investigates all applications filed in the /Pending folder. The
analyst updates the application information as needed, approves or denies
the application, and returns it to the approval representative.
Manager
The manager writes and updates procedures from time to time and
publishes them to the /Procedures folder. The manager spot-checks
processed applications and keeps an eye on the work in the /NewAppls
and /Pending folders.
Everyone
Everyone must be familiar with department procedures.
Analysis
Setup on page 255

Analysis
Analyzing the environment requires several steps.
The analysis requires these steps:
Describe the work
List the operations performed by the various users.
Table of users and typical operations performed by them.
User/Function

Operation Performed

Clerks

Add applications to the /NewAppls folder

Copyright IBM Corp. 2006, 2011

253

Table of users and typical operations performed by them.

User/Function

Operation Performed

Processors

Participate in a workflow
Display credit card applications
Set status (a document property) to
approved, denied, or pending
Move documents from /NewAppls to
/Approved, /Denied, or /Pending folder

Analyst

Participate in a workflow
Display credit card applications
Set status (a document property) to
approved or denied

Manager

Add documents to /ProceduresSource folder

Publish documents to /Procedures folder
Display credit card applications in all folders

Administrator

Define and update workflows, publish

templates, and document classes

Determine the access rights required for the work

List the access rights required for the folder and document operations.
Table of folder operations performed by users and the access rights required to do them.

254

Security Extract

Folder Operations

Users

Access Rights Required

Add document to the

/NewAppls folder

Clerks

View Properties
Add to Folder

View contents of /NewAppls Processors

folder

View Properties

Remove document from

/NewAppls folder

Processors

View Properties

Add document to
/Approved, /Denied,
/Pending folders

Processors

Add document to
/ProceduresSource folder

Manager

Publish document to
/Procedures folder

Manager

Display contents of
/NewAppls and /Pending
folders

Manager

Add to Folder
View Properties
Add to Folder
View Properties
Add to Folder
View Properties
Add to Folder
View Properties

Table of document operations performed by users and the access rights required to do
them.
Document Operations

Users

Access Rights Required

Display applications

Processors

View Properties

Manager

View Content

Analyst
Update application status
(document property)

Processors

Modify Properties

Update application content

Analyst

Modify Properties
Modify Content

Publish procedures (source)

documents

Manager

View Properties
View Content
Modify Properties
Publish

Use publish template to

publish procedures

Manager

View Content

Define workflows, publish

templates, and document
classes

Administrator

None, the admin has Owner

Control. Must belong to
PWDesigner, if the group
exists, to define workflows.

Display and print procedures All users

View Properties
View Content

List the data objects

List the data objects that must be secured.
v Document classes: CCAppls, CCProcedures
v Folders: /NewAppls, /Approved, /Denied, /Pending,
/ProceduresSource, /Procedures
v Workflow: CCProcess
v Publish Template: CCProceduresPublishing

Setup
Creating LDAP accounts is the first step in this example.
To set up security for the credit card approval process, the administrator will:
1. Create users and groups in the configured authentication provider's directory
service.
To simplify maintenance, create a group for each function, even if only one
person performs the function. You then update the group membership when
job assignments change. For this example, we'll create the following groups:
v CC_ApplsEntry
v CC_Processing
v CC_Analyst
v CC_Manager.
Security example

255

2. Define document classes in Enterprise Manager.

a. Create the CCAppls document class.
Display the Default Instance tab, and add the groups, with the access
rights indicated in the table below. Optionally and alternatively, you can
associate the CCAppls document class with a security policy that will apply
appropriate security to applications depending on the version status.
Table of access rights to assign to the listed groups for the document class CCAppls
Group

Access Rights for Document Class:

CCAppls

CC_ApplsEntry

View Properties

CC_Processors

Modify Properties

CC_Analyst

Modify Content

CC_Manager

View Properties

b. Create the CCProcedures document class.

Display the Default Instancetab, and add the groups, with the access rights
indicated in the table below. Optionally and alternatively, you can associate
the CCProcedures document class with a security policy to apply security
appropriate to the procedure's version status.
Table of access rights to assign to the listed groups for the document class CCProcedures
Group

Access Rights for Document Class:

CCProcedures

CC_ApplsEntry

View Properties

CC_Processors

View Properties

CC_Analyst

View Properties

CC_Manager

Modify Properties
Publish

3. Define the workflow using Process Designer. Define the workflow used by
applications processors and analysts.
Table of access rights to assign to the listed groups for the workflow definition CCAppls
Group

Access Rights for Workflow Definition:

CCAppls

CC_Processors

View Properties

CC_Analyst

View Properties

4. Define the publish template using Publishing Designer.

Table of access rights to assign to the listed groups for the Publish Template
CCProceduresPublishing
Group

Access Rights for Publish Template:

CCProceduresPublishing

CC_Manager

View Content

5. Create folders using Enterprise Manager.

Create folders with the access rights indicated in the tables below.

256

Security Extract

Table of access rights to assign to the listed groups for the folder NewAppls
Group

Access Rights for Folder: /NewAppls

CC_ApplsEntry

Add to Folder

CC_Processors

Add to Folder

CC_Analyst

View Properties

CC_Manager

View Properties

Table of access rights to assign to the listed groups for the folders Approved and Denied
Group

Access Rights for Folders: / Approved and

/Denied

CC_Processors

Add to Folder

CC_Manager

View Properties

Table of access rights to assign to the listed groups for the folder Pending
Group

Access Rights for Folder: /Pending

CC_Processors

Add to Folder

CC_Analyst

View Properties

CC_Manager

View Properties

Table of access rights to assign to the listed groups for the folder ProceduresSource
Group

Access Rights for Folder: /ProceduresSource

CC_Manager

Add to Folder

Table of access rights to assign to the listed groups for the folder Procedures
Group

Access Rights for Folder: /Procedures

CC_Manager

Add to Folder

All other groups

View Properties

Optionally, a folder can be the security parent for the contained objects
(subfolder, documents, and custom objects). This requires configuration of the
parent folder and each contained object.

Security example

257

258

Security Extract

Frequently asked questions about FileNet P8 Platform

security
Some common security questions answered.
When you add non-administrative users while running the object store wizard,
what default permissions do they get?
On documents: View Content (on the class Default Instance Security ACL)
plus Create Instance (on the class Security ACL).
On folders: Modify Properties.
On the object store: Use object store.
How is a document's security set?
When first created, documents get permissions from the Default Instance
Security ACL and default security policy of its class. They can also inherit
permissions from a security parent, if configured. When documents go
through versioning changes (by being checked out, checked in, promoted
or demoted) their security can change if there is a properly configured
security policy associated with the document.
Are all objects securable?
Most objects that users and administrators work with are directly
securable. If an object's property sheet contains a Security tab, then it is
directly securable. However, some objects have the same security as some
other (owner or container) object that they are dependent on. For example,
once a choice list is added to a document, it has the same security as the
document.
Where does Content Engine store the security descriptors for its objects?
Content Engine's configured database has tables that contain all
information about objects, properties, classes, etc, including the fully
encrypted security descriptors for these objects.

Copyright IBM Corp. 2006, 2011

259

260

Security Extract

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law: INTERNATIONAL
BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS"
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. Some states do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

Copyright IBM Corp. 2006, 2011

261

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA 95141-1003
U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,

262

Security Extract

modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries,
or both. If these and other IBM trademarked terms are marked on their first
occurrence in this information with a trademark symbol ( or ), these symbols
indicate U.S. registered or common law trademarks owned by IBM at the time this
information was published. Such trademarks may also be registered or common
law trademarks in other countries. A current list of IBM trademarks is available on
the Web at http://www.ibm.com/legal/copytrade.shtml (www.ibm.com/legal/
copytrade.shtml).
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.
Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in
the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States, other
countries, or both. Other company, product, and service names may be trademarks
or service marks of others.

Notices

263

264

Security Extract

Index
Special characters
.NET client 53
#AUTHENTICATED_USERS
#CREATOR-OWNER 212

211

A
access rights 71, 87
annotation 98
class 91
compound document 95
custom objects 99
deny access to document 248
document 93
document entry template 103
document lifecycle 97
Enterprise Manager UI 220
event and subscription 100
folder 92
for document operations 109
mapped to permissions 243
object stores 90
overview 63
publishing 100
script 100
search 102
workflow 99
workflow roster and queue 103
Workplace and Workplace XT security
editor 221
ACE security levels 68
ACE source 67
ACE type and order of evaluation 68
activate new users and groups 230
Active Directory Lightweight Directory
Services 160
AD LDS 160
ADAM 160
admin account Workplace XT 191
admin accountApplication Engine 191
Allow ACE 68
annotation access rights 98
applets 219
Application Engine admin account 191
Application Engine deploy account 180
Application Engine installation
account 178
application server
LDAP user account 190
application server accounts 207
application server administrator 207
application server installation
administrator Content Engine 181
application server installation group
Content Engine 181
appserver_admin 207
authentication
AD LDS 160
ADAM 160
CA Directory 129
Copyright IBM Corp. 2006, 2011

authentication (continued)
IBM Tivoli authentication 133
Novell eDirectory 138
Oracle Directory Server Enterprise
Edition 146
Oracle Internet Directory 142
Windows Active Directory 150

B
Bootstrap admin 192
bootstrap administrator
change passsword 233
bootstrap properties 216
browser security settings 70

C
CA Directory 129
directory configuration
properties 131
get and search 133
overview 130
support matrix 130
ce_bootstrap_admin 233
ce_db_user 202, 203, 204
ce_service_user
Active Directory 194
AD LDS 195
CA Directory 199
IBM Tivoli 197
Novell eDirectory 197
OID 198
Oracle Directory Server Enterprise
Edition 196
CFS for IS user 201
classes security 73
Clear Text 225
client connection 70
client session 70
configure multiple 245, 246, 247
content encryption 227
Content Engine application server
installation administrator 181
Content Engine application server
installation group 181
Content Engine directory service
account 193
Content Engine installation account 182,
183
Content Engine instance accounts for DB2
for z/OS 185
Content Engine operating system user
account 182, 184
Content Engine operating system user
account for DB2 for Linux, UNIX and
Windows 184
Content Engine operating system user
account for DB2 for z/OS 185

Content Engine service user

Active Directory 194
AD LDS 195
CA Directory 199
IBM Tivoli 197
Novell eDirectory 197
OID 198
Oracle Directory Server Enterprise
Edition 196
Content Engine system user 192
Content Engine upgrade user 191
content search security 70
cookies 70
credential encryption 224
cryptopgraphic keys 225
custom object security 77

D
DB2 for Linux, UNIX, and Windows
database user 203
DB2 for z/OS database user 204
Default ACE 67
default security
security 68
Deny ACE 68
deploy account Application Engine 180
digital signing 219
Direct ACE 67
directory service providers
overview 127
document access rights 93
document security 76

E
eForms security 71
email attribute for login 239
encoding 225
encryption 224, 225, 227
Enterprise Manager
security 222

F
failover support
using domain names 155
failover support, Active Directory
using host:port pairs 155
FAQs about security 259
folder
add documents and subfolders 232
configure to be security parent 235
folder security 74
folder security parent
configure 236, 237, 238
folders
root folder 250

265

GCD admin 193

GCD administrator
add or remove 231
guest account 221

network security issues 223

Novell eDirectory
configure sorting 174
directory configuration
properties 139
get and search 141
overview 138
support matrix 138

RC4-HMAC Security 48
realms 245, 246, 247
redirect to SSL 221
Rendition Engine user account
root folder
restrict access to 250

securable objects
security 86
security
database security 70
installing third-party fixes and service
packs 69
users and groups 177
security example
analyze security requirements 253
credit care approval process 253
set up security sequence 255
Security identifier (SID) 63
security inheritance 122
security policies 112
assigning 114
custom objects and folders 117
effects of change 115
overview 113
preserve direct ACE 115
rules of association 116
templates 114
Workplace and Workplace XT 117
security tools 215
security:
users and groups 211, 212
select users and groups 221
session key 70
show or hide security page 221
SID 63
site preferences 221
SQL Server database user 202
SSL 227
storage area security 117
content cache area 121
file storage 118
UNIX 121
Sun Java System Directory Server
configure sorting 166
get and search 149
overview 146
symmetric encryption 225

I
IBM Content Search Services installer
account 189
IBM Content Search Services operating
system account 189
IBM Content Search Services security 70
IBM Enterprise Records search
security 71
IBM Legacy Content Search Engine 70
IBM Legacy Content Search Engine
operating system user 187
IBM Legacy Content Search Engine
security group 188
IBM Legacy Content Search Engine
security user 189
IBM Tivoli authentication
directory configuration
properties 135
get and search 137
overview 133
support matrix 134
IER search security 71
inherit from folder 235
inherit security from folder 236, 237, 238
inheritable depth
configure 243
inheritance
allow or disallow 232
Inherited ACE 67
install 185
install Application Engine 178
install Content Engine 183
install Rendition Engine 201
install Workplace XT 178
installation account Content Engine 182

K
K2 search security 70
k2_os_user 187
k2_sec_group 188
k2_sec_user 189
Kerberos 53
Kerberos on the client 50

M
Markings 79
Add, Remove, Use 81
administration 85
Allow and Deny 83
constraint mask 82
Copy to Reservation 82
hierarchical and non-hierarchical
overview 80
Master Key
resetting 226

266

Security Extract

84

object security
modify 250
object store
add new users 251
object store administrator 194
add or remove 231
object store security 72
object_store_admin 194
operating system accounts 177
Oracle database user 203
Oracle Directory Server Enterprise
Edition
configure sorting 166
directory configuration
properties 148
support matrix 146
Oracle Internet Directory
directory configuration
properties 143
get and search 145
overview 142
support matrix 142
other object security 78
ownership 105, 251

P
P8 domain root security 72
parent folder 236, 237, 238
passwords 225
pe_admin_group 200
pe_config_group 200
pe_service_user 199
Process Engine administrator group 200
Process Engine configuration group 200
Process Engine database user for DB2 for
Linux, UNIX and Windows 205
Process Engine database user for DB2 for
z/OS 187, 205
Process Engine database user for
Oracle 206
Process Engine database user for SQL
Server 207
Process Engine installation account 185
Process Engine installer account 186
Process Engine region administrator 200
Process Engine service user 199
property modification access 107
PSConsole 209
PSDesigner 209
PWAdministrator 210
PWConfiguration 210
PWDesigner 211
PWDiagram 211

201

T
take ownership 251
target access required
Template ACE 67
TLS 227

121

U
UPN attribute for login 239
user credentials 225
users and groups
add to a class 229, 230

V
Verisign 219
Verity search security

70

W
Windows Active Directory
directory configuration
properties 152
failover support 155
get and search 158
realm configuration 154
support matrix 150
Windows Active Directory Lightweight
Directory Services
directory configuration
properties 163
get and search 165
overview 160
support matrix 162
workflow queues and rosters 251
Workplace XT admin account 191
Workplace XT installation account 178

Index

267

268

Security Extract




Product Number: 5724-R76

5724-R81

GC19-3234-03