WIF : Replacement for SelfSTS.

If you've been around like I have since the early days of WIF 1.0, VS 2010 and FedUtil, you will know about Vittorio's magic tool called SelfSTS which provided a really simple STS with configurable claims that you could use for testing without the hassle of running up a real IDP.

And then it disappeared and there was much chaos in the ranks over at stackoverflow.

There was also the "Identity and Access Tool" from VS 2012 - also late lamented and gone.

I found EmbeddedSts from thinktecture a while back but ran it up recently when I needed a quick STS for prototyping and was impressed.

It uses the .NET 4.5 library.

It's a NuGet package installed via:

Install-Package Thinktecture.IdentityModel.EmbeddedSts

There is a json file called "EmbeddedStsUsers.json" in the application's App_Data folder, If it's not there, it simply creates one viz:

Then you change the WIF web.config entry e.g.

wsFederation passiveRedirectEnabled="true" issuer="https://EmbeddedSts" realm="https://xxx" requireHttps="true" 

and when you access the application, you get:

Depending on who you sign on as, you get a different set of claims.

Note: Just like SelfSTS, you don't actually have to authenticate by typing in a user name and password. Clicking the "Sign In" button automatically generates a SAML token.

Very neat!

Enjoy!

Certificates : Getting User and Local Computer stores

For Windows 8 upwards, you can get this from the Modern Tiles method (thanks to Brady Gaster for the tip).

Search for user,cer and then click on "Manage user certificates".

You then get the "Current User" portion of the usual mmc plug-in.

Search for computer,cer and then click on "Manage computer certificates".

You then get the "Local Computer" portion of the usual mmc plug-in.

Enjoy!

WIF : Welcome exclamation mark!

How many times have you seen this in your ASP.NET project?

The reason for this is that the application is expecting a Name claim i.e.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

In ADFS, you can do this in the claims rules by mapping "Display-Name" to "Name".

Enjoy!

Certificates : Finding a certificate by the thumbprint (or other attributes)

I was having issues with a WIF web.config issue. The web.config had a thumbprint and I couldn't find the actual certificate in the ADFS server certificate store.

Duh - the ADFS encryption and signing certificates are not stored there if you use certificate rollover. They are apparently stored in the ADFS DB or in AD in a certificate container or .. There's a number of inconclusive posts on this matter.

But it did lead to me learning something about how to find a certificate from the thumbprint.

You you use the certificate plugin from mmc.

Right-click in the top level and then "Find Certificates".

Then you can put a thumbprint (or part of one) and search on "SHA1 Hash". There are other parameters you can search on as well.

You'll then get a list of the certificates that match and if you scroll over to the right, the stores that they are contained in.

Or you can use PowerShell from the root directory.

 dir -recurse | where {$_.Thumbprint -eq "5D278138246AE7E7C71F580F07E1BCEC6AA4D27E"} | Format-List -property *

where the thumbprint is the one you are looking for.

Or you can use Raf's amazing utility "Deploy Manager":

DeployManager June 2011 edition

Just remember to run it in Admin. mode.

It bears repeating that you can also extract the certificates from the ADFS metadata.

ADFS : Getting certificate data from metadata

Enjoy!

WIF : ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry

You see this error a lot and there's a zillion entries on the Internet about how to fix it.

This relates to the certificate details in the web.config i.e this entry:

trustedIssuers
          add thumbprint="0659B14B1AB76A495V53998E45986C7610294207" name="http://xxx/adfs/services/trust" /

The normal causes (according to the searches) are:

• You cannot copy and paste from the "Certificate Details" thumbprint because there are hidden characters
• You must make the letters all capital
• You must remove the quotes as well when you copy / paste and then replace them

And some others too ridiculous to mention.

I've found the the first one is the main reason. Copy the thumbprint into something like Notepad, remove the spaces between the two letter / digit groups and then paste into the web.config.

Came across a weird problem recently. I did all the above and still kept getting the error. WTF?

I go back to VS 2010 and run FedUtil. It now suddenly works. I look in the web.config and see another entry. Aha - certificate rollover.

For the period of transition, there are actually two certificates - one primary and one secondary. The safest way is to put both in the web.config. i.e there are two "add thumbprint" entries.

Enjoy!
  

OWIN : Differences with WIF

This causes a lot of confusion and people keep asking me about this so I thought I would create a tabular comparison.

I'm specifically talking about the NuGet Identity components in OWIN.

OWIN (Identity)	WIF
Fully supported with new features being added	Supported – bugs will be fixed. No new features
WS Fed / SAML / OpenID Connect / OAuth	WS Fed
API’s via code	Invoked via ASP.NET event pipeline
JWT token	XML token
“Change Authentication” with Visual Studio 2013 and 2015	FedUtil with Visual Studio 2010 and “Identity and Access Tool” with Visual Studio 2012

You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.

It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical.

Enjoy!

WIF : Options for client-side SAML stack

Working with a customer who had developed a .NET 3.5 client side SAML-P stack.

It was buggy and too cumbersome to maintain. Also, the stack acted as a kind of R-STS in that it had various SAML connections to other IDP that it managed.

So what alternatives do they have:

• Keep SAML - purchase a commercial stack
• Keep SAML client side - purchase a commercial stack - move the IDP connections to ADFS - communicate to ADFS via SAML
• Keep SAML client side - use OWIN SAML (Community - not developed by Microsoft) - move the IDP connections to ADFS - communicate to ADFS via SAML
• Ditch SAML client side - use WIF - move the IDP connections to ADFS - communicate to ADFS via WS Federation
• Ditch SAML client side - use OWIN WS Federation - move the IDP connections to ADFS - communicate to ADFS via WS Federation

Just adding ADFS to the mix increases the security about a zillion per cent.

Also it allows mix and matching of metadata i.e. the client and IDP side's metadata does not have to match - essentially ADFS acts as a bridge.

And it future proofs the solution in that now that ADFS is in the mix, you now have social, Azure AD, ACS etc.

Enjoy!

ADFS : HttpException (0x80004005) : Failed to Execute URL

Got this exception on a web site (SP) talking to ADFS 2012 R2 using SAML-P 2.0.

So long conversation with Mr. Google.

The garbage that comes up on these searches these days is ridiculous  It takes you hours to sift through all the dross.

Suggested actions:

• Change the IIS pipeline mode to Integrated instead of Classic for the site.
• Send a dummy Name claim.
•  How To Resolve HttpException (0x80004005): Failed to Execute URL

The last one looked like a no-brainer because it specifically talks about a site behind ADFS. Except ... it didn't work.

The second was the suggestion from:

Failed to Execute URL Exception when on windows 2003 relying party with IIS 6 .

@paullem suggested that it was because the Name claim was null. The fix was to add a dummy claim inside CAM (the Claims Authentication Manager).

I was using ADFS and the Name claim wasn't used to I simply ran up a static claim i.e.

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Value = "Joe Bloggs"); 

That seemed to do the trick.

Enjoy!

ADFS : Self-signed certificates

If you do any work for ADFS, you'll know that these are a PIA.

You can use IIS but they are only valid for a year and ADFS no longer uses IIS in Server 2012 R2 so it's more effort to install.

There is always makecert but you have to jump through some hoops.

Then I came across this article:

Creating Self Signed Certificates with PowerShell

Fantastic - problem solved.

So the next time I did an install, I used it.

DAMN - ADFS rejects it because ADFS does not like CNG certificates (i.e. Certificate Next Generation).

Oh well - back to SelfSSL7.

Enjoy!