As per ADFS : Daemon and Web API on Server 2016 TP4 ADFS 4.0, I made the comment:
"The Azure AD sample relies on scope and NameID claims being returned in the JWT token. This is OK in Azure AD where the claims are static and Azure ID knows the ID of the application which is returned as a GUID in the NameID claim. ADFS AFAIK does not have claims rules for this so I hard coded the NameID. Hopefully, this will be resolved as more documentation is forthcoming."
Then I came across AD FS On-behalf-of Authentication in Windows Server 2016.
As per that article, you have to manually generate the scope claims!
They use the following claims rules:
These match the scope check boxes configured in ADFS in the application group.@RuleName = "All claims" c: => issue(claim = c); @RuleName = "Issue open id scope" => issue(Type = "http://schemas.microsoft.com/identity/claims/scope",Value = "openid"); @RuleName = "Issue user_impersonation scope" => issue(Type = "http://schemas.microsoft.com/identity/claims/scope",Value = "user_impersonation");
This means that every time you alter the scopes you need to alter the claims rules.
Hopefully, this will be fixed before the official release.
The other issue I had was with NameID.
As per that article:
"From AD FS we are issuing the Nmae claim but we are not issuing NameIdentifier claim. The sample uses NameIdentifier to uniquely key in the ToDo items. For simplicity, you can safely remove the NameIdentifier with Name claim in the code. Find and replace all occurences of NameIdentifier wiht Name."
(Spelling as per original article.)
My solution was simply to generate a static NameID. The whole point is to have a unique key into the token store.