Hide users to members

[alaindichiappar]

The use case is simple. We want to share sites, directories and documents with external counterparts keeping the framework users hidden to them, for the sake of company privacy.

Currently Alfresco does not allow us to set some configuration parameters to achieve that. For example, an external users, even with just the minimum level of capabilities can search for other users in the "People" section as well as he could see them in other specific list (eg. in the site sections).

Can anyone help us to understand how to face this issue with the least effort? Thanks.

[idwright]

The short answer is that it's not easy.

You can quite easily customize the header to remove the people finder and repository links which reduces the amount of things you can find by accident considerably even though users can still get at the information if they know how.

Another fairly straightforward thing you can do is to change the permissions within /sys:system/syseople which will also restrict the visibility of people - that's quite crude however and can cause problems if, for example, person A is not visible to person B and person A creates a document in the Shared Files space.

It's not well documented, or especially well tested, but you're welcome to have a look at cggh-alfresco-extensions/auth-platform-jar at master · cggh/cggh-alfresco-extensions · GitHub  and cggh-alfresco-extensions/auth-share-jar at master · cggh/cggh-alfresco-extensions · GitHub  - I wouldn't recommend using them without taking some time to understand how it all works, and what it's doing.(on the other hand there's not too much there)

These projects do several things in this area including, but not limited to, modifying the header menu and only allowing people to see other people who are members of the same site - you probably wouldn't want all of it.

[romschn]

One approach that comes to my mind is - put all the external users into one group. Customize people search finder in such a way that if the requesting user belongs to the external user group then do not return the standard results as it does out-of-the-box, instead just return result from the external user group only. This way external user will not be able to search other users in the repository.

Hope this helps.

[jpotts]

I agree with Ian. You are basically fighting the platform which is designed specifically to foster collaboration between individuals--secrecy is anathema to that.

I have done some work on this, though, and as Ian mentions it is a lot of work. Not only do you have to hide the obvious menu items, you also have to customize the "people picker" component so that it honors whatever rules you decide to put in place for allowing people to see each other (such as being members of the same site).

Then you've also got all of the RESTful endpoints to worry about which are public and easily discover-able.

Maybe you should just use randomly assigned user names or something.

The obvious workaround is to use two completely different applications. Share would be the "admin" or "content manager" application for internal use. Then you'd use a custom app, which probably can be much simpler than Share, as the external-facing app. The custom app could filter personal info as needed.

[idwright]

I think you'd drive yourself mad trying to customize all the places where it's possible to search for people.

The approach I took was to modify the rules for the PersonService_security bean with a new AfterInvocationProvider that removes people from the returned results. I think I saw Jeff take a different approach somewhere...

There are some (potential) drawbacks to this approach but it does mostly work for us, is reasonably simple, and does what you want but there are some places where it causes problems with the UI e.g., as described above, in shared files if you don't have permission to see the details of the owner of a file (my JIRA to fix this wasn't accepted...)

So you've still got to go through and test everywhere, make sure it scales for your installation etc,etc...

(i.e. I'm not very happy with my solution but it works for us)