Page MenuHomePhabricator

Problem with auto-creation of Shibboleth user in the wiki in case of the first login
Closed, ResolvedPublicBUG REPORT

Description

The title of this task is deliberately similar to T334083, because it might be the same or a similar issue.

I am currently testing MediaWiki 1.39.5 with extensions PluggableAuth 7.0.0 and SimpleSAMLphp 7.0.0 (with SimpleSAMLphp 1.19.7 as Service Provider). I have seen this behaviour also in 1.39.4 and 1.39.3 with the 7er versions of these extensions.

When logging into a wiki with a user that is currently unknown to the wiki (i.e. successfully returning from the login page of the Shibboleth IdP), the user is created in the mediawiki database, but it is not associated with any user groups. Only after a second login via the IdP (after logging out or using a new browser window), the requested groups are associated and the wiki is usable as desired.

I have used PluggableAuth-REL1_39-cfd7f79.tar.gz generated this morning and SimpleSAMLphp-REL1_39-c57ad6a.tar.gz created in August. It is unclear to me, if the changes mentioned in T334083 are present in these releases.

NB that users already present in the database are unaffected when e.g. upgrading from previous versions. I am currently using MW 1.39.2 and PluggableAuth 6.2 and SSP 5.0.1 in production, and the problem is not immediately obvious after upgrading to newer versions.

Event Timeline

It would be great if this could be tackled. MediaWiki 1.39.6 was released recently, and I am stuck with 1.39.2. I think it was unwise to change this extension for an LTE release mid-lifecycle.

I have tried to install a current version of MediaWiki with working versions of PluggableAuth and SimpleSAMLphp using composer, but the latter extension seems not to be available to composer.

I can confirm this issue and have provided a patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SimpleSAMLphp/+/991744

@CCicalese_WMF The issue is, that when a new user gets created, the PluggableAuthPlugin gets re-instantiated (apparently the request context changes in this case) and the new instance does not know about the SAML attributes from the initial authentication anymore. Extension:OpenIDConnect hat the same issue, but has already a workaround implemented: It stores the "payload" data from the OICD response in the session and uses this in PluggableAuthPlugin::getAttributes rather than a some object variable. I have now implemented the same workaround in Extension:SimpleSAMLphp, but I believe this should better be fixed in Extension:PluggableAuth, as it may affect other plugins as well. In my opinion, Extension:PluggableAuth should store the value of PluggableAuthPlugin::getAttributes in the session data, right after PluggableAuth::authenticate was called and then use this session data in GroupProcessRunner::run. Do you agree? If so I can provide a patch to Extension:PluggableAuth (and patches to Extension:OpenIDConnect and Extension:SimpleSAMLphp that remove the workaround).

cicalese edited subscribers, added: cicalese; removed: CCicalese_WMF.

Great catch! I agree completely with the proposed solution. Yes, please provide patches to move that functionality to PluggableAuth. Thank you!

I can confirm that this fixes the problem for me as well. Many thanks again!!

Osnard claimed this task.

Patch has been merged in the meantime