4.0.0-alpha1 release compatible with D10/Symfony6

Created a patch for Drupal 10 compatibility, please review.
Thank You.

did u actually check that the module is working ?

No, clearly not :)

This is isn't the first issue about this and I've now explained the situation on the project page in regards to the hidden 4.x release. To help get at least an alpha release out, I need feedback that this is working on real projects.

To help get at least an alpha release out, I need feedback that this is working on real projects.

Our organization has been using the 4.x branch of drupal/simplesamlphp_auth on a production site since 8 February 2023 without issue. We are currently requiring simplesamlphp/simplesamlphp version 2.0.3.

We did not need to change anything in the configuration files of simplesamlphp for the update, but we did need to change the expected directory of the library from www to public, as I've documented in 💬 Document simplesamlphp 2.x directory change (www to public) Active .

I'm going to change the status of this issue from "Fixed" to "Reviewed and Tested by the Community" and update the title to "4.0.0-alpha1 release compatible with simplesamlphp 2.x."

I'm also changing the priority to "Major" since simplesamlphp 1.x is not compatible with Symfony 6 and therefore not compatible with Drupal 10, so any sites trying to update to Drupal 10 with this module will need a Symfony 6/Drupal 10 compatible release

It's not clear to me how you can use 4.x with a stable 2.x release? I just checked again, simplesamlphp 2.0.3 supports only symfony 5 and simplesamlphp_auth 4.x supports either 1.x or dev-master, not 2.x.

Reviewing the 4.x branch current state, I see that it declares compatibility with simplesamlphp/simplesamlphp "^1.19 | dev-master", which is incorrect:

1. simplesamlphp/simplesamlphp 1.x is not and will never be compatible with Symfony 6: https://github.com/simplesamlphp/simplesamlphp/issues/1689
2. Drupal 10 requires Symfony 6
3. The 2.x branch of simplesamlphp/simplesamlphp is compatible with Symfony 6, and by proxy, Drupal 10: https://github.com/simplesamlphp/simplesamlphp/issues/1689
4. The 2.0.0 version of simplesamlphp/simplesamlphp was released on 2023-02-23

Conclusions:
1. The 4.x branch should specify a Composer version constraint of simplesamlphp/simplesamlphp on ^2, since it is not compatible with 1.x.
2. The 4.x branch should specify a Drupal core constraint of ^10, since Drupal 9's dependency on Symfony 4 makes the 2.x version of simplesamlphp/simplesamlphp, which is compatible with Symfony 6 and incompatible with Symfony 4, incompatible with Drupal 9.x.

The attached patch implements the above conclusions. Setting to "Needs review."

The reason for supporting both 1.x and dev-master was to support both D9 and D10 in the same branch, but that was assuming the API that is relevant to us is unchanged and that assumption untested. And I guess it will take longer to stabilize than D9 EOL so fine with that part.

Again, https://packagist.org/packages/simplesamlphp/simplesamlphp#2.0.3 states that it requires various symfony 5.x packages and only those. I don't understand how can require that on a D10 project?

It's not clear to me how you can use 4.x with a stable 2.x release? I just checked again, simplesamlphp 2.0.3 supports only symfony 5

Hrmm. According to the composer.json, the 2.x branch shows compatibility with symfony ^5.4 || ^6: https://github.com/simplesamlphp/simplesamlphp/blob/master/composer.json . We do have a site running on D10 since 8 February 2023 using the 4.x branch without issues, not that my vouchsafe should be worth much; I'm not sure about how best to further demonstrate compatibility for this module, however, given the integration requirements.

That's the master branch, that is not the same as the 2.x releases at all, they don't follow common semver branch names.

Me culpa: the site that we are using the 4.x branch of simplesamlphp_auth with requires dev-master of simplesamlphp/simplesamlphp, not 2.0.3, as stated above.

Given this, this module cannot yet declare a version constraint of ^2 on simplesamlphp/simplesamlphp. So, if there is to be an alpha release from the 4.x branch in the near future, it would need to have a Composer version constraint of dev-master, which would be unusual for a release, but might still be justified for adoption of Drupal 10?

I think you can understand better now why there is no alpha release yet ;)

I'm willing to create an alpha release, but need help to update the documentation to cover:

* the www/public change
* installing a module with dev dependency on default composer template, which has a stable min-dependency. I had several support requests about people not being able to upgrade to a php8 compatible version of simplesamlphp 1.x because that requires gettext dev. probably by explicitly requiring the dev version with @dev.
* recommendation to lock dev-master down to a specific commit and update only carefully.

The problem with dev-master is that there's no roadmap or anything when it will be released. It's aliased to 3.x in composer, and while they said in the Symfony 6 issue where I made it compatible that it *might* be merged into 2.1, it's just as likely that it will take years, and the problem with that is that symfony 7 will I guess be released in november 23, so they might switch to that and then there will suddenly be no compatible version at all. It's also unclear how dev-master is kept in sync with 2.x, if and how quickly it will be updated when there are bugfixes or security releases, there are quite a few differences between those branches.

For context, the reason it is not in 2.x is that being compatible with Symfony 6 requires PHP 8 and they did not want to make that jump. According to https://packagist.org/packages/simplesamlphp/simplesamlphp/php-stats#2, php7 usage is shrinking, so we can maybe convince them to make the jump with 2.1

it *might* be merged into 2.1, it's just as likely that it will take years, and the problem with that is that symfony 7 will I guess be released in november 23, so they might switch to that and then there will suddenly be no compatible version at all

Ugh. What a mess. Well, thanks for clarifying.

I've made an attempt at documenting the items listed in #16, and have included a boldfaced statement about the risks due to the unclear roadmap for simplesamlphp. Not sure if the README.md is the best place for this. Happy to add it to d.o's documentation system, if preferred.

The attached version of the documentation avoids removal of spaces at ends of lines in the previous patch.

Will review, thank you. README is fine IMHO, gitlab also gives us a pretty readable output of it that we can link to from the project page: https://git.drupalcode.org/project/simplesamlphp_auth/-/blob/8.x-3.x/REA....

Update for anyone in the Drupal community following this issue status: I reached out to the maintainer of simplesamlphp for more information on the technical limitations of declaring a Symfony 6-compatible version of the library, and while the answer is somewhat vague (what "signature changes"), it doesn't seem like the problem is unsolvable, or due to their hesitancy to drop support for PHP 7:

https://github.com/simplesamlphp/simplesamlphp/issues/1798#issuecomment-...

I plan to follow up and contribute to whatever technical implementation problems the maintainer is encountering as I can.

Thanks @mark_fullmer and @Berdir for the work so far.

I've taken a look at the github issue and I note the maintainer has closed it. I would add my voice there but I don't want them to feel like "the Drupalers are nagging me". Is it just a case of waiting for what's in dev-master to be released now?

I note the readme file presents a(n ancient) way to install the library without composer - do you think downloading and committing the library from the dev-master branch is a reasonable work-around here?

do you think downloading and committing the library from the dev-master branch is a reasonable work-around here?

If you are using a workflow where the entire codebase is under version control, I believe what you're suggesting would work fine, although running composer update could inadvertently update those files.

Alternatives:
1. The proposed changes to this module's README ( https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.... → ) document a way to add a specific commit hash of the master branch of simplesamlphp/simplesamlphp via your Composer requirements.
2. Fork the repository at https://github.com/simplesamlphp/simplesamlphp , then add in your site(s)' composer.json a VCS repository pointing to your fork (https://getcomposer.org/doc/05-repositories.md#vcs), and then you will reliably pull in the commit that you have in your fork.

Perfect, thank you very much!

The simplesamlphp/simplesamlphp package made a commit today that raised its constraint on simplesamlphp/saml2. That makes getting this installed on Drupal 10 a bit harder but not impossible. It requires getting off of drupal/core-recommended, and bringing in some dependencies with lower stability flags. In case it helps anyone else, here's the sequence of Composer commands I was able to run to install a new Drupal 10.0.9 codebase from drupal/recommended-project:

composer create-project drupal/recommended-project:^10
cd recommended-project/
composer require drupal/core:^10.0
composer remove drupal/core-recommended
composer update
composer require simplesamlphp/saml2:^5@alpha
composer require simplesamlphp/simplesamlphp-module-adfs:dev-master@dev
composer require simplesamlphp/simplesamlphp:dev-master@dev
composer require drupal/simplesamlphp_auth:^4@dev

Note that I don't necessarily recommend or condone doing the above. Getting off of drupal/core-recommended and bringing in multiple dependencies at dev/alpha stability might not be the right decision for your site. But if you absolutely must use this module on a Drupal 10 site, I'm not aware of any other way to currently accomplish that.

FWIW, even simplesamlphp 1.x requires dev dependencies for PHP 8.1 compatibility which causes pretty frequent support issues.

The core-recommends conflict is a bit more surprising, seems to be specifically due to saml2 requiring requiring psr/http-message:^2 while core-recommends wants ~1.0.1. We don't even depend on that ourselves, we just lock down dependencies of our depencies:

$ composer why psr/http-message
drupal/core-recommended         10.0.9 requires psr/http-message (~1.0.1)
guzzlehttp/psr7                 2.4.5  requires psr/http-message (^1.0)
psr/http-client                 1.0.2  requires psr/http-message (^1.0 || ^2.0)
psr/http-factory                1.0.2  requires psr/http-message (^1.0 || ^2.0)
symfony/psr-http-message-bridge v2.1.4 requires psr/http-message (^1.0)

guzzlehttp/psr7 2.5.0 then supports v2 as well as does symfony/psr-http-message-bridge 2.2.0. Drupal 10.1-alpha1 still depends on the previous minors as well, should we update our recommended versions to those minors there, then that would remove that conflict again? (for now, dev-master clearly is a moving target, just as I expected/am concerned about).

Drupal 10.1-alpha1 still depends on the previous minors as well, should we update our recommended versions to those minors

That was committed earlier today in 📌 Update dependencies for Drupal 10.1 Fixed . Possibly not relevant for this issue, but 📌 Update to Symfony 6.3 Fixed is RTBC as well.

Confirmed, simplesamlphp_auth can be installed alongside drupal/core-recommended:^10.1.x-dev@dev, so that's good.

Re #28, yep, and that now works with today's 10.1 beta release as well. In other words, the following works:

composer create-project drupal/recommended-project:^10.1@beta
cd recommended-project/
composer require simplesamlphp/saml2:^5@alpha
composer require simplesamlphp/simplesamlphp-module-adfs:dev-master@dev
composer require simplesamlphp/simplesamlphp:dev-master@dev
composer require drupal/simplesamlphp_auth:^4@dev

Still not great in terms of needing unstable dependencies, but good that it doesn't require switching off of drupal/core-recommended.

Part of the challenge with the bottleneck on this issue is that D9's EOL is so soon due to both Symfony 4's and CKEditor 4's EOL dates. Because Drupal 10 was able to get onto Symfony 6 instead of only Symfony 5, and because CKEditor is not planning another complete rewrite anytime soon, we can potentially support Drupal 10 for longer (though not necessarily for the entirety of Symfony 6's lifetime). 🌱 [policy] Decide how long major Drupal versions should be supported Needs review is the issue discussing that and I commented in #3238652-79: [policy] Decide how long major Drupal versions should be supported → with this contrib project as an example of the kind of situation that can come up and benefit from a longer support window for the Drupal version that's on the not-latest Symfony version.

#28 I have set up a ^10.1.x-dev@dev with the simplesamlphp dependencies in #29 and get an error related to a saml2. Does anyone else see this sort of error when using these composer dependencies? It looks like somewhere along the line the saml container doesn't get created or is dropped. Is there a place were this container should be created in the simplesamlphp_auth module?

Uncaught PHP Exception Error: "Typed static property SimpleSAML\\SAML2\\Compat\\ContainerSingleton::$container must not be accessed before initialization"

I'm also seeing the same error as #31 in the Drupal logs

Besides that visiting the simplesamlphp address also gives the following:

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
2 public/_include.php:28 (SimpleSAML_exception_handler)
1 /var/www/builds/sitename/sitename-263/vendor/symfony/error-handler/ErrorHandler.php:537 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
0 [builtin] (N/A)
Caused by: Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "debug.error_handler_configurator".
Backtrace:
6 /var/www/builds/sitename/sitename-263/vendor/symfony/dependency-injection/Container.php:264 (Symfony\Component\DependencyInjection\Container::make)
5 /var/www/builds/sitename/sitename-263/vendor/symfony/dependency-injection/Container.php:212 (Symfony\Component\DependencyInjection\Container::get)
4 /var/www/builds/sitename/sitename-263/vendor/symfony/framework-bundle/FrameworkBundle.php:101 (Symfony\Bundle\FrameworkBundle\FrameworkBundle::boot)
3 /var/www/builds/sitename/sitename-263/vendor/symfony/http-kernel/Kernel.php:131 (Symfony\Component\HttpKernel\Kernel::boot)
2 /var/www/builds/sitename/sitename-263/vendor/symfony/http-kernel/Kernel.php:192 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
0 public/module.php:14 (N/A)

I'm also seeing the same error as #31.

#31 here as well

Unfortunately, I could not find a working solution for D10, tried several direct commits combination for simplesamlphp/simplesamlphp and simplesamlphp/saml2 and we encountered other errors besides the one mentioned in #31.
As the problem itself goes beyond what this module does, I ended using (successfully) the alternative module:
https://www.drupal.org/project/samlauth →

I am experiencing the same error as mentioned in issue #31. At first, I thought that locking the dependent projects by using the following Composer command would resolve the issue:

composer require simplesamlphp/simplesamlphp:dev-master#7b69799 simplesamlphp/simplesamlphp-module-adfs:dev-master#62f4d63 simplesamlphp/saml2:^4.6

However, unfortunately, Composer is not cooperating, and the problem persists. It is clear that this situation requires further attention and effort to resolve.

#31 here as well

For anyone struggling with #31 issue you can try simplesamlphp_saml2_d10_container_singleton.patch.
I wrote this when troubleshooting the same problem, and I took the logic from previous working version. I assume there might be some way to instantiate the class before the check is made that now throws an exception, but I haven't used this that much to be sure.

Related to #39.

I also use simplesamlphp_auth_d10_redirect.patch in our D10 branch. Currently I have these patches for saml projects:

   ...
      "drupal/simplesamlphp_auth": {
        "Custom patch for D10 compatibility - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.patch",
        "Custom patch for D10 compatibility - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility_14.patch",
        "RedirectResponse fix for D10 compatibility": "patches/simplesamlphp_auth_d10_redirect.patch"
      },
      "simplesamlphp/saml2": {
        "Custom patch for d10 Container fix": "patches/simplesamlphp_saml2_d10_container_singleton.patch"
      },
   ...

With these I can login using OKTA, but then I get redirect to https://__URL__/saml/module.php/simplesaml/sp/saml2-acs.php/__SP__ which simply shows

File not found.

__URL__ and __SP__ are different per project, so these I have omitted.

I will try to check our current login process with d9 to see what's missing for proper redirect.

@tadas.rimkus I tried to applied your patches as follows:

"drupal/simplesamlphp_auth": {
"Custom patch for D10 compatibility - 3349278_documentation_19": " https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.... → ",
"Custom patch for D10 compatibility - 3349278-d10-compatibility_14": " https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility... → ",
"RedirectResponse fix for D10 compatibility": " https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_re... → "
},
"simplesamlphp/saml2": {
"Custom patch for d10 Container fix": " https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_c... → "
}

The result is a different error:
TypeError: SimpleSAML\SAML2\AuthnRequest::setNameIdPolicy(): Argument #1 ($nameIdPolicy) must be of type ?SimpleSAML\SAML2\XML\samlp\NameIDPolicy, array given, called in /var/www/builds/lab/lab-169/vendor/simplesamlphp/simplesamlphp/modules/saml/src/Message.php on line 490 in SimpleSAML\SAML2\AuthnRequest->setNameIdPolicy() (line 321 of /var/www/builds/lab/lab-169/vendor/simplesamlphp/saml2/src/SAML2/AuthnRequest.php).

I checked and my version still expects array, so it is likely you have saml2 at different version. These are composer.json related to saml we have:

    "drupal/simplesamlphp_auth": "^4",
    ...
    "simplesamlphp/saml2": "^5@alpha",
    "simplesamlphp/simplesamlphp": "dev-master#8c6ee7dd6a6",
    "simplesamlphp/simplesamlphp-module-adfs": "dev-master@dev",

@tadas.rimkus I just found out that simplesamlphp/saml2 has to be version simplesamlphp/saml2:v5.0.0-alpha.6 for it to work.
I'm using your patch suggestions here.

Unfortunately, the patch provided in comment #39 does not resolve the issue for me, even though I diligently followed the instructions mentioned in comment #42 and comment #43.

These are the entries related to simplesamlphp in my composer.json file:

    "drupal/simplesamlphp_auth": "^4",
    "simplesamlphp/saml2": "5.0.0-alpha.6",
    "simplesamlphp/simplesamlphp": "dev-master#8c6ee7dd6a6",
    "simplesamlphp/simplesamlphp-module-adfs": "dev-master@dev",
    "simplesamlphp/simplesamlphp-module-logpeek": "^1.0",

@Rishi could you try with all of the patches:

"drupal/simplesamlphp_auth": {
"Custom patch for D10 compatibility - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19....",
"Custom patch for D10 compatibility - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility...",
"RedirectResponse fix for D10 compatibility": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_re..."
},
"simplesamlphp/saml2": {
"Custom patch for d10 Container fix": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_c..."
}

@Johan den Hollander, thank you for recommending the implementation of all the patches. simplesamlphp_auth is making progress, but unfortunately, I am still unable to log in. I'm encountering an error message stating, "Oops! An Error Occurred The server returned a "500 Internal Server Error". Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused."

Here are the entries, that I have related to simplesamlphp in my composer.json file.

"require": {
   "drupal/simplesamlphp_auth": "^4",
    "simplesamlphp/saml2": "5.0.0-alpha.6",
    "simplesamlphp/simplesamlphp": "dev-master#8c6ee7dd6a6",
    "simplesamlphp/simplesamlphp-module-adfs": "dev-master@dev",
    "simplesamlphp/simplesamlphp-module-logpeek": "^1.0",
    "simplesamlphp/simplesamlphp-module-rfs": "^1.0",
    "simplesamlphp/simplesamlphp-module-yubikey": "dev-master#d7c939d",
}
"patches": {
    "drupal/simplesamlphp_auth": {
        "4.0.0-alpha1 release compatible with D10/Symfony6 - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.patch",
        "4.0.0-alpha1 release compatible with D10/Symfony6 - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility_14.patch",
        "4.0.0-alpha1 release compatible with D10/Symfony6 - RedirectResponse fix for D10 compatibility": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_redirect.patch"
    },
    "simplesamlphp/saml2": {
        "4.0.0-alpha1 release compatible with D10/Symfony6": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_container_singleton.patch"
    }
}

Anything in the Drupal logs? Or maybe you have access to the PHP / Apache logs on the server to see what is logged with this 500 error.

I managed to successfully login using OKTA today after doing some heavy debugging past few days. What I can recommend if you're stuck with 500 and not sure what the actual error is - enable xdebug and start debugging from module.php:
- make sure it goes through module.php and then step into whichever processes it goes
- on exception check trace and find which part threw an exception, and fix that part

Here's a list of potential problems (I had these happening locally):
- you need to add new key 'new_privatekey' - see 'privatekey' and you can use the same value
- configure 'trusted.url.domains' or regex to have a valid domain
- if you use docker, you might get incorrect url (i.e. https://yoursite.com:80 ) - dirty fix for this is adding $_SERVER['SERVER_PORT'] = 443; to module.php after imports.
- baseurlpath change from saml to simplesaml - I changed this in 2 places, I had to link to a different folder locally. This howerver might not be needed, I have this change for a long time. Below is modified snippet from local_install.sh from simplesaml:

# Symlink docroot saml to vendor simplesaml public.
docroot_link="${current_dir}/docroot/saml"
second_docroot_link="${current_dir}/docroot/saml"
if [[ ! -L "${docroot_link}" ]]; then
    echo Creating symlink from docroot simplesaml to vendor simplesaml www
    ln -fs "../vendor/simplesamlphp/simplesamlphp/public" "${docroot_link}"
    ln -fs "../vendor/simplesamlphp/simplesamlphp/public" "${second_docroot_link}"
fi

- decoding failure - this can happen if saml secrets are misconfigured. I had an issue where my secret/adminpass was not used correctly, and I kept getting stuck on decoding failure

Failure decrypting Data (openssl private) - error:02000079:rsa routines::oaep decoding error

. After using correct saml pem/crt secretsalt and auth.adminpassword.

I hope this helps anyone still struggling with 500 error.

I have now updated packages to include

simplesamlphp/saml2:v5.0.0-alpha.8

to avoid needing to patch assert from v6, but this needs additional simplesamlphp_d10_nameidpolicy_fix.patch to work. I will attach it here, it includes:
- module.php update for https port fix.
- NameIDPolicy fix
- trusted regex logic update to support using regular expressions

Here is the current relevant snippets from composer.json

"require": {
    ...
    "drupal/simplesamlphp_auth": "^4",
    ...
    "simplesamlphp/saml2": "^5@alpha",
    "simplesamlphp/simplesamlphp": "dev-master#8c6ee7dd6a6",
    "simplesamlphp/simplesamlphp-module-adfs": "dev-master@dev",
    ...
}
"extra": {
    "patches": {
        ...
      "drupal/simplesamlphp_auth": {
        "Custom patch for D10 compatibility - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.patch",
        "Custom patch for D10 compatibility - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility_14.patch",
        "RedirectResponse fix for D10 compatibility": "patches/simplesamlphp_auth_d10_redirect.patch"
      },
      "simplesamlphp/saml2": {
        "Custom patch for d10 Container fix": "patches/simplesamlphp_saml2_d10_container_singleton.patch"
      },
      "simplesamlphp/simplesamlphp": {
        "Custom patch for d10 NameIDPolicy fix": "patches/simplesamlphp_d10_nameidpolicy_fix.patch"
      }
    }
}

Tadas.rimkus,

Your custom patches, did you create issues for those at simplesamlphp github?

I haven't made any issues there yet, I only updated to v8 on Friday, but I will make one later if there isn't anything related.

Thanks for the patches, I am currently still running into the below error after logging in on the redirect back from authentication.

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
2 public/_include.php:28 (SimpleSAML_exception_handler)
1 /mnt/www/html/njcourtsreview/vendor/symfony/error-handler/ErrorHandler.php:537 (Symfony\Component\ErrorHandler\ErrorHandler::handleException)
0 [builtin] (N/A)
Caused by: Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "debug.error_handler_configurator".
Backtrace:

I've included the below patches:

            "drupal/simplesamlphp_auth": {
                "4.0.0-alpha1 release compatible with D10/Symfony6 - 3349278_documentation_19": "https://www.drupal.org/files/issues/2023-04-05/3349278_documentation_19.patch",
                "4.0.0-alpha1 release compatible with D10/Symfony6 - 3349278-d10-compatibility_14": "https://www.drupal.org/files/issues/2023-04-04/3349278-d10-compatibility_14.patch",
                "4.0.0-alpha1 release compatible with D10/Symfony6 - RedirectResponse fix for D10 compatibility": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_auth_d10_redirect.patch"
            },
            "simplesamlphp/saml2": {
                "4.0.0-alpha1 release compatible with D10/Symfony6": "https://www.drupal.org/files/issues/2023-06-17/simplesamlphp_saml2_d10_container_singleton.patch"
            },
            "simplesamlphp/simplesamlphp": {
                "Custom patch for d10 NameIDPolicy fix": "https://www.drupal.org/files/issues/2023-06-23/simplesamlphp_d10_nameidpolicy_fix.patch"
            }

Package Verisons:

        "drupal/simplesamlphp_auth": "^4",
        "simplesamlphp/saml2": "v5.0.0-alpha.8",
        "simplesamlphp/simplesamlphp": "dev-master#8c6ee7dd6a6",
        "simplesamlphp/simplesamlphp-module-adfs": "dev-master@dev",

@Johan I have made a PR to simplesaml/saml2 for container patch, but I did not make a patch for simplesamlphp/simplesamlphp because I noticed that it uses locked saml2 at alpha.6. I'll have to check more and maybe try alpha.6 again, or try to discuss that in an issue first.

@j-barnes The error you're having is related to symfony configuration - I have not encountered this problem before, but I saw it in framwork-bundle, and I have framework-bundle locked at ^6.3.0 and more precisely at this commit

https://github.com/symfony/framework-bundle/commit/4e082c10ae0c8b80e3290...

I suggest trying to update symfony packages if they are behind, maybe this will help.

I just read through the entire issue to get a sense of what is next for D10 support. It sounds like it _might_ already be possible using the dev branch of this module and various versions of vendor dependencies. I'm mainly basing my thoughts on the discussion way back in #20-#30. Can we get an IS update and if dev branch _does_ support Drupal 10, can we get a tagged release of this module and add to the release notes how to use it with Drupal 10? :pray:

My experience is #49 does work. I can spin up a D10 site and authenticate using the simplesamlphp_auth module.

I would say the current issue is (at least in our case) is the current version of simplesamlphp/simplesamlphp requires a specific commit version (dev-master#8c6ee7dd6a6). This only works in Composer when set at the root level, and our situation has the module installed in a custom install profile. Because of this, we either need to update the "Custom patch for d10 NameIDPolicy fix" patch each time a new update is pushed to simplesamlphp dev and use dev-master@dev, or wait for the patch to be implemented.

BUT, again, I am able to authenticate using the setup in #49 in a test instance.

Looks like 2 days ago there was an update to tvdijen/ws-security that locked a saml2 version that breaks the composer dependencies and causes #49 to stop working. I don't see versioning on that dependency any thoughts? Seems like this is a constantly moving target.

> Seems like this is a constantly moving target.

Yes, it is exactly that. dev-master is the upcoming, active development branch of simplesamlphp. Until things settle down on their side (meaning we get a tagged release like an alpha that we can rely on), do not expect a tagged release of this project, it is futile as the last few weeks have shown. And there is currently no roadmap or communication from the simplesamlphp team on when exactly that will be (https://github.com/simplesamlphp/simplesamlphp/projects/6 is empty).

If you only need the service provider integration, you could consider using an alternative solution like https://www.drupal.org/project/samlauth → . I have not yet evaluated myself if it offers similar functionality and flexibility, but I do plan to do when I upgrade the single project that I'm using simplesamlphp_auth for. And if my evaluation of that is successful, then I will likely step down from maintaining this project (as the currently only kinda-active maintainer).

I know others have closed issues as duplicate of this, but I would actually suggest to reopen a separate issue for the current patches/fixes here, then we can commit those and close that issue and use this issue to try and keep track of upstream changes.

What would also be useful would be to update the issue summary with the current installation instructions and patches, instead of just adding new comments. Everyone can edit that.

Can we use https://www.drupal.org/project/samlauth → as replacement of this module. Is it providing similar functionality as the simplesamlphp_auth?

I see a forked version also available https://packagist.org/packages/utexas/simplesamlphp_auth which is compatible with D10

See #57. As asked there, please update/create a separate issue with the patches for this module (the following two patches are for simplesamlphp itself).

The fork is from mark_fullmer and hasn't been updated in 2 months, that will have exactly the same problems as this issue, the only change there is that they do some trickery with composer dependencies, probably in combination with local version definitions in their composer.json.

Confirming what Berdir said in #62 about utexas/simplesamlphp_auth. This is a fork which switches the dependency from simplesamlphp/simplesamlphp to utexas/simplesamlphp, which is itself a fork of the SimpleSAMLphp library, and changes the version constraint for simplesamlphp/saml2, as well as a few other things. Our team cannot commit to formally supporting this for the community; it is meant as a temporary solution until things change with the SimpleSAMLphp library, or until we've been able to switch to a different solution such as https://packagist.org/packages/utexas/simplesamlphp_auth, which depends on the OneLogin module.

I can install SimpleSamlPHP but then I am getting this error - "READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion.". Any solution of how to fix it?

Thanks

Our use case is like below:
we have multisite setup
One site will work as SP for remote IDP like Azure Active Directory and this site will work as an IDP for rest of the sites.

For first part we can use saml_auth module. but for IDP we need to look for any other approach. Any suggestion for best approach for this Setup?

#64: These are tables from the simplesamlphp project, not this module. The only fix is to not put them in the same database, but it shouldn't matter because they are not accessed through the same mysql connection.

We got a comment from the maintainer of simplesamlphp on the https://github.com/simplesamlphp/simplesamlphp/issues/1825

You're already tagging the commit in your composer-file.. Why would you need a version-tag? It doesn't add anything.

It's really unfortunate (to say the least) that Drupal decided to skip the entire Symfony 5.4 LTS version... I get that it is an issue for you, but we follow Symfony LTS and do not have the capacity to keep up with the latest/newest stuff of everything in the ecosystem that relies on SimpleSAMLphp. Symfony 5.4 is supported until Nov '25, so we really have no incentive to rush things..

From the same issue, it seems there's going to be a version with symfony 6 dependencies:

The reason for this was carrying over 10 years of legacy and technical debt and not enough human resources.. We will not let that happen again.

Somewhere over the next couple of days we will be releasing v2.1 with bumped dependencies for PHP (8.0) and Symfony (6).

Yes I think 2.1 version will release in next few days. then we can expect some alpha release of this module.

We got comment on above issue

You can test-drive the simplesamlphp-2.1 release branch. If no issues show up in the next days I'm tagging a release

I was trying to test this branch locally but due to composer dependecies of simplesaml_auth I could not able to install this branch

I think simplesamlphp-2.1 is having only synfony 6 dependencies which mean we cant test this branch in D9

That may be true, but it will be an upgrade path, and due to similar code dependencies, other Drupal modules also require Drupal 10 for the upgrade. Testing could be done on a dev or test site beforehand.

yes correct this will be drupal 10 only release

Hi All, when are we planning to release Drupal 10 compatible version for this module ?

@hkumar4 we need to do testing the simplesamlphp-2.1 branch of simplesamlphp library with 4.x branch of this module. then we can ask maintainer of simplesamlphp library to create release from that supported branch

@nitesh624 i have an online development environment that I can use to test this in a close-to-production arrangement. should I ignore composer, and attempt to run this module with the 2.1 branch all installed manually?

If not, what is the best way to do this testing?

Hello, I'm also using drupal/simplesamlphp_auth: ^4 for my site running in Drupal 10.

However, I encountered this problem:
Uncaught PHP Exception Error: "Typed property SimpleSAML\Session::$trackid must not be accessed before initialization" at vendor/simplesamlphp/simplesamlphp/src/SimpleSAML/Session.php line 570

anyone who also encountered the same?

The last commit to 4.x for the module was 6 months ago. https://git.drupalcode.org/project/simplesamlphp_auth/-/tree/4.x?ref_typ...

The composer.json says to use dev-master but the simplesamlphp branch that needs testing is 2.1.

It would probably be best to work from the open MR to change requirements for 4.x to Drupal 10 and simplesamlphp branch 2.1. So something like this:

    "require": {
        "drupal/externalauth": "^2.0",
        "simplesamlphp/simplesamlphp": "simplesamphp-2.1",
        "drupal/core": "^10"
    }

https://git.drupalcode.org/issue/simplesamlphp_auth-3349278/-/tree/33492...

In order to use the MR on a project you'll probably need to update your composer.json to use the MR "as" the module instead of downloading the actual Drupal package. The following is off the top of my head and not tested so don't expect it to work without fixing.

    "repositories": [
...
        {
            "name": "drupal/simplesamlphp_auth",
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/simplesamlphp_auth-3349278.git"
        },

...

    "require": {
        "drupal/simplesamlphp_auth": "4.x as 4.0.0-alpha2",

@nitesh624 we can test it. It will take us a bit to set up because we have to coordinate with the IAM team for our organization. I will post our results here.

The forked repository here doesn't actually contain anything, so that's a pretty pointless exercise right now.

Again, to help bring this forward, I recommend that someone starts a merge request, preferably in a separate, more focused issue that updates composer.json to allow dev-simplesamlphp-2.1 to actually make that installable. All the other patches to this module and simplesamlphp itself might or might not be needed then, we'll have to figure that out. Once they actually create a tagged release, we can then likely update that to ^2.1 (it would be easier if they'd follow common conventions around development branches or have branch aliases).

Testbot should be able to handle that as well and we should be able to run tests against that branch.

I'm not super confident I did this correctly, can someone else review this patch and continue discussion or open a merge request in the new issue? 📌 Support SimpleSAMLphp 2.1 release Fixed

Not sure another issue was necessary since if this issue's MR is empty then we could have just applied the updated dependencies on this MR. But it's open now so let's try to make the scope of the new issue very narrow to ensure that the updated dependency becomes module version 4.0.0-alpha2 for testing. Continuing work there.

I still have the compatibility problem, I can't install simplesamlphp/simplesamlphp dev-master because it requires the
symfony/psr-http-message-bridge ^2.3, however Drupal 10.1 requires symfony/psr-http-message-bridge ^2.1. Does anyone have a solution for this?

Refer to the child issue 📌 Support SimpleSAMLphp 2.1 release Fixed that was just opened; we're targeting what will become the 2.1 release of SimpleSamlPHP, so don't expect the module current alpha to work off the library's master branch. You'll need to use the open merge request until it get merged and tagged as a new alpha.

Per the child issue, Berdir updated 4.x-dev → to support the simplesamlphp 2.1 RC, so the 4.x-dev version of the module should now properly install on Drupal 10 for alpha testing purposes only. Do not expect it to work OOTB or in production environments, and please report any issues.

4.x-dev still requires dev-master not 2.1.

If you were using the MR from the child issue to your composer.json you will need to remove the reference to it. I saw the same issue with trying to grab 4.x with composer require until I removed it.

Delete this from your "repositories":

        {
            "name": "drupal/simplesamlphp_auth",
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/simplesamlphp_auth-3380262.git"
        },

@caesius good catch! That worked! Thank you!

Just an update on our testing. There were a couple of bugs with the dedicated metadata URL. Those have been fixed. We are waiting for our IAM team to set up or test site with their test IdP with he updated metadata to complete testing. I will update this thread once that is complete.

We just tested the 4.x-dev version without any patches and it works without any issues with Drupal 10.

I've tested the 4.x-dev version with the following patches against a Drupal 9 site:

• "Issue #2940967: Allow drush uli logins": "web/profiles/contrib/houston/patches/upstream/2940967-allow-drush-uli-login.patch"
• "Issue #3332611: Saving a user overrides the authname": "web/profiles/contrib/houston/patches/upstream/3332611-4.diff"

Everything works as expected.

Just for clarification, installing 4.x-dev on a Drupal 9 site should be absolutely no different from installing 3.x-dev, as the only difference is updated dependencies to support Drupal 10. On Drupal 9 it will still use the same dependencies as before i.e. simplesamlphp:^1.19 since D9 would not be able to install the 2.x simplesamlphp library.

This update really needs to be tested in Drupal 10 to confirm that it's working. If it doesn't, it will need to then be narrowed down to an issue in the module or an issue in the library. The simplesamlphp maintainer hasn't officially released 2.1 yet because they need confirmation that it works.

I have just tested the following:

Drupal: 10.1.2
PHP: 8.1.16
simplesamlphp_auth: dev-4.x
simplesamlphp/simplesamlphp: dev-simplesamlphp-2.1

I was able to successfully authenticate, and was able to set up the simplesamlphp attribute mapping for automatic role assignment without a problem.

This seems to work as expected without PHP errors/warnings/notices.

Unrelated to the Drupal side of things, the simplesaml admin UI stuff all worked as expected as well.

I'm going to move this to RTBC as it appears we have two confirmations now of successful tests in D10, this one and #91.

Any update on when are we planning to release the alpha version of this module which is Drupal 10 compatible ?

Reporting another successful result with current dev-4.x and Drupal 10.1.2.

One detail: about configuration of entityID, we previously had:

        // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
        'entityID' => NULL,

It seems the NULL/undefined option is no longer supported - to achieve the same result, I needed to change that to:

        // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
        'entityID' => "https://{$_SERVER['HTTP_HOST']}:443/simplesaml/module.php/saml/sp/metadata.php/default-sp",

A release is planned when there is any kind of tag/release for 2.1 on the simplesamlphp project, see https://github.com/simplesamlphp/simplesamlphp/issues/1825.

Testing on a Sandbox SAML IpD that requires either SmartcardPKI or TimeSyncToken for authentication. No patches tested (yet). Testing with:

PHP 8.1.22
Drupal 10.1.2
simplesamlphp_auth: 4.x-dev
simplesamlphp/simplesamlphp: dev-simplesamlphp-2.1

Good News: installed cleanly once our System Administrators added the ext-intl extension to PHP, so that part went fairly well.

Bad News: not able to successfully authenticate due to problems with the NameIDPolicy Format. It seems to always revert to "transient" no matter what we input in authsources.php (we're required to use "persistent").

Is anybody else able to get that to attribute to change (without the patch)?

@slpearce could you clarify what patch you're referring to and link to where you found it? Is it a patch for the Drupal module or for the simplesamlphp library? If it's for the library then you should follow up in their issue queue. https://github.com/simplesamlphp/simplesamlphp/issues

@caesius, I was referring to the 'simplesamlphp_d10_nameidpolicy_fix.patch' patch referenced by @tadas.rimkus in #49, which may or may not still be needed... Not sure if that ever made it into the issue queues for simplesamlphp/simplesamlphp or simplesamlphp/saml2...

Update: I can now confirm that this works on our Sandbox setup for Drupal 10. The issue I ran into with the NameIDPolicy turned out to be caused by an unrelated proxy setting.

Once that was corrected, the rest went smoothly. No patching needed, as previously suggested in various issues above. At least, not for my setup.

We have this working on a multisite setup in Acquia Site Cloud Factory. Thank you all for your work on this. There was only one change we needed to make . . . we had a symlink to ../vendor/simplesamlphp/simplesamlphp/www that needed to be updated to ../vendor/simplesamlphp/simplesamlphp/public. Minimal tests confirm login is working on the sites, role syncing and masquerade is working. I mention the last two as we have patches for that functionality and they are not affected by the update and still apply.

Again - thank you to everyone that has worked on this. Looking forward to getting into D10!

Hi, same result as pbabin, it works perfectly for me (I used simple saml with google suite and azure directory in my case drupal 10.1)
I had just to change the path to simplesaml www to public (because of simplesaml php upgrade).

Maybe just a mistake of me, the following hook doesn't seem to be invoked when a user succeeded to connect with simplesaml:
"hook_simplesamlphp_auth_user_roles_alter"
I named correctly the hook with my module name, even die() into the hook, it wasn't invoked.
I used the hook "hook_simplesamlphp_auth_user_attributes" to add role instead (already used to add attributes to user entity).

Thanks for this work !

I have just tested the following, on Pantheon with Ping Federated:

Drupal: 10.1.3
PHP: 8.2.10
MariaDB: 10.4.25
NGINX: 1.25.2
Composer: 2.5.5
drupal/simplesamlphp_auth: dev-4.x
simplesamlphp/simplesamlphp: dev-simplesamlphp-2.1

NO PATCHES APPLIED

I was able to successfully authenticate without issue. However, I'm still getting the Drupal Status Report error: Transaction isolation level.

READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion. See the setting MySQL transaction isolation level page for more information.

@esch you have the simplesamlphp tables in the same database as Drupal. That is not necessary, so if you would put those in a separate database you can get rid of this warning / error.

@johan-den-hollander thanks for the quick reply.

Unfortunately, we are on Pantheon. They don't allow additional DBs(https://docs.pantheon.io/guides/platform-considerations/platform-site-in...) or support third party hosted DBs. Thus our stuff has to go into the Drupal DB.

cheers,
matt

I'm in the same situation as @esch regarding #104. My org runs Drupal websites at Pantheon and I have a D10 site there that's now using the same set-up for D10, simpleSAMLphp_auth, and SimpleSAMLphp as listed in #104. I'm also seeing the same error regarding the READ-COMMITTED transaction isolation level.

Both of those tables have a unique key that does not allow NULL values, so I changed them to primary keys as a test. So far, I'm seeing no problems with my ability to authenticate to the site.

Does anyone see a reason not to request that the SimpleSAMLphp maintainers change these keys to primary for the 2.1 release?

> Does anyone see a reason not to request that the SimpleSAMLphp maintainers change these keys to primary for the 2.1 release?

I very much doubt that will happen for the 2.1 release, but yes, we can't do anything about that, there is the only place you can ask for a change.

That said, I'm not sure if it matters at all. Those tables are read through a different database connection that won't use the same isolation level, Drupal just doesn't know that. It's just a reporting thing. You could create a core issue to allow setting a flag to ignore certain tables or something.

Thanks @Berdir for the explanation that the READ-COMMITTED isolation level for the Drupal database connection isn't being compromised. That's my main concern, given that the default isolation of REPEATABLE READ has been reported to cause deadlocks on tables that can lead to site performance problems.

I'll add a comment to the SimpleSAMLphp issues thread about this in case the maintainers are able at some point to change the table keys.

Thanks again.

Coming into this late... I can require ^4.0 with Composer, which of the patches listed are required? All? Some?

@kevinquillen, I think the only way to get it to work at the moment is to composer require drupal/simplesamlphp_auth:^4.0@dev. That worked for us, but I'm keen to see the full release sooner than later as I don't like pinning to a dev commit when I can avoid it.

On an old project the 4.x version causes the following error:

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
1 public/_include.php:28 (SimpleSAML_exception_handler)
0 [builtin] (N/A)
Caused by: Symfony\Component\Finder\Exception\DirectoryNotFoundException: The "/var/www/mysite/docroot/vendor/symfony/validator/Resources/translations" directory does not exist.
Backtrace:

This is due drupal/core-vendor-hardening that removes the Resources folder from symfony/validator.

As is quite standard to have now the composer/vendor folder inside the webroot, and thus not having the necessity of drupal/core-vendor-hardening, I don't think it's really necessary to document this issue, but at least there's this comment if someone else is going to have this problem.

Does anybody know when there will be a stable D10 compatible release ?

We currenly can not move forward to D10 because of this module only.

Thanks in advance.

A bug we spotted going from 3.2 to 4.x-dev is the one reported in this issue: saving a user overrides the authname 🐛 Saving a user overrides the authname Needs review

If something else can replicate it, I'd say it's a major regression because it can easily break the authentication for existing user and it can be fixed only with a query to the datatabase.

To reiterate, a stable 4.x release of this module is waiting on the simpleSAMLphp library releasing a stable 2.1 version. The library maintainer is waiting for internal review amongst their colleagues for the outstanding pull requests; there is nothing we can do to speed it along.

Until then, the 4.x-alpha release should be usable on Drupal 9 with version 1 of the library, but upgrading to Drupal 10 would need to use the currently-in-development 2.1 version of the library. The module itself is otherwise identical, aside from 4.x-alpha allowing for the 2.1@dev library version and including D10 considerations, and per previous comments may work fine on both D9 and D10 (with no guarantees).

Refer to the diff for more information.

Hopefully these IS changes will help in getting newcomers up to speed quickly.

@caesius - thanks for the link to the diff. That is extremely helpful.

For anyone considering other options, we've been testing a standalone implementation of SimpleSAMLphp 2.0 (stable version) in conjunction with the 4.x-dev branch of this module. That allows SimpleSAMLphp to run a different version of Symfony and sidesteps certain conflicts. Similar to the Drupal 7 approach. We had to make some awkward changes to our CI/CD processes to get that to work on our Sandbox, and I don't love it as a solution. But it does appear to work (if you have the ability to modify server configuration and create symlinks).

@giuseppe87 I've replicated the Saving a user overrides the authname 🐛 Saving a user overrides the authname Needs review issue from 3.2. But I've found that patch #4 from that issue still works on 4.x-dev.

The linked issue re: overriding the authname links to an issue in the externalauth module describing a change in that module's behavior. If you updated the externalauth module at the same time as updating this module to 4.x-dev, then the issue you encountered is due to updating that module, not this one.

Please continue discussion regarding this issue in 🐛 Saving a user overrides the authname Needs review since it seems to be unrelated to the 4.x version.

+1 for Drupal 10 compatibility

It's almost there the simpleSAMLphp library released the https://github.com/simplesamlphp/simplesamlphp/releases/tag/v2.1.0-rc1

Since a release candidate is available, we can now just require simplesamlphp/simplesamlphp:"^1.19 || ^2.1" and drop dev-simplesamlphp-2.1, assuming 2.1-rc1 is still chugging along fine.

Also, since it seems people are currently using the 4.x-dev branch, we may want to just release this as 4.0.0-alpha1 with the intention of fully releasing 4.0.0 once 2.1.0 is available. Anyone updating this module for Drupal 10 compatibility would need to upgrade the simplesamlphp library and externalauth modules by major versions anyway.

Tested as working, after adding the 'entityID' param.

Here we go: https://www.drupal.org/project/simplesamlphp_auth/releases/4.0.0-rc1 → .

Note that testing has been switched to GitlabCI, which provides a workaround for the composer plugin issue that prevented testing on DrupalCI. Any further contribution to this project must go through merge requests.

Tested https://www.drupal.org/project/simplesamlphp_auth/releases/4.0.0-rc1 → in a project. Worked for me.

This appears to be working for me as well, but I think I'm using 4.x-dev instead of 4.0.0-rc1. However, when I try composer require 'drupal/simplesamlphp_auth:^4.0@RC' nothing gets updated, so I guess I'm using the right version? I don't see a version number in 'admin/extend'.

Hi guys, thanks all for your hard work getting this Drupal 9/10 compatible. Just in time!

I have a question. We are using acquia/blt-simplesamlphp:1.0.0 which we used to load the config into our Acquia Cloud. This module requires simplesamlphp_auth:^3.0 thus cannot use the 4.0 version. Is there anything I can do to get around this e.g. loosening the restrictions somehow or overwriting this require from this module?

Currently we are on core 9.5.10 and want to use simplesamlphp_auth:4.x with simplesamlphp:^1.19. From what I can tell it should work but probably will stop working on simplesamlphp:^2 due to the directory (www->public) changes which I understand.

Thanks in advance.

@simon2d I just did that yesterday and I’m going to write up a blog post about it. I’m on vacation now though. I can send you my rough notes later.

@simon2d, you don't have a contact form on your profile. Sorry for the extra content here for those who don't these this info. For those using the blt-simplesamlphp plugin, here are basic steps to be able to update:

Copy the vendor/acquia/blt-simplesamlphp/src/Blt/Plugin/Commands/SimpleSamlPhpCommand.php
to your root blt/src/Blt/Plugin/Commands/SimpleSamlPhpCommand.php

Change the namespace of the command to the name space of your Blt commands. You must have your composer set up for defining the psr-4 autoload namespace. See also: https://docs.acquia.com/blt/extending-blt/

Remove the protected $pluginRoot variable at the beginning of the class and in the initialize function. Change instances of pluginRoot to repoRoot.

Update according to phpcs as it may be out of date with current standards.

Copy vendor/acquia/blt-simplesamlphp/scripts directory to root of your repo.

Thanks very much @shelane for your help. I will test and let you know how this works out.

I also observed simplesamlphp_auth can require either simplesamlphp:^1.19||^2.1

Is there a specific reason for this? Will I need to use ^2.1 for drupal 10?

1.19 is for Drupal 9, 2.1 for Drupal 10. If you don't specify an explicit dependency yourself, it will automatically pick the compatible version.

About #64 and #66:
I have searched how move the SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion in another database, but couldn't find documentation or configuration to do so, in order to avoid the

"READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: SimpleSAMLphp_saml_LogoutStore, SimpleSAMLphp_tableVersion."." error

Granted that isn't really a problem, does someone know how move those tables? Thanks

SimpleSAMLphp's session store database connections are all in its $config['store*'] values, which are documented in its example configuration.

🐛 This module prevents Drupal from installing from configuration RTBC could be something that is needed in 4.0.0@stable (next RC), see the 2nd comment in the issue,

@Giuseppe87, regarding #133 📌 4.0.0-alpha1 release compatible with D10/Symfony6 Fixed , I submitted code to the SimpleSAMLphp project that is now part of the 2.1 release that will add primary keys to the SimpleSAMLphp_saml_LogoutStore and SimpleSAMLphp_tableVersion tables and thus eliminate the error. The SimpleSAMLphp update code will run upon your first SAML-based login and add the keys. Commit is at here.

@josiahcavitana To solve this PHP 8.1 error with the trackid property, you have to edit vendor/simplesamlphp/simplesamlphp/src/SimpleSAML/Session.php file and change...

private string $trackid;

...with...

private string $trackid = '';

After upgrading I'm seeing this error:

Fatal error: Uncaught SimpleSAML\Assert\AssertionFailedException: Expected a callable. Got: array in /var/www/vendor/simplesamlphp/assert/src/Assert.php:364 Stack trace: #0 /var/www/vendor/simplesamlphp/simplesamlphp/src/SimpleSAML/Error/Error.php(264): SimpleSAML\Assert\Assert::__callStatic('isCallable', Array) #1 /var/www/vendor/simplesamlphp/simplesamlphp/src/SimpleSAML/Error/ExceptionHandler.php(33): SimpleSAML\Error\Error->show() #2 [internal function]: SimpleSAML\Error\ExceptionHandler->customExceptionHandler(Object(SimpleSAML\Assert\AssertionFailedException)) #3 {main} thrown in /var/www/vendor/simplesamlphp/assert/src/Assert.php on line 364

Any ideas. I didn't change any of my other configuration.

Hi everyone

Having the same issue mentioned above related to nameidpolicy.

We are running Drupal 10.0.11 with Simplesamlphp_auth ^4

The patch listed above (#49) and fix mentioned specifies using alpha version 5 of simplesamlphp/saml2 however the 2.1 rc1 version of simplesamlphp/simplesamlphp project is locked to saml2 ^4.6

How can we get around this and does anybody have a fix for it?

There has been a lot of discussion around upgrading. However, there was no Drupal Slack channel for SAML. I created a saml_auth channel if anyone cares to join to discuss. I know I'm having issues getting my authentication working with Drupal 10.

Has anyone seen this error when attempting to upgrade to Drupal 10 with SimpleSAMLphp Authentication:

Unable to install module simplesamlphp/simplesamlphp-assets-base, package name must be on the form "VENDOR/simplesamlphp-module-MODULENAME".                                                                                  

I've tried a few ways to upgrade everything at once, but this error keeps cropping up. I would assume that it's an issue with the SimpleSAMLphp library, but when I submitted an issue over there, the first suggestion I got was to upgrade sipmlesamlphp-assets-base before everything else, which I can't seem to make happen due to (at least, but probably not only) conflicting dependencies on psr/log:^3.0 for the simplesamlphp/simplesamlphp:2.1.0-rc1 and Drupal 9.5 limiting support to ^1.1.

So, I know this isn't a problem with this Drupal Module, but does anyone have any suggestions for getting around it?

So, I know this isn't a problem with this Drupal Module, but does anyone have any suggestions for getting around it?

I posted a response to this question in https://drupal.slack.com/archives/C0635298NQ1/p1698250714682619 , per the suggestion from #140

Hi all, currently getting an error running Drupal 10.0.11:
Uncaught PHP Exception TypeError: "SimpleSAML\Utils\Config\Metadata::parseNameIdPolicy(): Argument #1 ($nameIdPolicy) must be of type ?array, bool given, called in /mnt/www/html/company/vendor/simplesamlphp/simplesamlphp/modules/saml/src/Message.php on line 477" at /mnt/www/html/company/vendor/simplesamlphp/simplesamlphp/src/SimpleSAML/Utils/Config/Metadata.php line 250
In our authsources.php file we have
'NameIDPolicy' => false,
I notice there was a lot of discussion previously about nameidpolicy along with a patch, but seems I cannot apply the patch due to version constraints.
Does anybody have a suggestion on how we can resolve this? Thanks

I fixed the above issue by changing value for NameIDPolicy in authsources.php to an empty array:

'NameIDPolicy' => []

I also encountered an issue with entityID. We previously had this set to null but seemed like that isn't possible anymore considering the new authsources template. Instead I updated as follows (taking example from #96 but removing the ports):

Before:

// The entity ID of this SP.
// Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
'entityID' => null,

After:

// The entity ID of this SP.
'entityID' => "https://{$_SERVER['HTTP_HOST']}/simplesaml/module.php/saml/sp/metadata.php/default-sp",

I have now managed to get it working on Drupal 10.0.11 on our develop environment. Thanks for everyones help. I will linger for a bit to see if I can help others.

FYI - as of yesterday, there is now a tagged stable release for simplesamlphp/simplesamlphp version 2.1: https://github.com/simplesamlphp/simplesamlphp/releases/tag/v2.1.0

Did anyone figure out how to fix the trackID error without directly changing the vendor .php file?
Thanks for the fix in #137 📌 4.0.0-alpha1 release compatible with D10/Symfony6 Fixed as it did work.

There may be a config.php or authsources.php parameter that is missing that is causing this?

Automatically closed - issue fixed for 2 weeks with no activity.

hi @simon2d, i applied your steps and simplesamlphp is working on develop server. however it started showing error : Error: Cannot access property starting with "\0" in SAML2\XML\saml\NameIDType->__unserialize() (line 252 of /storage/www/www/lib-reimagined-9/vendor/simplesamlphp/saml2/src/SAML2/XML/saml/NameIDType.php).

Did you get this error. I am getting this error on our QA server.

Did anyone face this issue?

@chdeepak Referring to comment #150
I am facing the same issue message: 'Error: Cannot access property starting with "\0" in SAML2\XML\saml\NameIDType->__unserialize() (line 252 of /var/www/html/vendor/simplesamlphp/saml2/src/SAML2/XML/saml/NameIDType.php).'

After Drupal10.2.3-
Drupal module - drupal/simplesamlphp_auth v4.0.0
simplesamlphp/simplesamlphp v2.1.3

Error: Cannot access property starting with "\0". ... issue appears to be related to the update of simplesamlphp/saml2 to 4.6.11. See https://github.com/simplesamlphp/saml2/compare/v4.6.10...v4.6.11. Try going to 4.6.10.

@chdeepak @ anand.panure... this is related to simplesamlphp/saml2 changes on 4.6.11. https://github.com/simplesamlphp/saml2/compare/v4.6.10...v4.6.11. Try going back to 4.6.10

I'm also seeing the error. Using the 4.6.10 version is working well.
Let's try to fix this in: https://www.drupal.org/project/simplesamlphp_auth/issues/3427576 🐛 Cannot access property starting with "\0" in SAML2\XML\saml\NameIDType->__unserialize() Needs work