Wednesday, October 18, 2017

IdentityServer : WS-Fed metadata imported into ADFS

I've been looking at Identity server 4 (idsrv4) just to have a play with it.

This runs on .NET Core which I something else I need to get up to speed on.

There is also a WS-Fed plug-in which I got working and tried to hook up to ADFS as an exercise.

The metadata endpoint is:


and when I tried to import this into ADFS, I got the normal:

"Metadata contains some features not supported by ADFS" warning.

Now this could be because the metadata contains a SAML profile that ADFS doesn't support - PAOS being an example.

But 999 out of 1000 times, it's because the endpoints are "http" not "https".

Looking at the metadata, this is indeed the case.

This means that although the entry is added to ADFS, it has no endpoints so it will never work.

You can't just edit the metadata because it's signed and you'll get a signing error when you try and import the updated file.

You can delete the whole "Signature" section in the XML if you want. Do this at your own risk - normal best practice security applies :-).

The other way is to update the metadata when it's generated. There is no metadata file - it's dynamically generated every time.

You can do this in the "Properties".

Select the "Enable SSL" check box. IIS Express generates a new endpoint as above so now you have to replace all the instances of:


with the https endpoint as above.

This also means that you need to change this address in any of the client samples.

The new metadata imports without issues.


Wednesday, October 11, 2017

ADFS : PowerShell cmdlet - parameter PolicyMetadata

Another question on the forum around the format of PowerShell parameters.

This one was around PolicyMetadata.

Get-AdfsAccessControlPolicy -Name "Demo"

Name           : Demo
Identifier     : Demo
IsBuiltIn      : False
RpUsageCount   : 0
LastUpdateTime : 10/10/2017 7:22:00 PM
Description    :
PolicyMetadata : RequireFreshAuthentication:False
                   Permit everyone
AssignedTo     : {} 

Now if you copy / paste the metadata into a file and then run:

New-AdfsAccessControlPolicy -Name "DemoOne" -PolicyMetadataFile c:\Filename

you get all kinds of errors.

Looking at the errors e.g. "Root error" made me think that the format wasn't JSON, rather XML.

Which means that it is almost impossible to guess the element names etc.

So Mr. Google to the rescue and a long time later, I came across:

(Get-AdfsAccessControlPolicy -Name "Permit everyone").PolicyMetadata | fl *

which displays:

IsParameterized : False
Serialized      : <PolicyMetadata xmlns:i=""
                          <Condition i:type="AlwaysCondition">
                            <Values />
Summary         : RequireFreshAuthentication:False
                    Permit everyone
ExtensionData   : System.Runtime.Serialization.ExtensionDataObject

Putting that into a file e.g.

<?xml version="1.0" encoding="UTF-8"?>
<PolicyMetadata xmlns:i=""
                    <Condition i:type="AlwaysCondition">
                        <Values />

and then running the command works!

I suggest running:


which displays them all and then look at the XML formats to get some hints as to the XML format.


Saturday, October 07, 2017

ADFS : PowerShell cmdlet - parameter is an array

Over on the forum, there was a question around a parameter in the cmdlet that accepts multiple options as an array i.e.

"-RedirectUriSpecifies an array of redirection URIs for the OAuth 2.0 client to register with AD FS".

The question was around the format of the array since that is not specified.

Looking at another example:

Set-AdfsRelyingPartyTrust -TargetName claimapp -ClaimsProviderName @("Fabrikam","Active Directory")

the array is of the form:

@("Fabrikam","Active Directory")


Thursday, October 05, 2017

OAuth2 : Displaying JWT tokens

The standard way that I've been looking at and debugging with JWT tokens is via:

Now, Microsoft have come to the party with:

It starts off with

Then you copy / paste the ID token and it will display the details.

You can see the standard attributes:

or the same thing as claims rules (if this is a more familiar format for you).

And it gives you a bit of extra context.


Friday, September 29, 2017

Auth0 : The connection was disabled

I was trying to set up an enterprise connection in Auth0 to my ADFS instance.

When I tried the "Test" button on the enterprise connection, I got:

"description": "the connection was disabled"


Eventually I realised that this is because I do not have a client that is configured under "Connections" to use that enterprise connection.

Assigned this to a client and viola! all is well.

That error message needs improvement!


Monday, September 25, 2017

ADFS : Pre-populating the user on the login screen

This question often comes up and I came across a site that does this.

Note this is with ADFS 4.0 (Server 2016).

The URL is:


The ADFS login screen then looks like:


Wednesday, September 13, 2017

ADFS : RP default token lifetime

This question keeps coming up.

The default value for TokenLifetime on a RP trust is 0. But what value is 0?

As usual, a heap of garbage via Google.

60 minutes, 300 minutes, 600 minutes, 10 hours ...

Using ADFS 4.0 and looking at a SAML RP, we get:

Conditions        NotBefore="2017-09-12T19:24:01.817Z"

So the correct answer is 1 hour = 60 minutes.

Note: Don't confuse this with the ADFS wide WebSSOLifetime. This is a server wide timeout parameter.

The default value for that = 8 hours = 480 minutes.


Friday, September 01, 2017

Azure B2C : Adding Azure Active Directory (AAD) via custom policies

As I write these are in preview.

The documentation is here.

The AAD guide is here.

And the obligatory warning:

"Custom policies are designed primarily for identity pros who need to address complex scenarios. For most scenarios, we recommend that you use Azure Active Directory B2C built-in policies. Built-in policies are easier to set up for your configuration. You can use built-in and custom policies in the same Azure Active Directory B2C tenant. To learn more, see the overview of custom policies."

and again:

"Custom policy editing is not for everyone. The learning curve is demanding, the startup time is longer, and future changes to custom policies will require similar expertise to maintain. Built-in policies should be carefully considered first for your scenario before using custom policies."

I don't necessarily agree with this and am somewhat puzzled as to why they push this so hard.

The aim should be to encourage people to have a crack at it and learn something rather than scare them away.

I would spend some time reading through the getting started guide and get an overview of how the XML files work, how to upload them etc.

The big drawback about all of these guides is that they publish snippets of XML and it's always hard to figure out the context i.e. where they go in the document and how they relate to the other sections.

So I decided to publish all five files as gists (suitably redacted!).

I have three add-ons:
  • Facebook - from the default policy 
  • ADFS - added but doesn't work because of the self-signed certificate
  • AAD - which works
Note that this was for a PoC where I was just looking at authentication. I haven't looked at the claims passed etc.

Also I did not have an actual application. I just tested using the "Run Now" button.

My B2C page looks like:

Also note that I added Application Insights which I strongly recommend for debugging (in SignUpOrSigninWithAAD.xml).


Azure B2C : Using B2C as an Identity router

B2C has been touted as the successor to ACS but I've always struggled to understand this.

With the advent of custom policies, this is now doable.

Essentially, forget about using B2C as it's supposed to be used i.e. external customer registration and self service password reset.

Just use it as a hub / identity router.

You can configure a policy e.g. sign up / sign in to handle any number of IDP as long as they support OpenID Connect or SAML 2.0. Each of these is configured via XML in the custom policies. Each has a login button on the landing page.

You could almost think of B2C as acting as a pseudo Home Realm Discovery page.

B2C can be branded so it could have the same look and feel as the rest of the corporate pages.

e.g. this is my PoC page.

It allows you to sign up with Facebook, ADFS or Azure AD.

Downstream B2C only allows OpenID Connect so the path would be e.g.

Application --> OIDC --> B2C --> OIDC  --> Facebook
                                                  --> SAML --> ADFS
                                                  --> OIDC  --> AAD

Or if you wanted lots of social providers, you could go OIDC to something like Auth0 and then use their large array of social providers.

So it's pretty much ACS++!

WS-Fed support is on the way.


Thursday, August 31, 2017

Azure B2C : Tracking errors

I've posted before on how crucial Application Insights is to troubleshooting B2C custom policies.

Once you had got it setup, you need to wait about 5 minutes and then run something like:


This displays all the data. You can sort by clicking on the "timestamp column".

 Expand the "message" section.

Expand the "FatalException" section.

and you'll see the error.

If you want to filter the errors, try something like:

| where severityLevel > 0 and message contains "Exception"


Wednesday, August 30, 2017

Azure B2C : Custom policies with ADFS

Azure AD B2C has custom policies in preview that enable you to add extra IDP / social to B2C via an "Identity Framework" that is a collection of XML files that document standards, orchestrations, user journeys etc.

Using this you can add providers that use either SAML or OpenID Connect.

So ADFS 4.0 was a good candidate for OIDC.

As per my SO question:

"I have ADFS 4.0 on an Azure VM and am trying to add ADFS as a provider to my Azure AD B2C tenant.

I have set up all the custom policies.

I am using OpenID Connect as the protocol.

My ADFS SSL certificate is self-signed and I have certificate rollover for the encryption and signing certificates.

The error I get in Application Insights is: 

Exception {"Kind":"Handled","HResult":"80131501",
"Message":"The remote certificate is invalid according to the validation procedure.","Data":{}} Kind Handled HResult 80131501 
Message The remote certificate is invalid according to the validation procedure.

I battled for hours trying to get this to work before asking the question.

Turns out:

"Your ADFS needs to have a valid SSL cert signed by the standard Certificate Authorities in order for Azure AD B2C to communicate with it".

So no self-signed. As this was a proof on concept, I'm not intending to go out and buy a certificate. This is further complicated by the fact that you can't buy a certificate for!

Tip - to debug the custom policies you need Application Insights. Without that, your chances of solving the issues are effectively zero.


Tuesday, August 29, 2017

ADFS : Issue with updating the SSL certificate

Using ADFS 4.0 and updating the SSL certificate.

This is on an Azure VM and I was accessing it remotely.

Ran the normal commands:

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint thumbprint

Set-AdfsSslCertificate -Thumbprint thumbprint

Error :

Set-AdfsSslCertificate -Thumbprint 24f...b35

Set-AdfsSslCertificate : PS0319: Validation task 'Test-_InternalAdfsSslCertificate' on AD FS server 'localhost' failed with error 'Connecting to remote server localhost failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

As per the message, running:

winrm qc

and then re-running the command fixed the problem.