ktbartholomew

stephenmahood,

I agree! The AUTH_KEY dependency was never a great solution. Version 0.9.4 no longer uses this method. It creates a completely random (not tied to auth_key, and also not reversible) password, but never actually uses it.

The plugin also no longer depends on being able to reproduce a password for each user to log them in, so changing the AUTH_KEY will no longer have the effect of locking out all the users.

https://github.com/ktbartholomew/saml-20-single-sign-on#094

pmirek, this issue has been identified here: https://github.com/ktbartholomew/saml-20-single-sign-on/issues/11

The fix is very straightforward, and should be released pretty soon.

That’s an error from the IdP itself. Decode the SAMLResponse (https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php) to see what’s up.

@meekels: I agree with Roquefort, I would recommend getting HTTPS running on the SP. I think you might be able to create plain HTTP endpoints in ADFS, but the POST from an HTTPS IdP to an HTTP SP will make a lot of browsers throw security warnings. Using a self-signed certificate should work just fine until you get things working.

@renperez01: Your IdP is sending a big hint here. The EntityID for the IdP is https://mywebsite.com/adfs/services/trust so you need to enter that URL in the IdP tab of the WP control panel page.

Do you know which 2 URLs are causing the redirect loop?

This is nearly identical to this request: https://www.ads-software.com/support/topic/feature-request-optional-group-adjusting. It’s a good suggestion, and I’m planning to implement it in some form.

The plugin doesn’t provide an interface for implementing encrypted assertions, but the underlying library (SimpleSAMLPHP) supports it. It’s a feature I’d like to add, but I can’t really promise an estimated timeline.

I just realized that I was having this issue today, while trying to chase down a separate IIS issue. I ignored it at the time, but I think I should be able to replicate it for you.

Incidentally, I did discover today that openSSL works fine on IIS, but you have to add an environment variable to the FastCGI handler: https://www.php.net/manual/en/openssl.installation.php

Specifically, the part about setting OPENSSL_CNF to something like “C:\php\extra\openssl.cnf”.

Once I followed those instructions, I was able to generate the signing certificate the FUN way!

I haven’t tested Single Logout a whole lot, but in a lab setting early on I believe I was able to get the SLO like you’re describing to work. I would make sure your IdP has the Single Logout URL the plugin provides, and that it’s actually sending a logout request to the WordPress site on logout.

If you can sniff your browser traffic and extract the SAML messages, there may be some help to be found there.

Hey Aaron,

The problem you were having is from deep in the SimpleSAMLPHP Library, which has a function that assumes absolute paths will only ever begin with a forward slash. This is true for Linux, but not Windows.

I’ll patch this soon, but in the meantime, you could apply the patch yourself in /content/plugins/saml-20-single-sign-on/saml/lib/SimpleSAML/Utilities.php, line 1088 or so.

Replace the if/else structure you find in that function with this:

/* Check for absolute path. */
		if(substr($path, 0, 1) === '/') {
			/* Absolute path. */
			return $path;
		}
		/* Check for Windows absolute path. */
		elseif( preg_match('/([a-zA-Z]:|\\\\[a-zA-Z0-9])/', substr($path, 0, 3) ) ) {
			/* Either a a drive letter or Windows Share */
			return $path;
		}
		else {
			/* Path relative to base. */
			$ret = $base;
		}

I’ve just quickly tested this in an AWS instance I threw together today, so I would appreciate your feedback on whether this works for you or not.

That fix involves editing the SimpleSAMLPHP library (not my own plugin code), so I’m hesitant to implement the fix without fully understanding its implications. The differences between array_intersect() and array_merge() are obvious, but I want to spend a little more time making sure doing this won’t change any other expected behavior.

I’ve also never worked with an IdP that uses multiple valid audiences, so the whole problem is a little new to me!

0.9.2 has been released, and respects the “redirect_to” parameter of the wp-login.php file. This means you can redirect your users wherever you want, such as sending them directly to the protected post they were just trying to view, or something similar.

Just create a login URL like https://example.com/wp-login.php?redirect_to=%5Bsome-url-encoded-location%5D. The default behavior is still to redirect to the admin URL, so Mark’s one-liner is still necessary if you’d rather people go back to the home page and can’t implement the redirect_to solution above.

0.9.2 is compatible with WP 3.8. I had no issues with 0.9.1 on 3.8 either.

Version 0.9.2 has been released, which gives you an option to use built-in WP authentication side-by-side with SAML authentication. In short, just go to /wp-login.php?use_sso=false to do a traditional login.

The expiration for the plugin’s cookie is 2 hours, so I don’t think that is the source of the problem. The plugin leans heavily on the SimpleSAMLPHP library, so you may also search that project’s forums for a potential solution. For example, this link: https://groups.google.com/forum/#!topic/simplesamlphp/EmfvEBfG3yg

I can’t get the above link to paste un-broken…so don’t bother clicking it and just copy/paste.