Wednesday, July 23, 2014

stackoverflow : 500 answers

Finally hit the mark.

If you calculate that I try to answer one question every day and 5 weekdays per week, then:

500 / 5 = 100 weeks ~ 2 years to get here!

Actually, it's taken almost 6 years.

Can do better!


Monday, July 21, 2014

SAML : I want to test my code

This question pops up frequently on the forums.

"I have written my own custom IDP / SP. How can I test it against some instance that's publicly available?"

There are a range of commercial products e.g. Tivoli, Oracle, Ping Identity. OpenAM which all deliver this functionality but they are complex to set up and are most certainly not free.

If you work in the Microsoft world and have a "spare" Windows server that's domain joined you can use ADFS. This runs on 2008 R2, 2012 and 2012 R2 and supports both IDP and SP mode.

Open source:

* Shibboleth 
*    and also Testshib
* simpleSAMLphp

Both these support IDP and SP mode.


SSOCircle - IDP only
Kentor - IDP only
Feide OpenIDP - IDP only
* Salesforce developer - (IDP / SP)

Beware: These are often simplified and some security checks have been removed so the fact that your code works in these environments does not ensure that they will work in the real world.

There are also some commercial / open source implementations for SAML stacks. These often have test IDP and SP that you can run up for basic testing.

ComponentSpace is one example.
onelogin SAML Toolkits - open source

There are others.


Friday, July 18, 2014

ADFS : ADFS and SAML AuthnContext

This article gives an good overview of the subject:

Authentication Handler Overview

You'll see that normally ADFS will set the AuthnContext to something like "urn:oasis:names:tc:SAML:1.0:am:password" for FBA.

So what happens if you have ADFS as a SP and the IDP demands something else?

If you have a ASP.NET application as the RP, you're in luck. All you have to do is set the wauth parameter as per this article:

Windows Identity Foundation (WIF): How to Utilize the WS-Federation WAUTH Parameter to Specify an Authentication Type

I normally do this in the web.config.

It seems counter-intuitive. wauth is a WS-Fed protocol element not a SAML one but ADFS obviously has the intelligence to pass this through to the SAML IDP in the AuthnContext.

What happens if your RP is SharePoint. Sadly, in this case you are fresh out of options. There are many references to this on the web but nobody appears to have a solution.

You pretty much have to add a proxy to add this element or speak nicely to your IDP provider!

Essentially you have to deconstruct the AuthnRequest, add the AuthnContext stuff and then put it all back together. That's basically just vanilla XML manipulation. However, if the agreement is that the AuthnRequest has to be signed, it's a whole new ballgame. You now have to get your hands on the private key of the SP signing certificate and read the SAML specifications to see which part of the AuthnRequest needs to be the signing input.

If you have certificate rollover set in ADFS, you again are screwed, The signing certificate is not in the certificate store. It's some weird combination of a certificate container in AD, a blob in one of the attributes and a link to the ADFS configuration database.

In this case, turn rollover off, generate your own certificates, place them in the certificate store in the usual manner and you are good to go. Remember to give the application account access to the private key. If that's all Greek, refer:

AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates

under the "Manage private keys" section.


Wednesday, July 09, 2014

ADFS : Claims rules and regex

I answer a lot of claims rules questions over on the forum:

and a lot of them concern regex.

One of the recent ones concerned:
"This works fine. I want to filter groups that are included in outgoing claim to just groups which start with string "SG". So I wrote custom ADFS rule:

c:[Type == "", Value =~
"(?i) ^SG*"]
=> issue(claim = c);"

There's a number of tools to check the regex. I tend to use Expresso.

But then I came across an article which showed an easy way to check this in PowerShell.

PS C:\> "SG1234" -match '(?i)^SG*'
PS C:\> "abcSG1234" -match '(?i)^SG*'
PS C:\> "SG1234" -match '(?i)^SG.'
PS C:\> "SG" -match '(?i)^SG.'
PS C:\> "SG" -match '(?i)^SG'

 ... and you can see some of the other strings I played around with.



Friday, July 04, 2014