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.
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 RootUserFolderA wareDomainAuthH elper(DomainAut hHelper) : dentials( self, credentials): 'extractor' ] != self.getId(): lRoot() .acl_users. validate( self.request) .getId( ) is not None: olderAwareDomai nAuthHelper, self).authentic ateCredentials( credentials)
...
def authenticateCre
if credentials[
return (None, None)
# do not authenticate non "special" users recognized by the root folder. Special users have id `None`.
if self.getPhysica
# user recognized by root user folder
return (None, None)
return super(RootUserF
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 `PluggableAuthe nticationServic e" does not directly support such an option, it is easy to implement it oneself.