So yesterday we went through how the security is structured across the workspaces, tabs, folders and documents. Now let’s look at how it’s applied.

Each item in WorkSite can have a default security. This applies to everyone accessing the folder, document etc. This the the “Shared As” option in properties.

You can set the “shared as” to:

• Private – setting to this means by default any one but the creator/author won’t be able to see the workspace, folder, document etc
• View – you can see it but access would be read only as would any property information/meta-data on the item
• Public  – you can see the workspace, folder, document etc and edit them and their property information/meta-data

The easiest way to maintain security is to simply secure at this level. However there may be occasions where you need to secure at more advanced levels for different groups/people etc

This is where the ACL (Access Control List) comes in.

This is additional security information to the basic default security “shared as” setting above. And for the groups/people named in the ACL it will override the default “shared as” setting (e.g. if the document default “shared as” security is “View”, but I am added to the ACL with Read/Write access. Everyone else will be able to get read only access apart from me who will have write access – the author/creator will of course still have write access too)

In the ACL you can add individuals or groups of individuals and assign the following access levels (remember these will supersede the default level for those individuals/groups!)

• Full Access – This allows full access to the document and full control over properties/meta-data and also the security (including for the folder, workspace etc)
• Read/Write – full access  to the document, but limited control on properties/meta-data and no ability to change security (including for the folder, workspace etc)
• Read – as it says, just allows to read documents, properties/meta-data etc
• No Access – again as it says (remember unlike Windows where you could see the folder even if you couldn’t gain access to it, in WorkSite No Access = it’s invisible)

There are a few things worth pointing out about Groups and Individuals in terms of adding to the ACL.

• Groups are extremely useful for workspaces that contain hundreds of documents and have security that changes regularly. This is because you can amend the security without having to refile everything (the refile action has to go through each document, folder etc and change the properties and security. On a large file this takes time!)
• However the downside of Groups is that users of the FileSite or Desktop clients cannot add or remove people from them. This has to be done using the database administration tool.

So before you determine your security think carefully about the following to help determine the best security to apply:

• potential size of the file (number of folders, documents etc)
• frequency of change of individuals access requirements
• degree of control the end user will need in maintaining the security

————–

OK now you hopefully understand a bit more about the default security and ACL. Let’s step back to how folders and documents inherit security from the parent folder, tab or workspace. Basically what we’re going to look at is limiting or opening up security within the workspace.

So remember the option to inherit or not?

Limiting access to sub folders or documents is easy. 

You set the top level (e.g. your workspace) as open a security setting as is acceptable e.g. Public (remember this is the “shared as” default security, not in the ACL).

You can then uncheck the inherit security on the folders you wish to secure more tightly, then either change the default “shared as” security (e.g. to “View”) or add a specific ACL to those folders.

However the real difficulty is when you want to apply a more open security to sub folders. i.e. opening access to wider audience in a sub folder that at the levels above.

So say your top level (e.g. your workspace) is Private (again remember this is the “shared as” default security, not in the ACL) and maybe it is also secured in the ACL to a group or individual. In WorkSite you can only open sub folders or tabs to people specifically listed in top (i.e. workspace) ACL!

When you think about it this is logical as if you have no access to the top level you couldn’t see the workspace, so how could you expect to see a folder within it?

This isn’t so bad, but the big gripe is that it only lists Groups, not people contained in those Groups!  i.e. the workspace is secured to View in the ACL to the IT group, then you want to allow me to have read/write access to a sub-folder. Unless I am named in the ACL as an individual as well you won’t be able to pick me at a lower level even though I’m in the IT Group!

Individual documents though are a little different. These can be opened up to either Groups or Individuals that are not listed in the top level (i.e. workspace) ACL. I guess this is logical as you could search for the document by it’s document number?!

  ————–

Finally a quick note on Roles, just for completeness. These though really aren’t essential to understanding security from a WorkSite user perspective. So if your brain is full or fried stop reading now!

In the background your WorkSite administrator will assign users of the WorkSite system to “roles”. These are settings that basically allow some overriding “security” to be applied that a user cannot amend. It will always apply to all workspaces, tabs, folders and documents etc. So your actions available within the system will depend on the role you are placed in.

Roles apply to more specific functions, like the ability to actually create a workspace or be able to physically delete documents etc. An example of a role setting is shown below: