Imagine that you’ve set up Alfresco Share as an Intranet within your company, and you’ve created a site for each department. Every site probably has a small number of managers that invite users, maintain the dashboard, and generally keep the information on the site all nice and tidy.

Let’s say that you also have some sites that you use to collaborate with external customers, partners, or vendors. You’ve opened up a hole in your firewall so that these external users can access Alfresco Share, and you’ve been careful to invite those users only to the specific sites that they should have access to.

You may think everything is secure, but no matter how careful you are, when you are letting external users into your Alfresco system, it’s possible for your internal users to accidentally share sensitive confidential information with those external users.

Here’s how it can happen.

1) Creating Public Sites

When you create a new site in Share, the default visibility is Public, which means that every user in the repository can participate in the site as a consumer, even if they haven’t officially joined the site.

Documents in public sites are easily returned in search results, and external users can download them and read them without your knowledge. Public sites are a bad idea if you have any external users in your system.

2) Sharing Documents with Everyone

Users in Share have the ability to change permissions on documents they create. They can share the document with other users, other groups, or with a special group called “EVERYONE”.

It’s not uncommon for a user to share a document with EVERYONE, assuming that it means everyone in the company, and not realizing that it includes every user in the repository. Most casual users don’t even realize that the system is being accessed by external users. But when a document is shared with EVERYONE, it’s available to both internal and external users, and this can allow sensitive information to fall into the wrong hands.

3) Inviting External Users to Internal Sites

Managers of sites have permission to invite other users to join their site. They can invite users that already exist in the repository, or they can invite external users that don’t yet have a user id. Alfresco Share makes it really simple to invite external users, and this can be a problem for some companies.

Let’s say a site manager invites an external user, but the user does not yet have an login ID for Alfresco. No problem – Alfresco will automatically create a user account, give that account access to the site, and send the user an email with their username, password, and a link to join the site.

While this behavior might be just what you want for an external community site, most IT departments would be horrified to learn that random Alfresco users can give strangers access to the corporate document repository without anyone knowing about it. To make matters worse, the current site manager can give the external user manager-level access, and now the external user can invite even more external users.

4) Putting External Users in Internal Groups

Like most enterprise applications, Alfresco has the ability to create groups of users that make managing permissions much easier. In many companies, documents are shared with groups of users, rather than individuals. You might want to give the Marketing group access to the sales team’s documents, for example.

Lets say that several months later, the marketing team brings on a contractor from an external advertising agency. It only makes sense to put that contractor in the Marketing group so she can get access to the marketing documents. But it’s often the case that the left hand doesn’t remember what the right hand has done, and unbeknownst to everyone, this external contractor now has access to all the proposals and sensitive sales documents that you probably wouldn’t want her to see.

The Blue Fish Solution

The way we’ve solved this problem for our clients is to introduce the concept of external users, external groups, and public folders. In our solution, we’ve written a job that executes every 30 seconds, identifies external users, and restricts them to accessing only those documents under a public folder. The nice thing about this approach is that it doesn’t require any customizations to Share or any serious modifications to the Alfresco server.

Here’s how it works.

When our job runs, it identifies all the external users. Any user without a company email address is considered an external user.

Note:Sometimes, you’ll have an external contractor or a board member that you trust the same as your internal users, so we’ve created a group called “Trusted External Users”. Add someone with an external email address to this group, and we’ll treat them like an internal user.

The first thing that the job does is to make sure that no external users are members of your internal groups. This prevents problem #4 above. We consider most groups in Alfresco to be internal groups, so if we find an external user in an Alfresco group, we will remove that user from the group.

Note: You may want to group your external users together, for example, into a Customers group or an External Contractors group, so we have a way to designate a group as an external group. It’s OK for external users to be in external groups.

Our job then finds any sites we haven’t seen before. If we encounter a new site, we create a Public folder in that site and set up a new site role called External User. This role appears in all the normal Share dialogs, so you can invite users to your site and give them the External User role. The External User role has no access to any documents except those in the Public folder.

Our job then starts to examine every existing site, looking at the site roles. If we find an external user with a standard site role (Consumer, Collaborator, Contributor, or Manager), we will remove the external user from that role and assign them the External User role. This solves problem #3 above.

The last thing our job does is to look at all the existing documents and folders. If we find that an external user has access to a document or folder outside of the Public folder, we remove that user from the permissions. So even if you explicitly grant an external user access to an internal document, our job will revoke that access 30 seconds later. If an internal user wants to share something with an external user, she has to move it or copy it into the Public folder.

If our job sees any documents or folders that give access to EVERYONE, we revoke that access since it would be visible to external users. In our system, you can’t give a document access to EVERYONE. This solves problem #1 and problem #2 above.

Whenever our job does takes some action, it emails the Alfresco administrators so they are aware of what’s going on.