ADFS Single Sign On with WordPress

8 mei 2014

We have recently deployed ADFS 2.0 and we needed to provide an SSO to our WordPress blog site. In particular the following had to be done to make this work:

1.Install and activate the plugin...

2.Go to Settings -> Single Sign-On and click the Identity Provider tab.

3.Under "Autofill using Metadata," enter your ADFS metadata URL and click Fetch Metadata. The default SAML 2.0 metadata URL for ADFS is https://your-idp.net/FederationMetadata/2007-06/FederationMetadata.xml +http see screen shot.

We also added http because the event log was asking for it.


4.Ensure that, at a minimum, the "URL Identifier", "Single Sign-On URL", and "Certificate Fingerprint" fields are populated.

5.Go to the Service Provider tab.

6.Upload your own certificate and private key or check the box to "Generate a new certificate and private key for me".

7.Under "Attributes", click ADFS 2.0 to fill the attribute fields with attributes that are suitable for use with ADFS.

8.Under "Groups", enter the names of security groups and the WordPress roles that their respective users should have. This should be the short form of the group name. For example, you might put "Domain Admins" in the Administrators field and "Domain Users" in the Subscribers field.

9.Click Update Options.

10.Go to the General tab.

11.Copy the URL in the box labeled "Your Entity ID" to the clipboard.

12.In the ADFS 2.0 Management console, under Trust Relationships/Relying Party Trusts, click Add Relying Party Trust.

13.In the Add Relying Party Trust Wizard, click Start.

14.Paste the URL you copied in step #11 to the "Federation metadata address" field. Click Next. You should see a message that some of the metadata is not supported by ADFS. Click OK to dismiss the message.

15.Change the display name if you want to and click Next.

16.Choose an Issuance Authorization Rule and click Next.

17.Click Next again to add the data to the ADFS configuration database. Click Close to close the wizard.

18.Right-click on the newly-added Relying Party Trust and click Properties.

19.On the Monitoring tab, un-check the box to "Monitor the Relying Party" and click Apply. This will allow you to manually modify its settings.

20.On the Encryption tab, click Remove to disable claims encryption. This plugin does not currently support encrypted claims.

21.On the Advanced tab, set the secure hash algorithm to SHA-1. Click OK to save your changes.

22.Back at your WordPress site, on the General tab, check the box to "Enable SAML authentication" and click Update Options.

Setting up Claim Rules in ADFS 2.0.

Here are the claim rules that we used:

Rule 1: (Using "Send LDAP Attributes as Claims" template)

◾SAM-Account-Name => Windows account name

◾Given-Name => Given Name

◾Surname => Surname

◾E-Mail-Addresses => E-Mail Address

◾Token-Groups - Unqualified Names => Group

Rule 2: (Using "Transform an Incoming Claim" template)

◾Incoming claim type: E-Mail Address

◾Outgoing claim type: Name ID

◾Outgoing Name ID format: Email

◾Pass through all claim values

Be sure/check that in the Active Directory the requested fields 'e-mail' are filled in with a correct e-mail  adres of the user account. Otherwise the user can not login!

Now you are done, but in our case it didn’t work we get error:

System.IdentityModel.SignatureVerificationFailedException: MSIS0038: SAML Message has wrong signature. Issuer:

For this error we have to install Microsoft KB Article http://support.microsoft.com/kb/2896713. We also installed all the latest updates. After installing the hotfix the error was gone.

Now that error was fixed we had a other one:

MSIS1000: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properties: null.This request failed.User Action

Use the AD FS Management snap-in to configure the configuration that emits the required name identifier.

For this error we removed claim rule1 & 2 and recreated them.

Now our Single Sign on is working perfectly.

In summary,

Follow this blog and it will work. For questions just contact us.

Johan Biere (@johanbiere) & Daan Huttenga (@daanhut)




Submit a comment

Dit vind je vast ook interessant.