One upon a time way back in 2008, Microsoft came up with a new direction for
authentication and authorisation called "Claims-based
authentication".
They had a new STS (that became ADFS) that had the codename
"Geneva" and a new set of client-side classes to handle the WS-Fed interaction
with Geneva called WIF.
It was announced in a blog post
on November 3rd 2008.
And Vittorio Bertocci came on board as an evangelist to help
spread the word.
To handle all the inevitable teething problems they created a forum.
This was mainly focused on development.
The world rolls on, claims are now mainstream and underpin the Microsoft
stack e.g. Office 365, Azure AD, SharePoint, CRM Dynamics etc.
WIF rolled through to OWIN (Katana) and OWIN is rolling through to IdentityServer in .NET Core.
ADFS 2.0 will shortly become ADFS 4.0 with far more functionality.
The ADFS proxy became WAP.
Vittorio is now a Principal PM with the Azure AD team.
And so this forum has closed.
Which is sad in a way. Looking back through my history, I first started
answering questions in June 2011 - five long years ago.
Since then, I've contributed to almost 700 questions and hopefully helped a
lot of people trying to get to grips with these products.
The content is still fully searchable so all that goodness lives on.
The good news is the forum lives
on in a more focused way.
Hope to see you there!
Enjoy!
Showing posts with label WIF. Show all posts
Showing posts with label WIF. Show all posts
Tuesday, June 14, 2016
Thursday, April 21, 2016
Claims : Azman in the new claims-based world
Refer : Windows Authorisation Manager
"AzMan is available for use in the following versions of Windows: Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP. It is deprecated as of Windows Server 2012 R2 and may be removed in subsequent versions."
"AzMan is a role-based access control (RBAC) framework that provides an administrative tool to manage authorisation policy and a run time that allows applications to perform access checks against that policy. The AzMan administration tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in.
Role-based authorisation policy specifies access in terms of user roles that reflect an application's authorisation requirements. Users are assigned to roles based on their job functions and these roles are granted permissions to perform related tasks.
Authorisation policy is managed separately from an application’s code. The application designer defines the set of low-level operations that are considered security sensitive and then defines a set of tasks that map onto those operations. The tasks, but not the operations, are designed to be understandable by administrators and business analysts."
Windows Server 2003 was way before the era of claims-based authentication and no doubt it had a place then.
Imagine a library. There could be two kinds of people; librarians and users.
Users can browse the catalogue and check in / out books. Librarians can also do those functions plus they can order books. So the list of tasks could be:
Now the steps in ordering a book could be:
So the librarian would first check that there was enough budget, then check that the supplier has stock and then process the order.
There is a hierarchy of Role which has Tasks which has Operations. Each operation has a number.
Now you assign Tasks to Roles and then Operations to Tasks.
Lastly, you then assign users to Roles under "Role Assignments" above.
This is all wrapped up in an Application. As above, in the tree, "Library" is an instance of an application.
You then used .COM objects to get the assignments and you ended up with an array of ints; each element was a binary for the operation of that number e.g. if "Check budget" was numbered one, then the first instance in the array would tell you if the user had permission to perform that operation.
Never having used Azman, I may have some details wrong but they are close enough to illustrate the point.
This is all well and good but how to you migrate this to a modern claims-based world using e.g. ADFS.
ADFS authenticates against Active Directory (AD) and AD does not directly support the above structure.
AD does not have a concept of "application" and I'm ignoring that for the moment as my particular requirement was to migrate an Azman based program that only had one application.
AD does allow a hierarchy of roles (called Groups in AD) e.g. A can be memberOf B can be memberOf C.
The problem is that the groups do not display in a hierarchical manner e.g.
The way this is setup in AD is that:
"Librarian" is a memberOf "Order book" is a memberOf "Check budget".
The user is then a memberOf "Librarian".
In terms of setting up the claims-based application, there are two ways to go:
How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF
where the STS = ADFS.
For OWIN, there is a Azure AD sample:
Integrating a web app with Azure AD using WS-Federation
and then convert to ADFS by using:
Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS.
On the ADFS side, be sure to add an LDAP rule that maps "Token-Groups - Unqualified Names" to "Role".
Using this and by adding the code in the gist to display the claims, my user that has the Librarian Role displays as:
The code can now use the IsInRole construct.
Refer Working with claims-based identities in multi-tenant applications for other ways to look at the claims.
Hopefully, this provides enough of the plumbing to get you across the line during your Azman migration.
Enjoy!
"AzMan is available for use in the following versions of Windows: Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP. It is deprecated as of Windows Server 2012 R2 and may be removed in subsequent versions."
"AzMan is a role-based access control (RBAC) framework that provides an administrative tool to manage authorisation policy and a run time that allows applications to perform access checks against that policy. The AzMan administration tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in.
Role-based authorisation policy specifies access in terms of user roles that reflect an application's authorisation requirements. Users are assigned to roles based on their job functions and these roles are granted permissions to perform related tasks.
Authorisation policy is managed separately from an application’s code. The application designer defines the set of low-level operations that are considered security sensitive and then defines a set of tasks that map onto those operations. The tasks, but not the operations, are designed to be understandable by administrators and business analysts."
Windows Server 2003 was way before the era of claims-based authentication and no doubt it had a place then.
Imagine a library. There could be two kinds of people; librarians and users.
Users can browse the catalogue and check in / out books. Librarians can also do those functions plus they can order books. So the list of tasks could be:
Now the steps in ordering a book could be:
So the librarian would first check that there was enough budget, then check that the supplier has stock and then process the order.
There is a hierarchy of Role which has Tasks which has Operations. Each operation has a number.
Now you assign Tasks to Roles and then Operations to Tasks.
Lastly, you then assign users to Roles under "Role Assignments" above.
This is all wrapped up in an Application. As above, in the tree, "Library" is an instance of an application.
You then used .COM objects to get the assignments and you ended up with an array of ints; each element was a binary for the operation of that number e.g. if "Check budget" was numbered one, then the first instance in the array would tell you if the user had permission to perform that operation.
Never having used Azman, I may have some details wrong but they are close enough to illustrate the point.
This is all well and good but how to you migrate this to a modern claims-based world using e.g. ADFS.
ADFS authenticates against Active Directory (AD) and AD does not directly support the above structure.
AD does not have a concept of "application" and I'm ignoring that for the moment as my particular requirement was to migrate an Azman based program that only had one application.
AD does allow a hierarchy of roles (called Groups in AD) e.g. A can be memberOf B can be memberOf C.
The problem is that the groups do not display in a hierarchical manner e.g.
The way this is setup in AD is that:
"Librarian" is a memberOf "Order book" is a memberOf "Check budget".
The user is then a memberOf "Librarian".
In terms of setting up the claims-based application, there are two ways to go:
- WIF (the older way but still supported)
- OWIN WS-Fed (the newer way)
How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF
where the STS = ADFS.
For OWIN, there is a Azure AD sample:
Integrating a web app with Azure AD using WS-Federation
and then convert to ADFS by using:
Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS.
On the ADFS side, be sure to add an LDAP rule that maps "Token-Groups - Unqualified Names" to "Role".
Using this and by adding the code in the gist to display the claims, my user that has the Librarian Role displays as:
The code can now use the IsInRole construct.
Refer Working with claims-based identities in multi-tenant applications for other ways to look at the claims.
Hopefully, this provides enough of the plumbing to get you across the line during your Azman migration.
Enjoy!
Thursday, March 03, 2016
ADFS : wreply does not redirect after WS-Fed signout
This is with Active Directory Federation services 3.0.
There are literally hundreds of questions around this on the Internet.
Among the comments:
And further "clarification":
And by "exactly", I mean case and all.
Anyway, I needed to get this to work. It took me literally hours but I managed in the end.
So yes, it does work on ADFS 3.0.
My ADFS RP:
The identifier:
https://my-pc/my-app.SSO/
The endpoint:
https://my-pc/my-app.SSO/
WS-Fed signin:
which decoded is:
GET https://my-adfs/adfs/ls/?wa=wsignin1.0&wtrealm=https://my-pc/my-app.SSO/
&wctx=rm=0&id=passive&ru=/my-app.SSO/&wct=2016-03-02T18:35:52Z HTTP/1.1
WS-Fed signout:
which decoded is:
GET https://my-adfs/adfs/ls/?wa=wsignout1.0&wreply=https://my-pc/my-app.SSO/Home/ HTTP/1.1
which results in:
and ADFS redirects to:
which is what I wanted.
You will notice that both the identifier and the endpoint are the same. I suspect that the endpoint is the one that counts. In other words, the identifier could be different.
As per ADFS 2.0 does not redirect back to 'reply' url on signout :
"The wreply URL for signout requests must be a sub-URL of the Passive Requestor Endpoint defined for the RP. The reason: Any other rule would make it more difficult for the user to verify if the signout process has completed correctly, thus opening the door for unintentional information disclosure in the 'public library browser' scenario."
What is a sub-URL?
"A sub URL is simply any page on your website other than your home page. For example if we signed up www.clicksubmit.com then we may also decide to add www.clicksubmit.com/seo as a sub URL."
So in my case, the endpoint is:
https://my-pc/my-app.SSO/
and the wreply is:
https://my-pc/my-app.SSO/Home/
which is a sub-URL.
And this is the URL that ADFS redirects to.
Aside
There is also the matter of the "green tick".
Vittorio has this to say in "Programming WIF".
"What sets apart the cleanup from all other actions I’ve described so far is that it might not end with a redirect. If the message contains a wreply, WSFAM dutifully returns a 302 message to the indicated location; if it doesn’t, it will return an image or .gif of a green check mark."
I couldn't get this to happen.
Update
Then I came across this.
"The Endpoints tab can specify several WS-Federation passive trusted URLs. ADFS takes the value from wreply parameter and tries to match it exactly first. Note that the matching is always case sensitive, just like with any other XML comparisons!
If no exact match is found, ADFS tries to match the wreply URI to any other trusted URL which would possibly be a parent path of the URI specified in wreply.
This applies to any matching, either sign-in or sign-out.
There are literally hundreds of questions around this on the Internet.
Among the comments:
- It never worked
- It only works on ADFS 2.0
- It works fine on ADFS 3.0
And further "clarification":
- The wreply string must match the ADFS identifier exactly
- The wreply string must match the ADFS WS-Fed endpoint exactly
- The wreply string must be a sub-URL of the ADFS WS-Fed endpoint
- You need to include wtrealm
And by "exactly", I mean case and all.
Anyway, I needed to get this to work. It took me literally hours but I managed in the end.
So yes, it does work on ADFS 3.0.
My ADFS RP:
The identifier:
https://my-pc/my-app.SSO/
The endpoint:
https://my-pc/my-app.SSO/
WS-Fed signin:
GET https://my-adfs/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fmy-pc
%2fmy-app.SSO%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fmy-app.SSO
%252f&wct=2016-03-02T18%3a35%3a52Z HTTP/1.1
which decoded is:
GET https://my-adfs/adfs/ls/?wa=wsignin1.0&wtrealm=https://my-pc/my-app.SSO/
&wctx=rm=0&id=passive&ru=/my-app.SSO/&wct=2016-03-02T18:35:52Z HTTP/1.1
WS-Fed signout:
GET https://my-adfs/adfs/ls/?wa=wsignout1.0&wreply=https%3a%2f%2fmy-pc
%2fmy-app.SSO%2fHome%2f HTTP/1.1
which decoded is:
GET https://my-adfs/adfs/ls/?wa=wsignout1.0&wreply=https://my-pc/my-app.SSO/Home/ HTTP/1.1
which results in:
GET https://my-pc/my-app.SSO/?wa=wsignoutcleanup1.0 HTTP/1.1
and ADFS redirects to:
GET https://my-pc/my-app.SSO/Home/ HTTP/1.1
which is what I wanted.
You will notice that both the identifier and the endpoint are the same. I suspect that the endpoint is the one that counts. In other words, the identifier could be different.
As per ADFS 2.0 does not redirect back to 'reply' url on signout :
"The wreply URL for signout requests must be a sub-URL of the Passive Requestor Endpoint defined for the RP. The reason: Any other rule would make it more difficult for the user to verify if the signout process has completed correctly, thus opening the door for unintentional information disclosure in the 'public library browser' scenario."
What is a sub-URL?
"A sub URL is simply any page on your website other than your home page. For example if we signed up www.clicksubmit.com then we may also decide to add www.clicksubmit.com/seo as a sub URL."
So in my case, the endpoint is:
https://my-pc/my-app.SSO/
and the wreply is:
https://my-pc/my-app.SSO/Home/
which is a sub-URL.
And this is the URL that ADFS redirects to.
Aside
There is also the matter of the "green tick".
Vittorio has this to say in "Programming WIF".
"What sets apart the cleanup from all other actions I’ve described so far is that it might not end with a redirect. If the message contains a wreply, WSFAM dutifully returns a 302 message to the indicated location; if it doesn’t, it will return an image or .gif of a green check mark."
I couldn't get this to happen.
Update
Then I came across this.
"The Endpoints tab can specify several WS-Federation passive trusted URLs. ADFS takes the value from wreply parameter and tries to match it exactly first. Note that the matching is always case sensitive, just like with any other XML comparisons!
If no exact match is found, ADFS tries to match the wreply URI to any other trusted URL which would possibly be a parent path of the URI specified in wreply.
This applies to any matching, either sign-in or sign-out.
In case of sign-out though, the matched trusted URL must also be marked as default in order for the log-out redirection to work."
Enjoy!
Enjoy!
Wednesday, January 27, 2016
WIF : IDPInitiated and a WS-Fed application
I discussed IDPInitiated here:
ADFS : SAML redirect to application via relayState and loginToRp
I've been looking at a case where IDPInitiated is used to a WS-Fed application.
The use case is:
IDP --> SAML --> ADFS --> WS-Fed --> Application
IDPInitiated is a SAML feature not supported in WS-Fed but it works in ADFS if you use the RPID construct.
If you set the RPID to the identifier of an RP in ADFS, the user will use IDPInitiated on their IDP to authenticate and this will go to ADFS, ADFS will see they are authenticated and pass the token onto the RP seamlessly.
However, you will get:
ID4216: The ClaimType '' must be of format 'namespace'/'name'.
The reason is discussed here:
AD FS 2.0: The Admin Event Log Shows Error 111 with System.ArgumentException: ID4216
Essentially, WS-Fed uses a SAML 1.1 token and SAML 2.0 uses a SAML 2.0 token and SAML 1.1 is far stricter on the claim type.
It requires:
Note the difference in the attribute name formats.
Apart from this WIF breaks because all the classes expect the stricter URI form.
To sort this out:
On the IDP side, just pass everything through:
c:[]
=> issue(claim = c);
On the RP side, you needs to do a pass-through but using a custom rule e.g.
c:[Type == "EmailAddress"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = c.Value);
That will keep WIF happy :-)
Enjoy!
ADFS : SAML redirect to application via relayState and loginToRp
I've been looking at a case where IDPInitiated is used to a WS-Fed application.
The use case is:
IDP --> SAML --> ADFS --> WS-Fed --> Application
IDPInitiated is a SAML feature not supported in WS-Fed but it works in ADFS if you use the RPID construct.
If you set the RPID to the identifier of an RP in ADFS, the user will use IDPInitiated on their IDP to authenticate and this will go to ADFS, ADFS will see they are authenticated and pass the token onto the RP seamlessly.
However, you will get:
ID4216: The ClaimType '
The reason is discussed here:
AD FS 2.0: The Admin Event Log Shows Error 111 with System.ArgumentException: ID4216
Essentially, WS-Fed uses a SAML 1.1 token and SAML 2.0 uses a SAML 2.0 token and SAML 1.1 is far stricter on the claim type.
It requires:
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue> tom@abc.com </AttributeValue>
</Attribute>
Instead of:
<saml:Attribute Name="EmailAddress"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">tom@abc.com</saml:AttributeValue>
</saml:Attribute>
Note the difference in the attribute name formats.
Apart from this WIF breaks because all the classes expect the stricter URI form.
To sort this out:
On the IDP side, just pass everything through:
c:[]
=> issue(claim = c);
On the RP side, you needs to do a pass-through but using a custom rule e.g.
c:[Type == "EmailAddress"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = c.Value);
That will keep WIF happy :-)
Enjoy!
Monday, October 19, 2015
ADFS : Metadata signing
ADFS and pretty much all half-decent IDP's use metadata to transfer stuff like endpoints, bindings, certificates etc.
Sometimes you need to change some part of the metadata e.g. ADFS won't accept any endpoints that aren't https.
So to be able to import the metadata, you have to edit it.
However, if the metadata is signed, it will throw an error.
This is because the signature is a hash value of the contents so obviously if you change the contents you change the hash value.
What to do?
Note: Below is at your own risk as there may be security implications.
Metadata stands on its own. There are no other files involved, links to web collateral etc. So it stands to reason that if the metadata is signed, the fact that it is signed must be recorded somewhere within the metadata.
And in fact it is.
It use the "ds:Signature", "ds:SignedInfo", "ds:SignatureValue" etc. constructs.
So to remove the signature protection, simply delete the entire "ds:Signature" construct, Now you can change anything you want. And by extension so can anybody else!
To repeat: Use at your own risk as there may be security implications.
Enjoy!
Sometimes you need to change some part of the metadata e.g. ADFS won't accept any endpoints that aren't https.
So to be able to import the metadata, you have to edit it.
However, if the metadata is signed, it will throw an error.
This is because the signature is a hash value of the contents so obviously if you change the contents you change the hash value.
What to do?
Note: Below is at your own risk as there may be security implications.
Metadata stands on its own. There are no other files involved, links to web collateral etc. So it stands to reason that if the metadata is signed, the fact that it is signed must be recorded somewhere within the metadata.
And in fact it is.
It use the "ds:Signature", "ds:SignedInfo", "ds:SignatureValue" etc. constructs.
So to remove the signature protection, simply delete the entire "ds:Signature" construct, Now you can change anything you want. And by extension so can anybody else!
To repeat: Use at your own risk as there may be security implications.
Enjoy!
Friday, October 16, 2015
WIF : Wrappers around protocols
Put together this diagram:
So what does this show:
WIF = WS-Fed
OWIN = WS-Fed, OpenID Connect, OAuth
There is no official Microsoft support for SAML-P (P for protocol). There are open source libraries and commercial stacks - refer : SAML : SAML connectivity / toolkit.
Just to repeat - WIF and OWIN are not protocols - they are wrappers around protocols.
Enjoy!
So what does this show:
WIF = WS-Fed
OWIN = WS-Fed, OpenID Connect, OAuth
There is no official Microsoft support for SAML-P (P for protocol). There are open source libraries and commercial stacks - refer : SAML : SAML connectivity / toolkit.
Just to repeat - WIF and OWIN are not protocols - they are wrappers around protocols.
Enjoy!
Friday, September 25, 2015
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:
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.
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!
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!
Tuesday, September 15, 2015
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!
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!
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:
The normal causes (according to the searches) are:
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!
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!
Monday, September 14, 2015
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.
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!
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:
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!
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
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!
Friday, September 11, 2015
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:
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.
That seemed to do the trick.
Enjoy!
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!
Wednesday, August 05, 2015
WIF : Federation Metadata Generation Tools
This question pops up frequently on various forums:
How do I generate metadata?
So I thought I'd collect a few links:
(Note: I haven't tried all of these - they may or may not work - use at your own risk - backup current metadata first if required).
Federation Metadata Generation Tool
STS Federation Metadata Editor
Also, have a look at the code inside:
Identity Server
You will see that it's generated dynamically.
Geneva-based WS-Federation metadata document generation wizard
Enjoy!
How do I generate metadata?
So I thought I'd collect a few links:
(Note: I haven't tried all of these - they may or may not work - use at your own risk - backup current metadata first if required).
Federation Metadata Generation Tool
STS Federation Metadata Editor
Also, have a look at the code inside:
Identity Server
You will see that it's generated dynamically.
Geneva-based WS-Federation metadata document generation wizard
Enjoy!
Thursday, May 14, 2015
Visual Studio : No STS tool
Inspired by this question on stackoverflow regarding the missing STS tool in VS 2013:
Add sts reference missing in visual studio 2013 update 4
From my answer:
"FedUtil and the "Identity and Access Tool" are no longer available.
The only way to do this is via "Change Authentication" when you create the project and then select "On Premise". Unfortunately, you can only do this when you create the project. You can't retrofit it afterwards. I believe this is changing in VS 2015.
Part of the reason for the tools disappearing is that these tools were WIF based whereas OWIN is the basis for all new VS development.
You can merge the WIF section from the web.config of an old WIF project"
So how do you do the last part.
Create a new project in VS 2013 - I choose MVC - and under "Change Authentication" select "No authentication".
Now find a VS2012 project of yours that uses WIF - with .NET 4.5
Use something like WinMerge and merge the two web.config.
Copy these over:
as well as the "ida:" lines under appSettings
and the entire system.identitymodel and system.identitymodel.services sections.
Obviously you need to update the URL of your target application .( I assume your IDP and certificates are still the same and are still valid otherwise you need to update them as well).
Add References to:
Add a NuGet package from Package Manager:
Install-Package System.IdentityModel.Tokens.ValidatingIssuerNameRegistry -Version 4.5.0
and you are done.
Enjoy!
Add sts reference missing in visual studio 2013 update 4
From my answer:
"FedUtil and the "Identity and Access Tool" are no longer available.
The only way to do this is via "Change Authentication" when you create the project and then select "On Premise". Unfortunately, you can only do this when you create the project. You can't retrofit it afterwards. I believe this is changing in VS 2015.
Part of the reason for the tools disappearing is that these tools were WIF based whereas OWIN is the basis for all new VS development.
You can merge the WIF section from the web.config of an old WIF project"
So how do you do the last part.
Create a new project in VS 2013 - I choose MVC - and under "Change Authentication" select "No authentication".
Now find a VS2012 project of yours that uses WIF - with .NET 4.5
Use something like WinMerge and merge the two web.config.
Copy these over:
<configSections>
<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</configSections><system.web>
<authentication mode="None" />
<authorization>
<deny users="?" />
</authorization>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web><system.webServer>
<modules>
<add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
<add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
</modules>
</system.webServer>as well as the "ida:" lines under appSettings
and the entire system.identitymodel and system.identitymodel.services sections.
Obviously you need to update the URL of your target application .( I assume your IDP and certificates are still the same and are still valid otherwise you need to update them as well).
Add References to:
- System.IdentityModel
- System.IdentityModel.Selectors
- System.IdentityModel.services
Add a NuGet package from Package Manager:
Install-Package System.IdentityModel.Tokens.ValidatingIssuerNameRegistry -Version 4.5.0
and you are done.
Enjoy!
Wednesday, March 11, 2015
WIF : WIF10201: No valid key mapping
The full error is:
WIF10201: No valid key mapping found for securityToken: 'System.IdentityModel.Tokens.X509SecurityToken' and issuer: 'http://xxx/adfs/services/trust'.
This is with ADFS 3.0 and the base VS 2013 with ASP.NET MVC.
Long discussion with Mr. Google - many entries, many explanations - "remove the trailing slash" , blah, blah, the most bizarre was "This is because WIF doesn't support SAML".
Yes - that statement's true but WTF does it have to do with the problem?
Google quality is getting exponentially worse and worse.
I knew this error rang a bell and after some quite reflection I remembered why. Vittorio had mentioned it:
His article didn't apply in my case because I get the error straight away - the home page doesn't display so there's no "Sign up for this application" link.
The article goes on to say that this "issue will be fixed soon".
So I took a punt and upgraded to VS 2013 Update 4.
Created a new project - problem solved.
Enjoy!
Monday, June 30, 2014
ADFS : VS 2013 and FedUtil
In VS 2013, there was a wizard called FedUtil which handled the "binding" between your WIF project and ADFS, sorted out the web.config configuration etc.
In VS 2012, this wizard was called the "Identity and Access Tool"
In VS 2013, there was - oh that's right - nothing!
But, fear not, there is a way.
Using VS 2013 Update 2:
When the project is created, you'll see the web.config has been updated.
Enjoy!
In VS 2012, this wizard was called the "Identity and Access Tool"
In VS 2013, there was - oh that's right - nothing!
But, fear not, there is a way.
Using VS 2013 Update 2:
- Create an ASP.NET Web Application
- Click "Change Authentication"
- Select the "Organisational Accounts" radio button
- In the "Cloud - Single Organisation" drop down - select "On-Premises"
- Under "On-Premises Authority", enter the ADFS Metadata URL
- Under "App ID URI", type the identifier or leave blank for default
- Click "OK"
- Back on the "New ASP.NET Project" screen, Authentication should say "Organisational Auth (On-Premises)"
- Click OK
- Done
When the project is created, you'll see the web.config has been updated.
Enjoy!
Wednesday, April 16, 2014
ADFS : Getting certificate data from metadata
A number of times I've needed to get information about the certificate e.g. to update the WIF thumbprint in the web.config and I've battled to extract this out of the metadata.
For ADFS, you'll find it at:
https://someserver/FederationMetadata/2007-06/FederationMetadata.xml
For Azure Active Directory, you'll find it at:
Then I found an easy way to do this based on a post I read.
Open the metadata file in Notepad++ or whatever your particular flavour is and then search for the "X509Certificate" tag.
Copy all the information between that and the closing tag. It's base64 encoded so it will normally end with an "=" sign.
Copy / paste this into a new Notepad++ window. Remove all trailing spaces.
Save the file somewhere with a ".cer" suffix.
Then double-click on the file.
Viola - it opens up the certificate window and you can grab whatever you want.
The thumbprint is found under the "Details" tab - scroll down to the bottom.
Enjoy!
For ADFS, you'll find it at:
https://someserver/FederationMetadata/2007-06/FederationMetadata.xml
For Azure Active Directory, you'll find it at:
- Click on "Active Directory" in the menu on the LHS of the Azure Portal.
- Click on your tenant name.
- Click on the "Applications" tab at the top.
- Click on "View Endpoints" at the bottom.
- Then navigate to the "Federation Metadata Document" link.
Then I found an easy way to do this based on a post I read.
Open the metadata file in Notepad++ or whatever your particular flavour is and then search for the "X509Certificate" tag.
Copy all the information between that and the closing tag. It's base64 encoded so it will normally end with an "=" sign.
Copy / paste this into a new Notepad++ window. Remove all trailing spaces.
Save the file somewhere with a ".cer" suffix.
Then double-click on the file.
Viola - it opens up the certificate window and you can grab whatever you want.
The thumbprint is found under the "Details" tab - scroll down to the bottom.
Enjoy!
Thursday, February 13, 2014
Visual Basic : A VB claims-enabled application
There was a question over at the MSDN forum that intrigued me so I thought I would take a crack at it.
The question was: "Looking at the ADFS sdk I found ClaimsAwareWebsite in C#. Is there an example in VB.net as well?".
Disclaimer - the last time I used VB was many, many moons ago.
Ok - so ADFS is the same, WIF is the same, the .NET Framework is the same so it shouldn't be that difficult - right?
I used VS 2012 with "Identity and Access Tool" added.
Take a look here: How To: Build Claims-Aware ASP.NET Application Using Forms-Based Authentication.
OK so we create a new project but select "Other languages / Visual Basic / Web. Then select "ASP.NET Web Forms Application". You could go MVC - I'm more at home with Forms (Yeah - I know :-) ).
OK, that gives us the base project. Now use the "Identity and Access Tool" to "bind" your application to ADFS or wherever. Many references of the web to do this - it's language agnostic. And remember to add your new application as a RP in ADFS.
When you run up your application, you should be prompted for the logon screen.
Sweet!
Now in Step 2 in the above link, add the html exactly as described to Default.aspx.
Remember F7 / Shift F7 swops between code and designer.
You can convert the C# code-behind in Step 2 to VB using e.g. Convert C# to VB.NET .
My page (for reference) was:
------------------------------
Imports System.Web.UI
Imports System.Security.Claims
Public Class _Default
Inherits Page
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Dim claimsPrincipal As ClaimsPrincipal = TryCast(Page.User, ClaimsPrincipal)
If claimsPrincipal IsNot Nothing Then
Me.ClaimsGridView.DataSource = claimsPrincipal.Claims
Me.ClaimsGridView.DataBind()
End If
End Sub
End Class
---------------------------
After you have been redirected to the home page after logging in, you should see a table that includes the Issuer, OriginalIssuer, Type, Value, and ValueType claims information about your account.
Enjoy!
The question was: "Looking at the ADFS sdk I found ClaimsAwareWebsite in C#. Is there an example in VB.net as well?".
Disclaimer - the last time I used VB was many, many moons ago.
Ok - so ADFS is the same, WIF is the same, the .NET Framework is the same so it shouldn't be that difficult - right?
I used VS 2012 with "Identity and Access Tool" added.
Take a look here: How To: Build Claims-Aware ASP.NET Application Using Forms-Based Authentication.
OK so we create a new project but select "Other languages / Visual Basic / Web. Then select "ASP.NET Web Forms Application". You could go MVC - I'm more at home with Forms (Yeah - I know :-) ).
OK, that gives us the base project. Now use the "Identity and Access Tool" to "bind" your application to ADFS or wherever. Many references of the web to do this - it's language agnostic. And remember to add your new application as a RP in ADFS.
When you run up your application, you should be prompted for the logon screen.
Sweet!
Now in Step 2 in the above link, add the html exactly as described to Default.aspx.
Remember F7 / Shift F7 swops between code and designer.
You can convert the C# code-behind in Step 2 to VB using e.g. Convert C# to VB.NET .
My page (for reference) was:
------------------------------
Imports System.Web.UI
Imports System.Security.Claims
Public Class _Default
Inherits Page
Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
Dim claimsPrincipal As ClaimsPrincipal = TryCast(Page.User, ClaimsPrincipal)
If claimsPrincipal IsNot Nothing Then
Me.ClaimsGridView.DataSource = claimsPrincipal.Claims
Me.ClaimsGridView.DataBind()
End If
End Sub
End Class
---------------------------
After you have been redirected to the home page after logging in, you should see a table that includes the Issuer, OriginalIssuer, Type, Value, and ValueType claims information about your account.
Enjoy!
Thursday, October 31, 2013
Visual Studio : Version issues
Once upon a time, we had VS 2010 and a tool called FedUtil which could be run many times to change the WIF parameters for different hosts, certificates etc.
Also, FedUtil could be run standalone so you could use it on different boxes when you promoted a build from e.g. Dev to Test.
There was no internal STS so we all used SelfSTS.
Then we had VS 2012, where FedUtil morphed to the "Identity and Access Tool" which added some capability but could no longer be run standalone. The "Identity and Access Tool" could be run many times.
It included an internal STS.
Now we have VS 2013 which has a "Change Authentication" feature invoked when you create a project.
There is no internal STS.
You cannot run it standalone and worse of all you cannot run it after the project has been created.
So what happens when I want to migrate my VS 2012 projects to VS 2013?
This SUCKS massively big time.
Is there anyone at Microsoft that actually uses these tools in the real world. Because if there was they wouldn't introduce such restrictions.
Seriously people, get your stuff together!
If you agree, vote here:
In VS 2013, allow ability to run the "Change Authentication" wizard AFTER project is created
Enjoy!
Also, FedUtil could be run standalone so you could use it on different boxes when you promoted a build from e.g. Dev to Test.
There was no internal STS so we all used SelfSTS.
Then we had VS 2012, where FedUtil morphed to the "Identity and Access Tool" which added some capability but could no longer be run standalone. The "Identity and Access Tool" could be run many times.
It included an internal STS.
Now we have VS 2013 which has a "Change Authentication" feature invoked when you create a project.
There is no internal STS.
You cannot run it standalone and worse of all you cannot run it after the project has been created.
So what happens when I want to migrate my VS 2012 projects to VS 2013?
This SUCKS massively big time.
Is there anyone at Microsoft that actually uses these tools in the real world. Because if there was they wouldn't introduce such restrictions.
Seriously people, get your stuff together!
If you agree, vote here:
In VS 2013, allow ability to run the "Change Authentication" wizard AFTER project is created
Enjoy!
Wednesday, September 04, 2013
ADFS : MSIS7042: The same client browser session has made '6' requests in the last '1' seconds.
Out of the blue, got this problem.
WTF?
So reviewed my changes to date.
I had made a change to fix the ubiquitous problem:
ID3206: A signin response may only redirect within the current web application
If you have played with WIF, you will have seen this particular problem.
The solution is BTW:
Add this to the global.asax
After googling around, I found the problem.
In my ADFS RP, I had configured the endpoint without a trailing slash.
Added the missing "/" and all was well.
Enjoy!
WTF?
So reviewed my changes to date.
I had made a change to fix the ubiquitous problem:
ID3206: A signin response may only redirect within the current web application
If you have played with WIF, you will have seen this particular problem.
The solution is BTW:
Add this to the global.asax
private void Application_BeginRequest(object sender, EventArgs e)This seemed to have fixed the bug but then introduced another - the dreaded slippery slope.
{
if (String.Compare(Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0 && !(Request.Path.EndsWith("/")))
Response.Redirect(Request.Path + "/");
}
After googling around, I found the problem.
In my ADFS RP, I had configured the endpoint without a trailing slash.
Added the missing "/" and all was well.
Enjoy!
Subscribe to:
Posts (Atom)