Topic on Extension talk:SimpleSAMLphp

Mediawiki: 1.39.1 Pluggable Auth: 6.2 SimpleSAMLphp: 5.0.1 Local SimpleSAMLphp: 2.0.3 PHP: 8.2

I'm hoping someone can shed some light on an odd problem I'm having with SAML and pluggable auth. If a user is completely logged out of the mediawiki instance and attempts to log in with SAML to an Okta IdP, I get Fatal error authenticating user.

However, if I try and log in again, I'm in without issue. It doesn't reach out to the external server and proceeds without a hitch.

If I go to Special:UserLogout and then attempt to log in, the behavior repeats.

I've dug into the logs and found almost identical GET requests, one is same-origin that works and has this mentioned in the log:

[PluggableAuth] In execute()

[PluggableAuth] Getting PluggableAuth instance

[PluggableAuth] Plugin name: SimpleSAMLphp

[PluggableAuth] Instance already exists

The other fails, is a cross-site request and has this message:

[PluggableAuth] Getting PluggableAuth instance

[PluggableAuth] Could not get authentication plugin instance.

I've tried authorizing XSS in my vhost configuration, and I know for a fact nothing is being denied by a firewall. Is there something I need to change in my configuration?

$wgPluggableAuth_Config['Log in using my SAML'] = [

       'plugin' => 'SimpleSAMLphp',

       'data' => [

               'authSourceId' => 'default-sp',

               'usernameAttribute' => 'NameID',

               'realNameAttribute' => 'NameID',

               'emailAttribute' => 'NameID',

               ]

       ];

$wgSimpleSAMLphp_InstallDir = "/var/simplesamlphp";

I've added the remote IDP to the trusted.url.domains value in the config.php file for simpleSAMLphp

The GET requests are identical barring the one that works says:

SEC-FETCH-SITE: same-origin

The one that doesn't says:

SEC-FETCH-SITE: cross-site with a referrer of my IdP

Note: Technical limitations on the part of my IdP require me to keep a list of authenticated users, and getting them to add NameID (which is the account's email address) as an attribute was painful enough. I have autocreateaccount and createaccount set to false. I know this isn't considered the typical use case.

I am not quite sure if I fully understand your setup and issue. But I guess this is some session issue.

[PluggableAuth] Could not get authentication plugin instance.

indicates that the user session was not properly loaded on side of MediaWiki. This an either be due to missing cookies, or cookies are not accepted by MediaWiki.

Have a look at Manual:Hooks/RequestHasSameOriginSecurity, maybe it can be used to "whitelist" your "cross-site" request.

Thank you so much for your reply and I'm sorry I need to be vague, I'm working with a company that's got a slight lawyer infestation and I need to be super careful to avoid mentioning anything identifiable. Was mostly just trying to justify the silly values I had to punch into the username and realname attributes.

I am attempting to authenticate against an Okta SSO provider located over the web. When I click login the first time, I get Fatal error authenticating user and the Could not get authentication plugin instance. I then return to the homepage, attempt to login again, and it goes through without reaching out to the Okta environment. The cookie is being saved to my browser.

The part that's boggling my mind is, when I DO succeed, there's an existing session.

I've set $wgCrossSiteAJAXDomains to allow the Okta environment I'm checking against, and set $wgCookieSameSite = "None" Are there any other values in mediawiki that might be relevant in this situation? Do I need to add a pause or something?

Hello guys,

UlfrTheRed bro i need you. Like you I am stuck with a fatal authentication error when I try to setup the sso. I don't use Okta but simpleamlphp as SP. However I have the same behaviour as you on the first login attempt I get the auth error and if I try again I end up logged on my mediawiki instance. I am also doing this for my company in a production environment, and have been stuck with this problem for about 2 weeks now. Would you have a solution or any tips to give me. This is the first time I've tried to set up SSO but mediawiki clearly doesn't make it easy with conflicting versions of extensions and configurations that change from one version to another etc. Thank you very much in advance for any help or answers.

@Osnard

I think I found a very important clue! I didn't look hard enough at the cookies themselves.

The cross-site cookie that I am issued has two values: SimpleSAMLSessionID and SimpleSAMLAuthToken

The local login that succeeds has several more values: SimpleSAMLSessionID, SimpleSAMLAuthToken, wikiUserName, SimpleSAML, and wiki_session.

I am very very new to the astonishingly frightening world of SSO. Did I goof in my configuration? Or is my provider giving me a bum steer.

Also, thank you very much for your feedback and time, I very much appreciate it!

That explains the issue at least. Without the wiki_session cookie, the wiki does not recognize the request as part of an authentication flow.

I believe this may be due to security policies. At some point, the browser does not allow to send that cookie to a certain context.

In general I don't believe the "cross-site" aspect in your setup is reasonable. I can not tell what, but something is wrong in that flow in general. This is probably not connected to MediaWiki, PluggableAuth or SimpleSAMLphp. And I somehow doubt that it can be solved there.

@Baldrom I have good news and bad news for you!

Good news is, I fixed it!

Bad news is, there was nothing wrong!

That error message is appearing because after you log your wiki session out, mediawiki destroys the session. When you then attempt to log in to the session using SAML, it requests the session that mediawiki had already destroyed. PluggableAuth then throws an error because it can't find the destroyed session, and then the second authentication works because it's either recreated using the session details provided by the first or something. Unsure what exactly.

The tentative solution I have is just to remove the log out button, but I'm also kind of in crunch time mode. Looks like adding a Single Sign Out behavior should remove the disconnect, but for now I've just removed the log out button

Hello @UlfrTheRed thank you very much for your feedback. In this case, it is enough to remove the disconnect button to solve the problem? This is done in the config pluggable auth of the localsettings.php of my wiki ? Thank you in advance for your answer and sorry for the "stupid" questions I can't manage with this wiki anymore, too many things are illogical

Best regards bro !

@UlfrTheRed I'm probably asking a lot but could you share with me your configs in your localsettings.php, in your simplesaml.conf and in your idp declaration ? I don't see precisely where and how I could bypass the error as you said you did above. 

@UlfrTheRed I just did some tests and indeed you are right! During my first login I don't have any session cookie for my wiki but during the second login ( which works ) I get the wiki media session cookie ! I'm waiting for a feedback from you to deactivate the logout but I thank you very much for this very precious information that you could bring me !

Hi @Baldrom!

Unfortunately I wasn't able to figure out any method to make the ACS assertion work in one step without an error. What I WAS able to do was bypass the error completely by using the IdP's pre-authenticate link to access the wiki, and set the cookie and session expiration timers to 15 minutes.

I wish I could provide you with an example of what I'm talking about but I'm operating under an NDA and can't provide an actual example. In my use case, we're using Okta as an IdP, and Okta provides a link that will redirect to the application and initiate the session that way. Then the login request comes and simpleSAML already has the session set up and ready to go. So rather than going directly to somewiki.org, there's an okta link that's something like okta.com/somerandomnumbers/somewikiredirect that eventually takes you to somewiki.org while also initiating the session.

I wish I could explain this better, best of luck!

@UlfrTheRed Thank you for documenting this issue! I am seeing the exact same issue on my organization's wiki when upgrading from mediawiki 1.35 to 1.39.3. Now I have some clues on how to move forward - seeing the same missing wiki_session cookie on first auth, and the "Fatal error" message thrown by PluggableAuth, and then the second auth succeeds.

I'm on PluggableAuth 6.2, SimpleSAML extension 5.0.1, simplesamlphp 1.18.4 and php 7.4.

@UlfrTheRed @Baldrom

So, I got things to work. This seems to be a known bug documented here: https://phabricator.wikimedia.org/T322828 that was fixed just recently in PluggableAuth. So, now using the latest version of PluggableAuth 7.0-dev, as well as updating the SimpleSAMLphp extension to 7.0-dev as well, login succeeds with no errors.