New configuration to log in in Plone using your Google Workspace account

You can check the original post as a reference here.

Since then there have been some major changes in the pas.plugins.oidc product that we are using to implement the login with Google Workspace such as the 1.0.0 release. We have also learned how to configure either plone.registry entries or ZMI Properties using collective.regenv. So we have decided to revisit how we configure our sites to allow logging in with Google.

The creation of the Google OAuth2 app and credentials is the same as in the past, so you can check the original article for the insights.

We have made some changes in the Plone configuration part to ease how we configure our clients' Plone sites:

• OAuth configuration: now we configure the OAuth details of our app (oauth issuer, client id, client secret, ...) with a YAML file. Thanks to collective.regenv we can create a file in the file system and let Zope load the contents of that file as property values in the ZMI. It also works for plone.registry values. As you can see, the YAML file is straightforward and the integration in the Zope instance is done using an environment variable. If you are using Docker or some other orchestration system, you can even pass the contents of the YAML file in an environment variable, and thus you don't need to mount a file with its contents. You can check the options of collective.regenv in its documentation page.
• Group configuration: you may remember that in the original post we used pas.plugins.memberpropertytogroup to map the e-mail of the user with a group with the same domain name which was the one that had the required permissions. We have changed this to use a feature of pas.plugins.oidc which can use a given property of the user coming from the OIDC provider to assign this user to a group. We have found that, when using Google Workspace, the property hd holds the domain name of the user. So we configure the plugin with this property (using the YAML file explained in the previous step), and all users coming from our domain will be assigned to a codesyntax group.
• Group creation: although configuring the users to be members of a given group, you will need to create a group and assign the correct permissions. To achieve that, we have created a very simple Plone addon called codesyntax.login which creates the codesyntax group and assigns the Manager role to it. This way, when we install this product on the site, our own users are already Managers, without doing anything else.
• Deactivate the Challenge PAS Plugin: by default if you install pas.plugins.oidc it will activate its own Challenge PAS Plugin, this way when the user is presented the "Unauthorized" error, instead of showing the login form, it fires the OIDC login process. In our case, our clients will keep using their own users to log in in Plone (either Plone users or other user management systems), so we can't allow OIDC plugin to handle the challenge. So we have added the required code in codesyntax.login to deactivate the challenge.
• Easy login URL: all this is OK, but you need to remember adding /acl_users/oidc/login to each of our sites to be able to trigger this plugin, so we have added a /plone-login URL in the codesyntax.login product so that it handles the proper redirect to the OIDC provider.

So now, we just have to add codesyntax.login to our buildouts, provide the configuration yaml file, adjust the redirect URL and the environment variable, and we are ready to log in in our clients' site without much effort.