README

AS SAML ACCOUNT GATE (as_saml_gate)

INTRODUCTION

Creates SSO accounts only for people one of your saml_role_mapping entities recognises. Everyone else authenticates successfully and is then told to contact a site administrator, exactly as they would be if account creation were switched off.

The problem it solves: saml_sp_drupal_login decides whether to create an account before it has looked at a single SAML attribute, so account_request_create_account is all or nothing. Leave it on and every person your IdP will authenticate becomes an account. Turn it off and the students and faculty your role mappings were written for can no longer provision themselves, which quietly breaks any webform whose access rules name those roles.

On the site this was written for, a year of logins produced 1,058 accounts: 953 students and faculty who submit major applications and placement questionnaires, and 101 with no role at all that had never submitted a form or authored a node.

REQUIREMENTS

saml_sp, with the saml_sp_drupal_login submodule enabled
cwd_saml_mapping, which provides the saml_role_mapping config entities this reads
A patch to saml_sp adding the hook this module implements. Without it the hook is never invoked and this module does nothing. The patch adds a saml_sp_drupal_login_allow_account_creation() helper and calls it alongside the existing account-creation condition, so it is inert unless some module answers.

Apply it with composer-patches:

"extra": {
    "patches": {
        "drupal/saml_sp": {
            "let a site refuse SSO accounts the role mappings do not recognise": "patches/saml_sp_allow_account_creation_hook.patch"
        }
    }
}

INSTALLATION

composer require as-cornell/as_saml_gate
drush en as_saml_gate

Leave account_request_create_account on. This module narrows that setting; it cannot widen it, and with the setting off there is nothing to narrow.

HOW IT DECIDES

For each enabled saml_role_mapping, the released attributes are matched the same way cwd_saml_mapping matches them, including the contains criterion.

Any mapping matches → the account is created, and cwd_saml_mapping assigns the role on the same request, as before.
No mapping matches → no account. The visitor gets saml_sp's existing "no account matching your address has been found, please contact a site administrator" message.
No mapping could be evaluated, because the IdP released none of the attributes they read → the account is created and a warning is logged. An attribute release failure should not lock out every new user at once.
No enabled mappings at all → saml_sp's own behaviour stands.

Mappings keyed on username work as well as mappings keyed on affiliation, so adding someone to a netid allowlist is enough for them to provision themselves on their next login. No administrator has to build the account by hand first.

LOGGING

Refusals are logged to the as_saml_gate channel with the email address and the eduPersonScopedAffiliation values, because that is the only durable record of who is being turned away: dblog keeps a fixed number of rows, and saml_sp's own attribute dumps are trimmed long before anyone investigates. If the affiliations in that log are not the population you expected, you are probably missing a mapping rather than looking at abuse.

CONFIG_READONLY

If your site locks configuration on production with config_readonly, admins cannot edit role mappings through the UI, and this module's behaviour is only as good as those mappings. Allowlisting is a site policy decision, so it is left to the site rather than shipped here. In your own module:

function MYMODULE_config_readonly_whitelist_patterns() {
  return ['cwd_saml_mapping.saml_role_mapping.*'];
}

Pair it with a config_ignore import entry if a config import runs on deploy, or the next deploy will overwrite what the admins changed.

MAINTAINERS

Current maintainers for Drupal 10:

Mark Wilson (markewilson)

as-cornell / as_saml_gate

Package info

Security

Statistics