Autologin when one client enabled

Thank you for your suggestion and contribution. I'm going to keep this issue open, so other users can vote whether they find this feature a useful addition to the openid_connect module.

+1; very useful for our organization.

+1 from me too. Thanks!

+1 this would be very useful for us on 7.x

Additionally, something that could complement or replace this feature would be to support "IDP hints" (similar to how Keycloak supports a kc_idp_hint parameter for identity brokering) that, when present, immediately bypasses the log-in screen and sends the user to the specified identity provider for authentication.

+1. It will be very useful for the project (D8) I'm working on at the moment. I've had to create a javascript function to do this.

Just tried with drupal/openid_connect (dev-1.x e002d7e). The 2018-11-19 patch didn't apply cleanly for me.

Were others able to use it/test it?

+1 would be very useful for my current project.

+1

+1; It will be really useful for us.

Although it can be achieved the same way with a custom module and an event subscriber... but if it's integrated it would be great!

+1 from me. I already have a simple custom module for Drupal 7 that does this on login. Would it be helpful to share that?

1+

@solideogloria: it would be really helpful, if you could share your custom module for Drupal 7 :)

This is the openid_autologin D7 custom module (not hosted on drupal.org) that a project I work on uses. The module file has been converted to a text file so I could upload it here.

Edit: The info file can't be viewed either, apparently. Uploaded as txt in the next comment.

Thank you really much! Works fine

+1 for this functionality

fyi, the D8 patch in #2 wasn't working for us, so I've created a new patch that at least works for us. Hopefully it'll be useful~

Additionally, it looks like the original patch was generating unnecessary extra files... which I haven't cleaned up yet. will do in a mo!

Corrected my patch from #18 to not create unnecessary duplicates of AutoLogin.php

We would find this very useful.

+1 would be very useful for my current project.

@Iain.Madder You shouldn't hard code the autostart_login_bypass, even if it's just the default. It would be better to generate a random one on install or default to NULL.

Also, openid_connect_save_destination() is deprecated. You should use OpenIDConnectSession::saveDestination() instead, (or \Drupal::service('openid_connect.session')->saveDestination(), but intellisense doesn't work with code in that form).

I made a couple changes to the patch in #19 per my previous comment. Interdiff is provided.

Fixed an incorrect use statement I added to be correct.

Still learning Drupal 8. Tested the changes I made and related to my comment in #22, it has to be \Drupal::service('openid_connect.session')->saveDestination() in AutoLogin.php, or it throws a fatal error.

Patch #25 works for me with #3112173: Drupal9 deprecations installed at the same time.

If someone else could review it...

Added the new settings to the schema yml, per the test failure.

Sigh. Missed the added files.

The latest patch passed the tests it needed to pass, since the branch is failing one test.

Here is a patch that successfully applies on top of #3112173: Drupal9 deprecations patch #15.

Working with multiple patches applied at once is tricky business...

Duplicate comment removed.

I reached a fatal error at one point. On line 104, it calls $response = $this->getClient()->authorize();, but the client can be NULL if more than one provider is enabled or if the settings are not configured. Similar to the code in isAutostartEnabled(), it should check if the client exists before calling a member function of the client.

Changes:
- contains a check for if $client is defined before calling the $client->authorize()
- Remove unused: use Drupal\openid_connect\OpenIDConnectSession;

This patch with the changes was rerolled to apply on dev.

Let's remove the token and reuse the existing 'showcore' parameter to the user/login page instead of 'autostart_login_bypass'. I fail to see the need to have a token value in addition to the parameter.

If there is only the parameter, then users can choose which login form they want and use the Drupal Core login, even if they shouldn't be able to.

Yes, the token grants a tiny, very limited layer of security. It also creates a new parameter in addition to the one already existing for the exact same purpose.

This will not be committed with the token parameter.

Is there another way to prevent users from bypassing login and going to the user/login page? For example using the parameter that already exists or blocking access to that page?

There are settings since a few months ago to hide the normal login form (added at the same time as the 'showcore' parameter). Users would need to know their Drupal username and password (and they would have to know about that parameter, but that info is available to all admins of a site using this module).

Users that had their accounts created via OpenID won't have a password set, so they won't be able to login until they set one up. And I'd prefer to let users that know their username and password be allowed to login.

Maybe a compromise solution would be to split this into two issues.. This issue without the token, which I'm willing to review and commit, and another that adds a bypass token to the showcore parameter, that if enough people think is a good idea, I'll probably commit as well (probably later).

Needs a re-roll for version 2.x of the module, as 1.x is no longer getting new features.

Rerolled the patch in #36 to the latest module version . Retaining status "Needs Work" to address #37. Thanks!

Still needs work to adapt to the new config entities in 2.x. Looking at the interdiff, #36 and #43 are exactly the same, with some minor line shuffling.

I have applied #36 in 8.x-1.0 version #43 on 2.x version and after applying the patch(Tried by configuring both the versions), while accessing /user/login, the page is getting redirected to client login page, but after providing the credentials its keep on redirecting between /user/login and authorization end points. And at the end it got failed with the error "Site can't be reached, redirected too many times.".

Also if I access any other URLs, its still taking me to Drupal login page. Is there a way for force authentication and redirect the user to providers login page if the user access any application URLs?

@angh1234 Are you using r4032login? Just wondering, because there is an issue there that is similar.

#3206294: Prevent redirect loop

@solideogloria I'm not using any other modules for redirecting purpose. I have used Open ID Connect Windows AAD module along with Open ID connect.

@angh1234, I don't think that module is compatible yet with the latest version of this module. See #3202845: Adapt to the 2.x branch of the OpenID Connect module. Also this feature will never be ported over to version 1.0 of this module, so there is no point in discussing #36.

As per #50 OpenID Connect Microsoft Azure Active Directory client is not yet compatible with 2.x version, hence configured Azure AD endpoints with Generic OAuth 2.0 client and applied patch #43 with slight difference in openid_connect\openid_connect.services.yml .

But even after applying the patch, I'm getting redirected to Drupal login page. Anything I'm missing here or should I use any other version of the OpenID connect module to make it work ?

Do we have any workaround to get autologin working with 2.x ?

Patch at #36 did work well with 8.x .

Claims seems to be missing with the patch at #36.
Tested this patch with 8.x-1.1 release. We might need a re-roll for the latest dev branch.

Rerolled to version 2.x

1. Adapted the AutoLogin event subscriber to the new config entities from version 2.x
2. Changed the deprecated plugin manager service with the new one from version 2.x

Tested with 2.x - works properly

Hi Team,

I have used the openid connect module which supports drupal 8 & 9 and using drupal 9 which was upgraded in my site and if i installed newely and configured the credentials and while apply the Auto login patch in mentioned below url
https://www.drupal.org/files/issues/2021-09-17/openid_connect-autologin-... and while update the patch using composer getting line mismatch, so i have applied and created the patch openid_connect-autologin-3011413-58.patch. may it will useful other to upgrade the drupal 8 to drupal 9

If possible to get the next stable version release which support drupal 8 & drupal 9 it will be greatful in advance.

Thanks,
Ganesh

Patch #58 does not apply to 8.x-1.x.

I made one that applies (works for me using composer.patches.json). This should help those who are still on the supported branch.

The patch in #59 seems to have broken the login flow on the site I work on. The issue in our case is with this line:

$entity_storage = \Drupal::entityTypeManager()->getStorage('openid_connect_client');

Doesn't seem like 1.x has the 'openid_connect_client' entity as 2.x does.

It didn't work for me, either, in the end. I get the errors that openid_connect_client entity doesn't exist.

All I did was make it so that #58 applies.

I manually went through all the changes and rerolled the patch for 8.x-1.x, taking into account what was said about the autologin bypass setting (and removing it).

The patch successfully applies. I tested this with a fresh openid_connect and openid_connect_windows_aad, and login works as it did before.

I am trying to use 1.2 and the patch in 63, the only issue I'm having is that `showcore` parameter doesn't prevent the redirect to the SSO endpoint like patch 36 and 1.1 did. Is it possible to get that into a new patch here or is that a different issue I just haven't found yet?

@graper You need to set the "OpenID buttons display in user login form" setting to "Replace".

Did that, set to replace and used showcore flag and it still redirected. Made sure that Chrome didn't cache the redirect as well.

In patch 63 the login method doesn't check for the request query parameters to see if the showcore flag is set so it just redirects you. In 36, that same method checked if the bypass flag was set.

Since this thread is about auto redirect and auto login when only one provider is set up, clicking the button to redirect to the SSO provider isn't needed (replace method), and the bypass in patch 36 was useful for keeping users (at least our developers) on the Drupal login form.

I think the showcore flag should be able to prevent the redirect similar to the bypass code did in patch 36, otherwise you'd never be able to use Drupal's core form when a single provider is set up.

Could you submit a patch? I'd guess it should use something like && empty($request->query->get('showcore')) in the login() function on line 99. I also noticed I left a comment about the bypass parameter. So that comment can be updated.

I won't have time to get around to testing that for a while.

Reroll of 63 with the one line change.

Re-rolled with a properly made patch against 8.x-1.2

Better re-roll. seems I suck at making patches.

It still has the reference to openid_connect_bypass in a comment on line 98.

Ignore this. I tried the wrong branch.

Patch #56 does not apply to either 2.x-dev or 2.0-alpha12.

However, patch #70 still works for 8.x-1.2

    "drupal/openid_connect": {
      "#3011413: Autologin when one client enabled": "https://www.drupal.org/files/issues/2022-02-14/openid_connect-autologin-3011413-70.patch"
    },
    "drupal/openid_connect_windows_aad": {
      "#3169996: Incorrect configuration schema file": "https://git.drupalcode.org/project/openid_connect_windows_aad/-/merge_requests/5.patch"
    }

Re rolled the patch against 2.x version.

@sourabhjain The patch applies, but it's missing the AutoLogin.php file.

Class "Drupal\openid_connect\EventSubscriber\AutoLogin" does not exist

Fixed PHP error (missing Autologin.php file) from #75 for 2.x patch.

Removed references to old param 'openid_connect_bypass' in comments for 1.x patch (improving upon #70).

#79 is for 1.x. I selected the wrong branch to test against.

Fixed missing Autologin parameter in the services.yml file.

*sigh*. Fixed missing Autologin.php file. I wish git bash would auto-add new files when a patch that adds the file is applied...

This event listener works well, thanks for creating it!

We had to make a slight adjustment because we have content editors which need a login page, but also customers which have their user profiles stored in an identity provider. For our customers, we send them to the following url: /user/login?autologin

Here is a patch that will adjust the module to work for both cases.

The patches for 1.x already had a 'showcore' query parameter that does what you want to do. Also, your patch didn't include any of the other changes from the previous patches.

Patch 83 wasn't working for me against 2.0.0-beta3. The issue was in openid_connect.settings.yml.

This patch works for me.

Get scopes before client authorize for 1.x.

Tested patch #86 and it is working great with 3.0.0-alpha2. I see the new checkbox setting Autostart login process and after enabling this, the Drupal login form is bypassed and sending me straight to the identity provider.

This is working particularly well when combined with the r4032login module if you want to force login with an identity provider.

Setting this to needs work because the ?showcore URL parameter isn't working when Autostart login process is enabled.

Small addition to the patch in #87: if the endpoints are empty, don't attempt auto login.

Added schema definition for the new autostart_login_bypass configuration option.

Just posting the MR as patch to use in composer

You don't need to repost as a patch. Just download the MR patch into a folder and use something like ./patches/openid_connect-mr22.patch in your composer patches file.

https://git.drupalcode.org/project/openid_connect/-/merge_requests/22.patch

Fixed undefined classes for 3.X-dev

The latest patch works for me on 3.x

Patch #79 still works for 1.x

Small addition to the patch in #94: if one of the endpoints are empty, don't attempt auto login.

Changed

foreach ($client->getEndpoints() as $endpoint) {
  if ($endpoint === NULL) {
    return FALSE;
  }
}

to

foreach ($client->getEndpoints() as $endpoint) {
  if (empty($endpoint)) {
    return FALSE;
  }
}

Hi,

Updated new patch. Included claims to retrieve the scopes from client.

Thanks,
Buvaneswaran.

Moving to Needs Review, since there's been a couple changes and no interdiffs.

latest (and most here) patches do not adhere to Drupal coding standards. Unclear why these would pass the test bot.

There is a userinfo endpoint option of "Alternate or no endpoint". We are using Azure's Common API (stupid name for an app which acts as a router to multiple AAD tenants). So far we do know of a userinfo endpoint so we picked the no endpoint option; but then this would leave the endpoint value empty (if filled in, auth fails as it fails trying to access the non-existent endpoint). But, if left empty, this fails the conditions for allowing autologin.

For now we have simply hacked out that condition; but possibly a more thought out solution here? I suspect the thinking was that all the "other" endpoints had to be filled in; but likely not that one.

NVM - this patch is no good

I modified the patch from #99 to not include userinfo endpoint.

• I started with patch #94
• I fixed all the coding standards issues that are in the changes (without duplicating the work at #3418272: Fix PHPCS errors).
• I fixed comment wording

I'm going to look into whether any of the changes after #94 should be included.

MR 98 should be used going forward, as it targets 3.x.

I applied the changes from #103, but with it actually working ($type needed to be added to the for loop).

I have now applied all the requested changes from #94 and after. Please review the changes.

The patch from the MR can be downloaded here. Put it in your project folder and put a reference to ./patches/openid_connect-3011413-mr98.patch or whatever in your composer.patches.json file.

Make sure to clear your site's cache after applying the patch.

Whenever credit is assigned for this issue, please include:

• rp7
• cbuvaneswaran
• liquidcms (already credited)

Bit less strict with endpoints as only authorization is used during login