Easiest way to add “advanced” OneLogin options?

Hey @desmith,

There’s a wp_saml_auth_option filter but I’m not sure if it only affects the config values specified in the wpsa_filter_option function right above it, or if I can use it to set other arbitrary configuration settings that aren’t part of the plugin’s GUI.

You can use it to set other arbitrary configuration settings that aren’t a part of the plugin’s GUI. The internal_config attribute is passed directly to the OneLogin class.

Hope this helps! Let me know if there are any other questions I can help with.

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.)

Thanks for reporting back, @desmith!

And once you do an add_filter('wp_saml_auth_option'), the plugin’s GUI no longer is accessible.

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

(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.)

To clarify: if you’ve manually added the filter, the GUI settings are completely disabled.

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.)

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

What do you think about this new language?

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.

We’ll keep it under consideration!

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 thought about that before. I wouldn’t want a user to be confused about why the page wasn’t appearing though, so opt-ed for the message instead.

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.

I like it! ??

Great!

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

You’re welcome ??