Working of Authentication and PAS in Plone

Development Developing for Plone
,
1

Hello Andreas Jung(@zopyx),

Thank you for your feedback. I have been working on the changes you suggested for my proposal for the project "Add WebAuthn 2 support for Plone" and need more info to work on implementing and integrating with Plone.

I would like to know more about the working of existing authentication processes and Pluggable Authentication Services(PAS).

  1. How is a user authenticated in Plone?
  2. What is PAS and how is it integrated into Plone?

Thank you.

2

Complicated story but I am trying to explain it in short:

PAS is a compentent in Plone that handle authentication, authorization, password management etc. - basically all aspects related to authentication and authorization. The architecture of PAS is pluggable.
By default, we authenticate using username + password against the local Plone user database. An LDAP plugin would authenticate against a remote LDAP server. Every plugin may implement a different set of functionalities like authentication-only (e.g. Plone would not provide password management for LDAP users). You may all these specific aspects of PAS on my

Plone demo site (admin/admin as login).

For the authentication part (easily spoken):

  • the login form data is send to Plone (in terms of the Plone REQUEST object)
  • the data is handled to PAS
  • the PAS plugins that implement the authentication functionality are asked in sequence if they
    can handle the REQUET (aka "do you know the username in your user database"). So a user
    may be found in the Plone user database, in LDAP (if configured), in AD (if configured).
  • after asking all authentication plugins, you either have one or one user source that could
    authenticate the login request.
  • a successful login will be indicated by a returned authentication cookie __ac

The same is true for roles and authorization. A request to Plone is either authenticated according to one user source or the user is considered being the Anonymous Users. For the authenticated user (even for the Anonymous Users), a PAS plugin can return a set of roles of group associated with the particular user. Again, Plone has its own concept of roles and group. Other plugins for LDAP could introduce supplementary roles and groups if the related plugin is written or configured for providing roles and groups.

I hope, this is explains a bit further. For sure, I can search and provide additional explanations on Monday, if needed...weekend now :slight_smile:

4 Likes
3

Thank you @zopyx for the clarification.

I want to confirm some things

  1. does Plone have a central users directory that LDAP uses or does every Plone instance have a separate user directory?

  2. Are multiple PAS plugins used for authenticating users like one for searching users and then another for authenticating or are both implemented in the same plugin as different functions? this leads to another question for 2FA will we use a different plugin for each factor?

  3. is the front end, the pages that the user interacts with implemented in PAS or is PAS just a backend plugin? if it is only a backend plugin how can we prompt the user for details about the second factor?

Also, can you share the repo link for the demo site you shared both front and backend with PAS?

Best,
Pavan Thota

4

First, the primary documentation on PAS is here:

https://docs.plone.org/4/en/old-reference-manuals/pluggable_authentication_service/index.html

Although for version 4, they also apply to the most current Plone versions.

  1. Plone does not use LDAP. All user accounts (usernames and hashed passwords) are stored within the ZODB (acl_users/source_users). Supplementary PAS plugins may implement an authentication against specific users sources like LDAP. Plone sites are individual and have their own default user database.

  2. A PAS plugin can implement the functionalities that it needs for doing its jobs. A PAS plugin for example it is not required to implement a search functionality. A PAS plugin for WebAuthn support would implement only those interfaces/functionalities that it needs - nothing more, nothing less.

  3. PAS is the backend part with its API. The frontend part is completely decoupled.