Fusion ECM

1. General Concepts

From the hive mind at Wikipedia

"In computer security, an access control list (ACL) is a list of permissions attached to an object. The list specifies who or what is allowed to access the object and what operations are allowed to be performed on the object. In a typical ACL, each entry in the list specifies a subject and an operation: for example, the entry (Alice, delete) on the ACL for file XYZ gives Alice permission to delete file XYZ

In an ACL-based security model, when a subject requests to perform an operation on an object, the system first checks the list for an applicable entry in order to decide whether or not to proceed with the operation."

In Content Server (and Collaboration Server where it was first used) ACL security is an additional way of applying security to content. 

When you enable ACLs (see section 2 below), you add another level of granularity to the security model, in addition to the standard security group / role and optional accounts security.  Of course nothing comes for free, so see section 3 for best practices and applications.

2. Enable ACLs (from Billy's post below)

It�s a pretty simple two step process:

1. Add the two ACL metadata fields, xClbraUserList and xClbraAliasList.
   
2. Set the following entries in the config.cfg file
   UseCollaboration=true
   SpecialAuthGroups=
   ZonedSecurityFields=xClbraUserList,xClbraAliasList

As you�ve added custom metadata fields, if you are using Verity indexing, you�ll need to reindex (so it�s best to set this configuration before you have lots of content).

Project level security is part of Collaboration Manager and is discussed at length in the documentation for that product.  What the above settings give us is a subset of that functionality.

If you look at the Checkin page after enabling ACL security, you�ll see something like this:

Notice that you now have three new entries on the checkin page � you can create a collab project, or you can apply a UAL (User access list) or alias access list.

Clicking the select button to the right of each will allow you to select from users or aliases defined in the user and alias tables.  These can be integrated with external providers in the same way as standard security, but users will need to login once to create an entry in the table.

3. Best Practices

This section is still a work in progress, but the following are issues to be addressed in any ACL implementation.

3.1 Performance

Any additional security checks will impact performance and this performance impact will be directly proportional to the number of users and aliases defined in the system.  Care should be taken to only use the security model that is required to achieve the business goals.  If those goals require ACL security, then this will entail additional hardware cost to provide additional system resources, or a resetting of end-user expectations in terms of system response.

Remember, the more complex a security model, the longer the system will take to check that security and return search results, library listings, etc.

3.2 Aliases

Use of alias groups is strongly recommended because of the way that ACL permissions are inherited within folders and projects.  If I assign Pete and Shelley to a project, then they get permissions on all subsequent content created in that project unless I manually override those permissions on checkin.  If Pete goes to a different project and Chris is assigned to this one, I have to change the project security and then propagate the permissions update, then go back and find the manual override cases.  If I first created an alias called "CS_Team� and put Pete and Shelley in that alias, then assigned permissions to the alias, we could swap Chris for Pete in the alias and we�d be done.

This requires a slight change in admin behaviour, but is by far the best way to approach any projects with changing personnel (isn�t that all of them?).  There is a finite but small performance impact from using aliases rather than users, but in 99% of cases no-one will notice it � but they will notice if the user lists become stale and populated with incorrect usernames.

3.3 Planning

Following on from the section above, use of ACLs requires as much, if not more, upfront planning of security.  While there is granular flexibility to assign permissions at the document level, it is very easy for this scheme to get out of control.  Again, use of aliases helps in this management, but user training is important as well.  Just because they can assign permissions at the document level, they should think whether they need to.  This is particularly so in the case of frequently accessed documents, large documents, etc.

3.4 Post-processing filters

Placeholder for now pending info from R&D � currently only available in Records Manager, awaiting confirmation that it can be ported to Content Server.

The F1 racing world has been scandalized by accusations of Ferrari secrets leaked to McLaren.  The accusations center around a former Ferrari employee who subsequently went to work for McLaren and allegedly took some Ferrari documents.  You can read about it HERE.

While the truth or falisity of the personal accusations are still being worked out, this certainly highlights the vital importance of securing content outside of "the system" - whatever system that may be.

That is where Oracle IRM - Information Rights Management comes in.  As a critical part of our overall Enterprise Content Management strategy, the ability to secure content once it leaves the server - via email, or thumb-drive, or screen capture, whatever - is not to be overlooked. 

F1 Team ING Renault has this system in place, watch what they have to say about it HERE