The art of simplicity

After authenticating through WIF, a FedAuth cookie is generated containing all your claims. We got a situation where this caused issues as the same cookie name was used for different applications. One FedAuth cookie was generated at the root level and was applicable for all sub sites. Every site generated it’s own FedAuth cookie that was applicable for that specific subsite only. This caused conflicts when you navigate from one of the subsites to the root site. As a FedAuth cookie is found, it is used to try to extract the claims. But this doesn’t work as the cookie isn’t generated for this website. To fix it, we changed the cookiename in the WIF configuration to use a different name and avoid name collisions: This can be done by setting the name attribute on the cookiehandler(more info: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/windows-identity-foundation/cookiehandler )

By default WIF uses a built-in SessionSecurityTokenHandler to serialize the session token to and from the cookie. Behind the scenes this tokenhandler uses the Data Protection API (DPAPI) to protect the cookie material. DPAPI uses a key that is specific to the computer on which it is running in its protection algorithms. For this reason, the default session token handler is not usable in Web farm scenarios because, in such scenarios, tokens written on one computer may need to be read on another computer. As a solution you can switch the default SessionSecurityTokenHandler by a machine key based alternative: After doing that, there is one extra step required. The default IIS configuration autogenerates a machine key per application pool. To generate a specific key and copy it to all server instances on your web farm, remove the checkboxes next to the ‘Automatically generate at runtime’ option and choose Generate Keys from the action menu on the right. Now you can copy and ...

While documenting our security and privacy policies for GDPR, I got a question about the Windows Identity Foundation cookies created after logging into ADFS. When looking in the Chrome Developer tools, we noticed that the Expires/Max-Age setting was set to 1969-12-31…: We were wondering why this strange date? When I opened the same site in Edge, I saw the following in the Edge Developer Tools: The cookie lifetime is set to Session, which makes more sense. Probably the Chrome Developer Tools are showing a minimum date when the cookie lifetime is linked to the session. Kind of confusing…

At one of my clients we are (still) using ASP.NET MVC 5 and Web API 2. To secure these web applications we use the WSFederation OWIN middleware together with ADFS. This combination works nice and helps us keeping our applications secure. Today one of the teams contacted me and complained that the middleware no longer worked. The error message they got looked like this: Could not load type 'System.IdentityModel.Tokens.TokenValidationParameters' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The root cause of the problem could be found in the version number, they accidently upgraded the System.IdentityModel.Tokens.Jwt assembly from version 4 to 5. It turns out that version 5 is no longer compatible with OWIN. After reverting back to version 4, everything returned back to normal…

To validate a new installation of ADFS, we created a small sample app that used Windows Identity Foundation to authenticate to the ADFS server. We got most information from our system administrator, but it turned out that the Issuer Thumbprint was missing. As the system administrator wasn’t in the office, we had to find a different solution to get the thumbprint. Here is what we did: By default every ADFS server exposes its metadata through a metadata xml. Typically the url where you can find this metadata xml will be something like https://adfs4.sample.be/federationmetadata/2007-06/federationmetadata.xml Inside this XML you can find the signing and encryption certificates: To read out the certificate information(and the thumbprint) you have to Create a new text file Copy the certificate value into the file Save the file with a .cer extension Now you can open the file, and read out the thumbprint value: Double click on th...

I’m talking to a WCF service and use a bearer token to authenticate to the service. The bearer token is provided by a custom STS (during testing). However when I tried to invoke the service, I got the following error message back: The X.509 certificate CN=LocalSTS chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. And indeed this error makes sense as the tokens generated by the local STS are signed by an untrusted certificate. As we are using it for testing purposes only, it’s OK to disable the certificate validation. Open the configuration of your webservice. Add a serviceCredentials block to your serviceBehavior. Inside this block add an issuedTokenAuthentication section and set the certificateValidationMode to “ None ”. That should do ...

By default WCF uses symmetric encryption for token validation. However in our situation we were using a custom STS that created bearer tokens. This means that we don’t provide any proof about our identity. When we tried to use the token to call a WCF service we got the following error message: The signing token Generic XML token:    validFrom: 10/31/2016 10:52:49    validTo: 10/31/2016 11:52:49    InternalTokenReference: SamlAssertionKeyIdentifierClause(AssertionId = '_129cb505-83f0-4af0-a455-c51b51926d3a')    ExternalTokenReference: SamlAssertionKeyIdentifierClause(AssertionId = '_129cb505-83f0-4af0-a455-c51b51926d3a')    Token Element: (Assertion, urn:oasis:names:tc:SAML:1.0:assertion) has no keys. The security token is used in a context that requires it to perform cryptographic operations, but the token contains no cryptographic keys. Either the token type does not support cryptographic operations, or th...

After configuring my ASP.NET MVC application to use WSFederation with WIF, I was finally ready to run the app the first time. However instead of redirecting me to the configured STS and showing me a login page I ended up with a 401 Unauthorized error page. I first thought that the required HTTP modules were missing, but no they were there: Let’s have a look at the WIF configuration: There is definetely something wrong here, but I had a hard time figuring out what. The problem is related to the passiveRedirectEnabled configuration setting. If you set passiveRedirectEnabled to false , WIF will no longer be responsible for the redirections to your issuers. That explained a lot! Switching the setting to true solved my issue and I was finally welcomed by my STS login page…

I’m currently working on a training for one of my customers covering WIF(Windows Identity Foundation),  OIDC(Open ID Connect) and some other security related topics on top of the .NET stack. Yesterday I got a strange problem after configuring the MVC application that should act as the relying party. Here is the WIF specific configuration: And here is the error I got when I ran the application: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer. I compared the thumbprint of the certificate used by the STS with the thumbprint inside the config: <trustedIssuers>          <add thumbprint=" 6b 7a cc 52 03 05 bf db 4f 72 52 da eb 21 77 cc 09 1f aa e1 " /> </trustedIssuers> No matter how much I looked, I couldn’t see a differe...

Last week I had some fun investigating a WIF issue. A colleague came to me and explained the following situation: I have 2 sites under the same domain each configured as a separate application in IIS with their own applicationpool. Site 1 is available at my.domain.name/Site1. The other site is available at my.domain.name/Portal/Site2. When I login to site 1 through ADFS everything is ok. Then I go to site 2 where I also login. When I then move back to Site 1, I get the following error message: The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. When I investigated the issue, I noticed that the “same” FedAuth cookie was issued twice, once scoped to my.domain.name/Site1, once scoped to the root domain my.domain.name. When browsing back to Site1, WIF get both cookies(as both apply to the target domain). However as both cookies are issued for different website...

WIF(Windows Identity Foundation) is not the most easy framework to use. The moment something goes wrong it’s not always transparent what actually happened leaving you no clue where to search for the root cause. Luckily Microsoft integrated great tracing functionality so you can have a look under the hood. To enable tracing, add the following configuration to your app.config/web.config file: Tracing information will be written to a file in XML format. However you can use the SVCTraceViewer tool to open and read the trace messages in a more user-friendly format.

After my post from yesterday where I talked about a problem with X.509 certificates, I did some extra research. One great blog post that I would recommend to read is “ Eight tips for working with X.509 certificates in .NET ”. In this post Paul Stovell, the creator of Octopus Deploy (a great tool by the way), shares some of the lessons he learned when using X.509 certificates to secure communication between the central Octopus server in Octopus Deploy and the remote agents.

Aaah, security errors, you have to love them. When deploying a new service on IIS, I got the following error: Server Error in '/SampleService' Application. The profile for the user is a temporary profile. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Security.Cryptography.CryptographicException: The profile for the user is a temporary profile. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [Cryp...

This week I lost some time searching where I could specify the ‘Home Realm’ when using the WIF components inside OWIN. I finally found it and decided to share the code:

I’m in the middle of switching between the ASP.NET WIF implementation and the OWIN WIF implementation. I had some unexpected issues, but the positive thing is I learned a lot about WIF and OWIN . One of the issues I encountered was the following error message: “A default value for SignInAsAuthenticationType was not found in IAppBuilder Properties. This can happen if your authentication middleware are added in the wrong order, or if one is missing.” Fixing it is a one-liner: app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

Last week I spend a lot of time searching for a specific WIF issue we encountered. The Facts Let’s first describe the situation before I come to the error itself. We have a root ASP.NET MVC Website e.g. portal.sample.be/ and a list of subsites portal.sample.be/subsite1, portal.sample.be/subbsite2,…  Users always have to login through the root site before they can use any of the subsites. Login is handled through WIF and a range of STS instances(depending on the  authentication type). Once logged in on the root site, users have Single-Sign-On and can connect to any of the subsites without authenticating again. The Issue Last week we upgraded the root site to ASP.NET MVC 5, .NET 4.5 and the build-in System.IdentityModel and System.IdentityModel.Services. The sub sites are still using .NET 4.0, System.IdentityModel and Microsoft.IdentityModel. Authentication on the root site works as expected, but when we try to connect to any of the subsites, SSO fails and WIF returns ...

I’m in the process of building my own STS implementation(don’t ask why). While testing an Active Federation scenario, I got into trouble and ended with the following error message: ID1038: The AudienceRestrictionCondition was not valid because the specified Audience is not present in AudienceUris. Aah, you have to love WIF and it’s wonderful set of error messages... The problem was that I forgot to add an audienceUri in my client config:

Since the release of Windows Identity Foundation, Microsoft always provided us with a development STS that was easy to setup and configure. However with the release of Visual Studio 2013, the development STS(provided through the Identity and Access Control extension) is gone. A good alternative is the EmbeddedSTS provided by Thinktecture: EmbeddedSts is intended to be used from an ASP.NET application that is using .NET 4.5 and the Federated Authentication Module (FAM) from WIF. It allows for a simple and easy to use STS instead of a production STS that might require installation and configuration. It does this by embedding itself a proper WS-Federation security token service within the application itself. When the ASP.NET application would normally redirect to the production STS, it will instead redirect to the EmbeddedSts. The EmbeddedSts will provide a list of users that can login and will then issue a SAML token back to the application that contains the selcted user's cl...

After creating a web application, I configured it to authenticate with ADFS through WIF. However when I browsed to the application, after authenticating, it failed with the following message: ID3206: A SignInResponse message may only redirect within the current web application: '/app' is not allowed. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: Microsoft.IdentityModel.Protocols.FederationException: ID3206: A SignInResponse message may only redirect within the current web application: '/app' is not allowed. The strange thing is that it works when I add a trailing slash to the application url, e.g. https://localhost/app/ instead of https://localhost/app   Anyone with a suggestion how to fix it?

In Visual Studio 2012, you had the Identity and Access tool which gave you an easy way to configure your WIF configuration and integrate with an existing STS. After installing Visual Studio 2013, I started looking on the Visual Studio Gallery for a new version of the tool. But no luck, only a VS 2012 version was available . And it seems that a version for Visual Studio 2013 will never appear. Vittorio  Bertocci shared the following information: In VS2013 Microsoft added support for claims-based identity directly into the ASP.NET project creation experience (see http://blogs.technet.com/b/ad/archive/2013/06/26/improved-windows-azure-active-directory-integration-with-asp-net-amp-visual-studio.aspx ), hence there are no plans of porting the Identity and Access tool to VS2013. We are aware of the fact that as of today the feature set of the two approaches are not 100% equivalent. VS2012 and VS2013 work well side by side, if you depend on functionality only available on the...