Feature: Exception to abort authentication

[Dieter Maurer]

Zope 2 supports a hierarchical authentication. If a user folder is unable to authenticate a user with sufficient permissions, a higher up user folder gets the chance to authenticate the user. This is often used to give Zope "Manager"s access to subsites with their own user folder.

Meanwhile I have met two szenarios where the standard feature seems not sufficient:

 * IP based (anonymous) authorization: "Manager"s from domains matched by IP rules have a bad experience (they do not see ZMI
   actions they expect, they cannot visit parts of a subsite due to insufficient priviledges.

 * some modern authentication protocols (e.g. OpenId and SAML2) are so expensive (relying on multiple interactions witj foreign sites) that they should only be triggered when there is real need.

My idea to address these szenarios: Implementation of an "IAuthentication" plugin that checks higher up user folders whether they can authenticate the current user. However, this plugin cannot succeed in the normal way, because then the user would be associated with the current user folder not the one higher up. Therefore, I propose the definition of special exception (e.g. "AuthenticationAborted") which causes the "PluggableAuthenticationService" to stop locking for further authentication possibilities. The plugin mentioned above would use this exception to give higher up user folders their chance.

[Tres Seaver (tseaver)]

I'd be willing to merge a branch implementing this feature, assuming it
had really good test coverage for all the edge cases it creates.

[Dieter Maurer (d.maurer)]

I do not have write access to the zope repository. Are you also willing to accept a patch?

[Dieter Maurer (d.maurer)]

Having meanwhile implemented a plugin for SAML2 based authentication (--> "dm.zope.saml2"), I recognize that actually the second use case does not apply: it is very easy and efficient for an SAML2 authentication plugin to determine that there is no SAML2 authentication. The only expensive thing involved is the authentication process itself - introduced not by the authentication but the challenge plugin. This is already handled well by the existing framework.

This means that only the first use case remains -- and this is probably better handled by an extension of the `DomainAuthHelper` plugin to avoid domain based authentication when a higher level user folder can authenticate the user.

A colleague has implemented this feature for our simplified scenario where the root folder contains the only higher level user folder. It goes like this:

class RootUserFolderAwareDomainAuthHelper(DomainAuthHelper):
    ...
    def authenticateCredentials(self, credentials):
        if credentials['extractor'] != self.getId():
            return (None, None)
       # do not authenticate non "special" users recognized by the root folder. Special users have id `None`.
       if self.getPhysicalRoot().acl_users.validate(self.request).getId() is not None:
           # user recognized by root user folder
            return (None, None)
       return super(RootUserFolderAwareDomainAuthHelper, self).authenticateCredentials(credentials)

Thus, there is likely no need at all to change the framework. It might be helpful, however, to provide an option for the `DomainAuthHelper` plugin to become aware of higher up user folders as the current behaviour is likely to often cause headaches. But, if `PluggableAuthenticationService" does not directly support such an option, it is easy to implement it oneself.

[Tres Seaver (tseaver)]

> I do not have write access to the zope repository. Are you also willing
>to accept a patch?

Sure. I will also see about getting a Launchpad mirror set up for the code.

[Tres Seaver (tseaver)]

The bzr mirror is now available:

  $ bzr branch lp:zope-pas

gets you a writable checkout. You can then push your committed
changes to a branch under your Launchpad account, e.g.:

 $ bzr push lp:~dmaurer/zope-pas/bug_649596

(or whaver you'd like to call it). You can then link that branch
here to this issue.

[Dieter Maurer (d.maurer)]

I have pushed the extension to "lp:~d.maurer/zope-pas/NotCompetentPlugin".

The extension is slightly different than the ones previously described. It now defines an new plugin type "INotCompetentPlugin". Plugins of this type check whether the current user folder is competent to authenticate the current request or should delegate authentication to user folders higher up in the hiearchy. Consequently, such plugins are not used at the root user folder (as there are no higher up user folders). The extension implements one such plugin "NotCompetent_byRoles". It declares the user folder as not competent when a higher level user folder is able to authenticate the request without challenge and with a user having one of a set of specified roles. If not roles are specified, any user acceptable by the request will do.

[Tres Seaver (tseaver)]

Thanks very much for the patch. Merged to the trunk for a 1.9.0 release:

 http://svn.zope.org/Products.PluggableAuthService/trunk/?view=rev&rev=126497