@@ -214,3 +214,228 @@ Now that the Service Provider configuration is complete, SimpleSAMLphp creates t
11. Once configured, you should have two Issuance Transform Rules that look as follows:

Testing Authentication
---------------------------------
Now that we have configured SimpleSAMLphp as the service provider, ADFS as the IdP, exchanged metadata between the two and configured some basic claims rules. We are now able to test authentication.
1. Navigate to the simplesaml web application for our site https://sso.lewisroberts.com/simplesaml then select the Authentication tab and click Test configured authentication sources.
2. Select transishun-sp from the list.
3. You will be immediately sent off to the ADFS server (or Web Application Proxy depending on how your ADFS farm is configured). Enter your user ID in the format “domain\user” or “user@domain”.
NB: Now, I’ve cheated slightly, I have enabled Alternate Login ID so I can sign in with my email address. If you see the article I’ve linked to, Microsoft strongly recommend using the mail attribute for sign in. As they say;
One of the benefits of this feature is that it enables you to adopt SaaS providers, such as Office 365 with AAD without modifying your on-premise UPNs. It also enables you to support line-of-business service applications with consumer-provisioned identities.
4. Once signed in, you’ll be bounced back to SimpleSAMLphp and shown your claims. If it all went a bit wobbly, double-check everything and then check the Event Viewer for hints as to what could have gone wrong.
5. Click Logout to test this works as expected – this is where the sign.logout declaration in the Service Provider configuration becomes relevant. ADFS requires the logout to be signed.
6. That looks as though it’s working.
7. Let’s add another claim using the Send Group Membership as a Claim template just to get a little more understanding of what’s happening.
8. After re-authenticating, we can see the group claim is sent through as well.
9. What about our custom PHP application?
Good job you asked, I nearly forgot.
In the previous blog post, I provided some code that I took from the SimpleSAMLphp website. On line 3 of that code when we created a new object, we specified the service provider we wanted to use. It looked like this:
Not to be too cheeky but basically, we would simply change the service provider to, you guessed it, transishun-sp. After doing so, the whole file looks like this:
After changing that, you can test your application and instead of being sent off to Azure AD for authentication, you’ll be sent to the federation service where, after logging on and being sent back to your application, you’ll see something like this – obviously changing depending on the claims you configured.
Hang on, I noticed in the index.php file that the logout link is different than the preceding post’s example. You’re right, it is – why? Well, if you left that Logout link in place, you will indeed be logged out but then you’ll be sent straight back to the application which will need you to log back in again and you’ll be sent off to sign in – not a great user experience.
To overcome this, we can send our user to a different page. It can be done using the getLogoutURL() function but if we wish to be certain the user was logged out, as per the SimpleSAMLphp documentation section 5.3, I would create two files: logout.php and logged_out.php with the following contents. What each file does should be pretty clear.