If we open a node with comments as anonymous user we will see the links including
the registration link with url: http://web/en/user/register?destination=node/1%23comment-form
User will be redirect back to the node page.

1. You need to drop destination from request or we can send the response instead of passing further
2. You need to take into account "destination" parameter and pass it here
   https://ecas.ec.europa.eu/cas/eim/external/register.cgi?service=

Define and implement what information needs to be rendered about a user by default and how to do so.

Possible scenarios:

• Content author information
• User page

Bulk Add EU Login Users currently allows to specify usernames.

Would it be possible to enter emails that are registered in EU login to become system users?
Also could we use this for creating NEW users in EU Logid Identity Provider in case their email does not exist?

Steps to reproduce:

• Enable oe_authentication with forced login.
• Leave front page as "/user/login" - this is the default from core/modules/system/config/install/system.site.yml.
• Attempt to login as an inactive user, or login with a non-existent user, and have it be auto-created as inactive.

Expected:
Not sure what we expect :)

Actual:
EU Login redirects to frontpage, Drupal refuses to login the inactive user, Drupal redirects back to EU Login, EU Login redirects back to Drupal frontpage, etc.

Workaround:
As a site builder, simply avoid having front page = /user/login.

Solution:
As maintainers of this module, we simply need to push site builders to change the default front page.
Perhaps having this issue here is good enough.

Currently, when a new user is register after a successful EU Login, if the site policy is to require admin approval, the account will be blocked. This should be configurable. For example some projects might consider that users registered via EU Login are safe and there's no need for approval.

Proposal

Add a new setting Block newly created users if the site requires admin approval on new account registering (find a better wording!). This should default to TRUE in order to ensure BC.

Create a new release for the component: 1.0.0-beta1

Remove patch https://www.drupal.org/files/issues/2019-04-12/3047390_2.patch

It has been fixed https://www.drupal.org/project/cas/issues/3047390

This module is removing methods to cancel accounts for most users in a hook. The super user (uid 1) can still chose one of these removed methods.

If the selected method is one of the forbidden ones and users have the permission "Cancel own user account", when a user tries to cancel its account we'll see a PHP error (notice) in dblog reports:

Notice: Undefined index: user_cancel_reassign in Drupal\user\Form\UserCancelForm->getDescription() (line 70 of /var/www/html/build/core/modules/user/src/Form/UserCancelForm.php)

Removing options to cancel accounts like this, in a hook, is already a problem because in some cases sites will want one of them. In ECIF there is an example where this hook was removed in a local patch. In another project we'll need to do this too now.

I don't know the requirements to remove methods and only allow them to the super user.
I can only suggest to rethink the all approach here.

After the latest symfony/http-foundation 3.4.24 update Drupal core has reported an issue with its lazy sessions: https://www.drupal.org/project/drupal/issues/3045349

The current solution is to fix the http-foundation version in te composer.json file:

"conflict": { "symfony/http-foundation": "3.4.24" },

Dears,
EU login and registration is not working. When we try to login using a new user, we are unable to login and getting an error message on the screen attached below.
When we checked admin/people page, we don't see an account created. Expected behavior is account should be created after login and new user should be redirected to registration form.

We are using 1.13.0 version of this module.

Can you please check and help.

The last official release (1.3.0) is now more than a year old and the CAS version is requesting an update which is updated in version 1.4.0 that is in an own branch but hasn't been released to be picked up by composer require as instructed (composer require openeuropa/oe_authentication)

Are there plans to release the next version?

On sites with a big number of users (100K+), the user Drush sanitization function from the oe_authentication_user_fields module is trying to load the entire list of users in memory before sanitizating them and that, in turn, depending on the PHP CLI ram limits, might trigger an Out of memory error.

I would propose to change, in the oe_authentication_user_fields/src/Commands/sql/UserSanitizeCommand.php file, the lines:

$users = $this->entityTypeManager->getStorage('user')->loadMultiple();
 foreach ($users as $user) {

to a more memory conservative way as follows:

    /** @var  \Drupal\Core\Entity\EntityTypeManagerInterface $user_storage */
    $user_storage = $this->entityTypeManager->getStorage('user');

    /** @var int[] $user_ids */
    $user_ids = $user_storage->getQuery()->execute();

    foreach ($user_ids as $uid) {
      /** @var \Drupal\user\Entity\User $user */
      $user = $user_storage->load($uid);

Thank you.

While reviewing #85 I found a dubious section of code in RouteSubscriber::alterRoutes() and no comments are given on why this is needed:

    // Replace the core register route controller.
    $route = $collection->get('user.register');
    if ($route instanceof Route) {
      // ...
    }

Why is it here assumed that RouteCollection::get() would return objects which are not Route objects? If this can happen, why would we ignore this silently?

I see from the definition of \Symfony\Component\Routing\RouteCollection::get() that it only returns Route or NULL:

    /**
     * Gets a route by name.
     *
     * @param string $name The route name
     *
     * @return Route|null A Route instance or null when not found
     */
    public function get($name);

I'm not sure if something came up during testing that necessitated this if statement, but it seems more likely that this is just a mistake and the if statement can be simply removed. If is is necessary then we should have some clear documentation on why this can happen, and a test to prove that we handle the case correctly.

Ref. https://github.com/openeuropa/oe_authentication/blame/master/src/Routing/RouteSubscriber.php#L37

This entire class could use an overhaul by the way, there is almost no documentation, except for some comments that explain what the code is doing, but not why.

When I follow the instructions I get an error regarding missing credentials when docker-compose attempts to download the authentication container:

$ docker-compose pull
Pulling web            ... done
Pulling mysql          ... done
Pulling selenium       ... done
Pulling authentication ... error

ERROR: for authentication  b'Get https://registry.fpfis.tech.ec.europa.eu/v2/ecas-mock-server/manifests/4.6.0: no basic auth credentials'
ERROR: Get https://registry.fpfis.tech.ec.europa.eu/v2/ecas-mock-server/manifests/4.6.0: no basic auth credentials

Can a container be made that mocks the service using open source software so that it can be made publicly accessible? There are many tools available that can be used to easily mock a REST or SOAP service.

Add in the README.md:

• the header of the paragraph concerning Docker.
• More information concerning the private container euLogin.

The core version if fixed to Drupal 8. Do you plat to add support of Drupal 9 ?

Hello,
I can see that a Drupal 8 core version is required for this module to install with composer. Will there be any Drupal 9 version of this module?

Thank you,
gb

Good morning,

I would like to request an update for the openeuropa/oe_authentication module. Recently, a new version to drupal/cas was released (version 2.3.1), but I noticed that openeuropa/oe_authentication still requires the previous version, 2.2.

Therefore, I kindly request that you update the openeuropa/oe_authentication module to make it compatible with the latest version of drupal/cas.

Thank you in advance for your attention, and I look forward to your response.

Best regards,
Cláudia Desidério

In Drush 13.0.0-beta1 there is a change related to SanitizePluginInterface referenced by UserSanitizeCommand.

SanitizePluginInterface and SanitizeCommands are moved to new namespaces.

Error: Class "Drush\Drupal\Commands\sql\SanitizeCommands" not found in /test/toolkit/web/modules/contrib/oe_authentication/modules/oe_authentication_user_fields/src/Drush/Commands/sql/UserSanitizeCommand.php on line 69 #0 /test/toolkit/vendor/consolidation/annotated-command/src/Attributes/Hook.php(30): ReflectionAttribute->newInstance()

Hello, I have a login problem in my local version.
There is error in Drupal log:

Error when validating ticket: Error Code INVALID_USER: Invalid user: "XXXXXXX" belongs to "SELF_REGISTERED" users while application accepts only "INTERNAL" users or users with higher assuresponse received from CAS server:

In settings.php I have
$config['oe_authentication.settings']['assurance_level'] ='LOW';
$config['oe_authentication.settings']['base_url'] = 'https://webgate.ec.europa.eu/cas';

A direct link to the EULogin documentation in the readme would be highly appreciated.
I believe: https://citnet.tech.ec.europa.eu/CITnet/confluence/display/IAM/EU+Login correct?

Also a brief explanation of each setting (at admin/config/system/oe_authentication) such as "Application assurance levels" etc would be sufficient for developers to better understand what each one does.

Hi there,
is there a way to redirected to the user to the user edit page after the very first time login, like on ecas module (D7)?
We need to implement this behavior due to the privacy policy regulations.
Thank you in advance,
Fab

We would like to have those fields in here
https://github.com/openeuropa/oe_authentication/blob/master/oe_authentication.module#L40
to be configurable in both view and form displays

Cannot be installed with current latest Drupal 9 version.
Please update to be compatible with symfony/http-foundation v4.4.44

• openeuropa/oe_authentication 1.8.0 requires symfony/http-foundation <=4.4.41
• latest drupal 9 version of symfony is v4.4.44

When installed, the module creates next base fields for the user entity: field_oe_firstname, field_oe_lastname, field_oe_department, field_oe_organisation. Also, on registering a new Drupal account with data taken from EU Login, it fills those fields with data.

This approach is hard coupled to a specific OE business model, preventing module reusability. The module should not be in business of configuring the user entity fields. That should be deferred to other module, to the parent project or to configuration management (if the fields are converted from base to configurable).

Also there's no way to allow users change data on the site, e.g family name, because everytime they are logging in, data from EU Login is overwriting the local changes.

Proposal

• Stop adding user base fields.
• Use cas_attributes module to map and set fields.

Initially, on Joinup project, we've been developed some code to sync the user's organisation with the EU Login organisation value. However, lately, our PO decided that Joinup users will manage locally their organisation(s) and the field should not be overwritten by the EU Login attribute.

The sync is not straight because EU Login doesn't provide the organisation name, but the organisation domain. So, the name has to be extracted from the ECAS Schema. Also, a mechanism has to be put in place that is caching locally the ECAS Schema, so that a HTTP request on each login is avoided. But, then, the system need to ensure that the local cached schema is periodically refreshed if there are upstream changes. Finally, from all these constraints, resulted some functionality that we had to drop.

We think that, if such a functionality is required for OE Authentication module, the code that we've built (dropped lately) can be easily adapted with minimum effort. The code is contained in the revert commit: ec-europa/joinup-dev@07c5aa6

The CAS module settings are at: /admin/config/people/cas
The OE Authentication settings are at: /admin/config/system/oe_authentication

This is a little bit confusing from a UX perspective, as the 2 modules are very coupled and a site builder would expect to find the settings in proximity.

Proposal

Consider moving OE Authentication settings at /admin/config/people/cas/oe-authentication and add it as tab of the main CAS settings form.

For some reason the module is altering the path of the cas.login route to /eulogin. This is breaking the functionality as documented in the CAS module. There is no value in doing this.

The code responsible for this is as follows, as you can see there is no reason given to explain why this breaking change is required:

  protected function alterRoutes(RouteCollection $collection): void {
    // ...

    // Replace the cas callback route controller.
    if ($route = $collection->get('cas.proxyCallback')) {
      $route->setDefaults([
        '_controller' => '\Drupal\oe_authentication\Controller\ProxyCallbackController::callback',
      ]);
    }

    // Replace default cas login route with eulogin one.
    if ($route = $collection->get('cas.login')) {
      $route->setPath('/eulogin');
    }
  }

Also no reason is given for altering the proxyCallback controller.

Please make sure that these paths are made available without breaking the default URLs provided by the CAS module.

Since this is a Drupal 8 module, we should use the branch naming conventions as documented on drupal.org. We should switch to 8.x-1.x and empty the master branch, leaving a note in the README directing the users to the correct branch to use.

Ref. Maintaining a Drupal project with Git: Working with branches and tags

The client has asked us to delete (not just block) a certain user.
We are using oe_authentication and we have seen that it blocks this possibility.
We wanted to confirm with you if this is a security restriction or if we can create a patch to remove that limitation?
Please can you explain the security reasons for this limitation?
Thanks!

This should be configurable as some sites may want to offer also Drupal registration. Other sites might decide to show a page with several authentication providers/authorities.

After release 1.0.0-beta2 of task-runner we're not touching the default.settings.php file anymore.

So here we need to change the append task to run after drupal:settings-setup and to target the new file settings.override.php .

I want all users to be able to login using only a 2 factor authetication method, users can be EC or self registred.
Is there a way to see if the user logs in using a 2FA method, like SMS, EULoginApp or Token?

I found this page: https://citnet.tech.ec.europa.eu/CITnet/confluence/display/IAM/How+to+determine+the+type+of+authentication but don't know how to implement it on Drupal 9.

Any suggestion is welcome!

Thanks

Latest version of oe_authentication is not compatible with drupal 9.4 while the 1.6 version was compatible.
9.3 security support ends in 3 months and 2 weeks

When following the installation instructions we fail when enabling the module in a Drupal 8 installation.

$ composer require  openeuropa/pcas
Using version ^0.2.2 for openeuropa/pcas
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Package openeuropa/pcas is abandoned, you should avoid using it. No replacement was suggested.
Writing lock file
Generating autoload files
$ composer require openeuropa/oe_authentication
Using version ^0.5.0 for openeuropa/oe_authentication
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Package openeuropa/pcas is abandoned, you should avoid using it. No replacement was suggested.
Generating autoload files
$ drush en oe_authentication
 
In PmCommands.php line 247:
 
  Unable to install modules oe_authentication due to missing modules oe_authentication.
 
 
pm:enable [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--druplicon] [--notify [NOTIFY]] [--xh-link XH-LINK] [--] <command> [<modules>]...

Do you have any idea what is going wrong?

Best
Ben

Hello,

If we enable the option "Force two factor authentication" from the module settings (/admin/config/system/oe_authentication), we are still able to select the password authentication method from ECAS.
When we do so, we get a vague error in Drupal, which is very confusing for end users:

There was a problem validating your login, please contact a site administrator.

And the Drupal logs contain:

Error when validating ticket: Error Code INVALID_STRENGTH: ticket 'ST--' does not match requested strengths: [PASSWORD_MOBILE_APP, PASSWORD_SOFTWARE_TOKEN, PASSWORD_SMS]

Ideally EULogin should only list applicable login options.
I believe https://citnet.tech.ec.europa.eu/CITnet/confluence/display/IAM/Multi-factor+authentication is related and explains 3 types of authentication methods (basic/medium/high).
Shouldn't the module expose these 3 options (as select?) in settings instead of the "Force two factor authentication" checkbox?

Thank you

See oe_authentication_user_cancel_methods_alter(). Why only superuser is able to cancel accounts with deletion?

Looks like this restriction in hard coupled with some OE business logic (?)

CAS setting error_handling.login_failure_page is not working properly in drupal/cas:2.5.
We have a behat scenario failing: "A site that requires administration validation on users should block them by default" is failing in step "I should be on the homepage" because destination param is sending the user to user/login page.

May be related with this commit:
https://git.drupalcode.org/project/cas/commit/d27bcb0

Hi,

After installing this module I get the following error:

You are using an invalid service to access EU Login: ['https://d8tst.example.com/casservice?destination=/'] 

Instead of example.com I'm using a functional domain name.

Is there a need to register this website first before it can be used with EU login? I didn't seen any references in the README.md

Currently the information received from eulogin is only updated during the first login.
Decide when this information should be updated (every login, during cron,...) and implement it

The current base fields are prefixed with "field_". This is confusing since it makes them look like fields that were created through the Field API when they are not.

The goal of the ticket is twofold:

• Rename the current fields and remove the 'field_' prefix
• Provide an upgrade path for current users of the component.

In the latest beta version the dependency on https://www.drupal.org/project/externalauth is missing.

externalauth.authmap used in oe_authentication.external_user_access_checker service.

In \Drupal\oe_authentication\Access\ExternalUserAccessCheck::access() there is this piece of code:

if ($this->authMap->getAll($account->id()) === []) {
  return AccessResult::allowed();
}

Using ::getAll() here is wrong because on a system might offer support for multiple external authentication authorities (social media, Github, OpenID, etc.)

Even if limiting the access to those routes could be useful when using other provider/authority, this module should not make assumptions on behalf them.