Using Plone with custom security check


We have an existing product that we'd trying to integrate Plone into. Our product has users that interact with clients through a web interface, and we'd like to use Plone to handle client-related documents. Only certain users can interact with certain clients, and we'd like to be sure that Plone limits access to client documents in the same way. A simple SQL query can determine whether a given user (determined by SSO token) should be allowed access to client information, but I'm trying to figure out the best way to have Plone take advantage of that query.

Would it make the most sense to:

  • Use an existing add-on to determine whether a given file is something a given user can access?

  • Take advantage of Plone group permissions, and use API calls to periodically update Plone with what users should be in what groups?

  • Develop a new add-on, perhaps with a new Security Policy that invokes the aforementioned SQL query?

  • Use some other solution?

I'm excited by the possibilities Plone offers us, but I'm having trouble wrapping my head around all the associated pros and cons with these options. What do people familiar with Plone think would be the best approach to this problem?


I was watching yesterday this presentation from @esteele at the Plone Conference 2016 in Boston; it could be interesting for you:

check also this example product:

A client is using a similar scenario.

In his scenario, his clients have different Plone portals. Every such portal contains the documents for the corresponding client. A PlonePAS plugin ensures that users are only authenticated in the portal associated with the adequate client (it looks into a Postgres database for this). It also adds appropriate roles or groups to the user (based on configuration in the relational database).

Some portals can be associated with more than a single client. The above mentioned PlonePAS plugin can recognized those situations, authenticate the corresponding users and assiciate appropriate roles and groups with them.

A (local) SSO is used to ensure that a user authenticated in one portal is automatically authenticated in another portal that knows him (however with the appropriate roles/groups in this context).

A specialized search is used to integrate "foreign" content (i.e. content maintained in a different portal) into a given portal.

This sounds very close to what we're looking for! Is the PlonePAS plugin publicly available, or is it something they came up with in-house?

hvelarde - That was an interesting presentation - I haven't focused much on the SQL part of the problem yet, I've been assuming we'd be able to figure something out once we got closer! Thanks for that!

Completely developed "in-house". But, it should not be difficult once you have understood PlonePAS and its base (PluggableAuthService). You can use the publicly available plugins as guidance. There are also plugins available which integrate with a relational database.

Are there any good online resources for learning about PlonePAS and the PluggableAuthService? I've tried installing them both using the buildout.cfg file, as well as running easy_install Products.PlonePAS (and Products.PluggableAuthService); but I don't see any change in my Plone site, or an entry for either of these in the Add-ons section. I do see other add-ons that I've added to the buildout.cfg file, though. I suspect that I misunderstand how these are supposed to be installed/used, but I'm having trouble finding information about how to make use of them.

Along these lines - is there a repository of public PlonePAS plugins someplace, similar to for Plone add-ons?

PlonePAS is a standard component of Plone; it is always there and there is no need to install it separately.

PlonePAS is used to implement the acl_users object in a Plone portal. You can explore this object using an url of the form <url_to_your_plone>/acl_users/manage_workspace. What you see there are objects used to implement plugins. Via the "add" action, you can add more plugins. To be effective, a plugin must be in acl_users and it must be activated. You use the Plugins tab to manage activations.

PluggableAuthService (and by extension PlonePAS) splits authentication and authorization into a multitude of tiny subtasks. Each such subtask is specified by an interface (which often has a single method). A plugin implements one or more such interfaces and thereby can perform the corresponding subtasks. The Plugins tab, mentioned above, gives you an overview of the potential subtasks (respectively interfaces).

To learn about the details of the interfaces, you look into the source tree
for Products.PlonePAS and Products.PluggableAuthService; watch out for interfaces.