David E. Smith

I can confirm that it still works, at least for my use case, up to WordPress 6.7.

That said, it would be nice if the plugin authors would officially confirm that they’re still testing/maintaining it.

Glad to see it!

Out of curiosity, why is that a define and not a setting exposed in wp-admin? Not that a define is especially difficult to use, but that feels like something that will be used enough that you might want to make it more easily discoverable. (Most of those defines do look like things that it would be uncommon to change, but the two related to comments feel different.)

This screen shot might make more clear what’s going on – the first item in the thread is a post, the others are comments, and I’d like to know if there’s a way not to generate Mastodon posts for the latter.

Are you considering adding an option for users to enter their own Twitter API keys for this purpose? I really like having the different login options visually unified. (I know that it’s a bit of added complexity which is kinda not Jetpack’s vibe, but in this case I’m not sure there are many other options.)

I’m seeing the same issue but with Object Cache Pro. Performance Lab and Object Cache Pro keep replacing each other. I wonder if Performance Lab should be a bit more conservative about this — if it detects another object-cache drop-in, sure, fire a warning in the health check screen, but maybe don’t replace the pre-existing one without explicit user consent.

Perfect. Thank you!

To my great disappointment, this is not only a known bug, but it’s one that’s been open for eleven years: https://core.trac.www.ads-software.com/ticket/17904

My backup plan was going to be “oh, I’ll just use our SSO system’s user IDs for this” but there’s a separate check in wpmu_validate_user_signup that prevents users from having all-numeric usernames.

I strongly suspect that at least my original case (usernames with periods) works, because on my test network, a few users that were created with usernames like that, from before I switched the site to a network, exist and pass the initial sniff tests (can log in, appear to work at first glance).

Time to write some patches, I suppose.

Unfortunately, the filter hook won’t work, because it doesn’t fire until after the questionable regex check takes place.

https://developer.www.ads-software.com/reference/functions/wpmu_validate_user_signup/ — the regex in question is on line 479, but the filter doesn’t run until line 600, and in any event the filter says you can’t use it to change anything, it appears to be intended for error handling.

While this feels like a piece of leftover code, I just find it hard to believe that I’m the first person who ever has wondered “why can you use a period as part of a username HERE but not THERE”. And it’s a simple enough fix, but I don’t know nearly enough about all the other places that MU and usernames might interact to know if it’s safe.

I like it! ??

Thank you again for all your help with me trying to figure out this plugin and how to wrangle it for my environment.

Good point. Is there anything you think we could clarify on the messaging?

A line or two on the “Installation” page, just to reinforce that if you filter anything, you’ll have to specify settings for everything.

If you’re feeling really ambitious, maybe a widget on the Settings page that will export your current settings into a code block, ready to be cut-and-pasted into a filter. (I’m not sure if that actually would be MORE confusing, though. At a minimum, the wording on such a gizmo would be ‘interesting’.)

Speaking of things that might be more confusing, I wonder whether it’s worth hiding the GUI page entirely if there’s a filter, since the page only exists to say “this page does nothing.” (I’m doing that with a simple action, but I have a fair amount of control over my environment, and I know that most of my users will never need to touch SAML settings.)

For the future reference of anyone else who falls into this particular rabbit hole…

All of this plugin’s settings live in one array. And once you do an add_filter('wp_saml_auth_option'), the plugin’s GUI no longer is accessible. (I think if you put in any settings before doing that, they’d still take effect, but that feels like a really nasty trap to set for yourself, so don’t.)

You’ll have to put ALL of your settings into your filter.

I first created a function with all of the settings exposed via the GUI:

public function add_saml_config( $value, $option_name ) {
  $mysettings['connection_type']  = 'internal';
  $mysettings['permit_wp_login']  = true;
  $mysettings['auto_provision']   = true;
  // and another half-dozen "generic" settings

  $mysettings['internal_config']['strict'] = true;
  $mysettings['internal_config']['debug'] = true;
  $mysettings['internal_config']['baseurl'] = home_url();
  $mysettings['internal_config']['sp']['entityId'] = 'urn:' . parse_url( home_url(), PHP_URL_HOST );
  $mysettings['internal_config']['sp']['assertionConsumerService']['url'] = wp_login_url() ;
  $mysettings['internal_config']['idp']['entityId'] = 'https://idp.entity.id/goes/here' ;
  $mysettings['internal_config']['idp']['singleSignOnService']['url'] = 'https://my.sso/url/here' ;
  // and so on, for me this is about 15 more lines

  $value = isset( $mysettings[ $option_name ] ) ? $mysettings[ $option_name ] : $value;
  return $value;
}

Be aware that it’s arrays all the way down. internal_config is an array that’s passed into the OneLogin library, and it in turn expects an array for the SP, a different array for the IDP, and a few top-level settings.

If you want to add extra obscure SAML settings (which was my goal), you can just add them to the internal_config. Maybe:

$mysettings['internal_config']['security']['wantMessagesSigned'] = true;
$mysettings['internal_config']['security']['wantAssertionsSigned'] = true;

and so on.

Then, you have to use the filter you’ve created with all your config settings, and you’ll probably want your settings to go in first (so they’ll override the defaults), with something like:

add_filter('wp_saml_auth_option', array( $this, 'add_saml_config' ), 5, 2);

(The above assumes you’re inside a PHP class; if not you probably can just do ‘add_saml_config’ instead of the array for the second arg.)

So far, at least, that approach seems to work. Putting it all together for anyone in the future who might need it… I’ve added actions like this, for both wp_saml_auth_new_user_authenticated and for wp_saml_auth_existing_user_authenticated:

add_action( 'wp_saml_auth_new_user_authenticated', function ( $user, $attributes ) {
  $this->populate_saml_attrs( $user, $attributes );
  }, 10, 2 );

The populate_saml_attrs function, in my case, goes through the provided attributes and stores the info in user_meta:

function populate_saml_attrs( $user, $attributes ) {
  foreach( $attributes as $k=>$v ) {
    $samlname = 'saml_' . strtolower( $k );
    update_user_meta( $user->ID, $samlname, $v );
  }
}

This gives you a bunch of user_meta attributes with whatever names or OIDs were provided by the identity provider. In my case it’s something like:

saml_urn:oid:1.2.840.113556.1.4.221     a:1:{i:0;s:10:"davidsmith";}
saml_urn:oid:2.16.840.1.113730.3.1.241  a:1:{i:0;s:11:"David Smith";}
saml_urn:oid:2.5.4.42   a:1:{i:0;s:5:"David";}
saml_urn:oid:2.5.4.4    a:1:{i:0;s:5:"Smith";}

Anyone using this is highly recommended to extend how they populate the attributes, and put in some sort of user-friendly names instead of the OIDs if they can, the folks consuming the data will thank you.

I never tested if you could add this straight to $_SERVER to mimic how the Shibboleth plugin works. More I thought about it, more I thought that modifying a superglobal seemed like a really bad idea. ??

Thank you!

Weird, I was literally about to post about those, and how I’m not sure how they work. ??

Does new_user_authenticated only trigger on a user’s first logon, and existing_user_authenticated only trigger on subsequent logons? (Is there one that triggers for all successful logons, both new and existing? That’ll help me avoid duplicating code.)

I’m doing this which covers most of my use cases so far:

add_action( 'wp_saml_auth_existing_user_authenticated',
  function ( $user, $attributes ) {
    foreach ( $attributes as $k=>$v ) {
      $sname = 'saml_' . strtolower( $k );
      update_user_meta( $user->ID, $sname, $v );
      $sname2 = 'saml_' . $this->get_name_by_oid( $k );
      if ( $sname !== $sname2 ) {
        update_user_meta( $user->ID, $sname2, $v );
      }
    }
  }, 10, 2
);

(get_name_by_oid is a function that looks at the OIDs and returns the human-readable versions, a low-budget attribute map if you will)

Should I just abstract that code into a separate function and call it for both new_user and existing_user events?

Issue opened. This looks like in theory it’s a one-liner, but there’s a lot of potential discussion to be had around that one line. ??