Home / Blog / May 2015 / IBM FileNet P8 Security – Concepts and Considerations

IBM FileNet P8 Security - Concepts and Considerations

27/05/15 - Written by Paul Marlborough, Senior Technical Consultant, Integritie

With over 10 years' experience designing, developing and building a wide variety of ECM solutions from single server scanning implementations to highly available fully distributed and integrated systems for major blue chip companies, Paul has a wide and comprehensive understanding of all aspects of ECM technology.

There are many different options when it comes to choosing how to set up your security on a FileNet object store also on IBM Content Navigator or WorkplaceXT, if you are using the IBM provided web based interface. The subject of security is a vast and complex one so I am going to just touch on the basics.

Security considerations should start at the root on your directory server. Before planning a P8 system be sure to consider any future expansion that may dictate at which level your FileNet groups sit in the directory tree, as this may make life easier in the future if you intend to include another domain or department, for example. Also ensure any users are added to specific groups that can then be assigned to FileNet, assigning individual users in the FileNet P8 content Engine for object stores, document classes etc can be hard to manage when employees who use the system leave or join. For this reason also try not to use existing groups that may also govern a different system or department as if the employees access needs to be revoked in future to only FileNet then it will make it harder to do this.

How many groups do I need?

To a certain extent this is up to the organisation. In my experience it depends very much on the size and complexity of the organisational structure of the company implementing the FileNet solution. For example if there are separate departments dealing with the Front end application, i.e. Navigator or WorkplaceXT etc. then a separate AE_Admins and AE_SuperUsers group may be required, also if there is a separate department building and deploying Workflows then a separate PE_Admins group may be required, however if the organisation is smaller, there may be just one or two people looking after all aspects of FileNet configuration. In this case it would be more efficient for the customer to only have to manage one admin group that has a P8Admin service user to perform all tasks. However certain admin users are a good idea to include regardless, for example a FileNet domain admin user, a directory bind user and a service user that external services can use to connect would be a minimum, and at least one user group and one Admins group.

The design of user groups for the object stores and application login is entirely dependent on the customer. Generally each object store would have its own admin group and then subsequent groups to allow different levels of security each with its own ACE (Access Control Entry) in the ACL (Access Control List), e.g. Read only, Modify properties, Modify content, Full control etc. Taking time to build a security model that best suits the organisation and the solution is a must before configuring a FileNet P8 system. Take a look at some of the following popular security models to see if any of these fit:

  • Multi-Level

  • Layered

  • Roles Access

  • State Transition

  • Chinese Wall

  • Perimeter

  • Silos

Security Inheritance

This is where it starts to get more complex. Different objects can be set to either inherit security, use a security template or have security applied directly. This can sometimes create confusion, for example when using annotations on a class of documents, the annotation class may require its own security, however if the class it is applied to is set to ‘this object and all children’ then regardless of what the annotation security is, it will be superseded by the document class security, therefor this will need to be set as ‘this object only’ to enable different security for the document and associated annotation, this example is especially confusing as the direct security on the annotation object itself will supersede the Document class, however as the document class security won’t allow you to see it the only way to view the annotation would be to search for it in the admin tool. Simple hey!! The Security hierarchy is as follows for FileNet objects:

  • Direct/Default Deny

  • Direct/Default Allow

  • Template Deny

  • Template Allow

  • Inherited Deny

  • Inherited Allow

This is a useful reference when setting security, especially when it is different on folders and documents, for example a user may have access to view a document, but if the subfolder it's in doesn't allow access then the user will not be able to see the document without searching for it. Also remember that a change to security will only apply to new objects added, it won't apply to objects retrospectively without running a security update task.

Similar can occur for folder security and even document class security for sub classes. All this only applies if there are no marking sets or security proxies set up to over write the default security. So it is worth bearing in mind that when setting the Default instance security it is exactly as described, just the default, there are many other security settings that may over ride these. So if you are scratching your head and wandering why you have changed the default instance security of a document class but when you add a new instance of that class the security isn't picked up, consider looking at the possibility of inherited security, check that there are no marking sets applied to any of the document class properties and check there are no security proxies set.

Why use a marking set?

A marking set is a very dynamic way of applying security based on a property value. For example it could be as simple as setting a property value to be 'yes' in which case everyone associated with the yes entry in your marking set can see the object, or set the value to 'no' in which case only the groups associated with the no entry in your marking set can see the document, this also means that as long as the object has the property at the time it was created, security can be quickly and easily changed for existing documents by updating only the marking set security or updating the value of the marking set property for each object individually. Another advantage of this is that a document of a sensitive nature can even be hidden from the FileNet Administrator so only a specific user can view or edit it.

Why use a security Proxy?

Proxy security can be very useful if you are applying the same security to a group of objects and you may wish to change the security access frequently and easily, this is because you will only need to change the security on one object and all other objects set to use that objects security as a proxy will inherit it without having to update every single object individually. A down side to this can be if you are looking for a more diverse model it can be more work to change, hence this will only apply to certain security models.

The setting up of the security will often be a major part of how the final FileNet solution operates and meets the requirements of a project, for this reason it is important to get it right and get it right before a project goes live or millions of documents are migrated. Changing security retrospectively can be tedious, complex and troublesome so it is well worth investing the time to get this right from the start and plan ahead to make future changes easier. There are various IBM red books and help files relating to all these concepts available online that go in to plenty of detail, these should be read carefully or consult your FileNet solution provider for advice.

For more Information on Integritie's KC Online solution, please email sales@Integritie or click here.

comments powered by Disqus
Regina Police Service SMC4
Case Management
Cumberland Building Society KC Online
social media capture
government cloud
RAC Cloud
avivia Cloud