IIS : Could not load file or assembly

 

So I had a website – .NET Framework 4 / IIS 7.5 - working perfectly on my PC.

Moved it to another box and got the error with one of my dlls.

“Could not load file or assembly ‘xxx’ or one of its dependencies. An attempt was made to load a program with an incorrect format”

WTF!

Mr. Google to the rescue. Normal battle with the ten tons of shite but then one link rang a bell.

My original box was 32 bit whereas the new one is 64 bit.

What you have to do with the ApplicationPool is:

In IIS 7 Manager:

• Click ApplicationPools
• Select the one for your application.
• Click “Advanced Settings” on the right
• Under “General” at the top, set “Enable 32-bit Applications” to be “True”

Bingo – problem solved.

Enjoy!

ADFS : I want to see the SAML data

There are a number of ways to see the SAML data.

Fiddler is one way.

You can use the TextWizard to URL decode and SAML decode. Refer my update on this - SAML : Encoding / decoding a trace

Refer Using Fiddler to trace a SAML IDP Request from ADFS 2.0

Dominick Baier wrote a Fiddler Inspector for Federation Messages.

Also described here : Viewing SAML/Federation response in Fiddler.

Also, the Troubleshooting WS-Federation and SAML2 Protocol tool. 

There's also the Feide SAML 2.0 Debugger.

And a URL Decoder/Encoder.

And another SAML 2.0 debugger.

But my favourite way is to use the:

SAML Tracer

which is a FireFox add-on..

Or Auth0 SAML tool

Or the Chrome SAML extension:

SAML Chrome extension 

And there are some more tools here:

Collection of Useful SAML Tools

Enjoy!

ADFS : IDP / IP and SP Initiated flows

This confuses some people so some ADFS v2.0 screen shots might be helpful.

SP Initiated is the more normal flow. The user navigates to the application, WIF (or whatever) redirects to ADFS and you get the normal login screen:



After the user is logged in, the application gets the SAML token.

IDPInitiated in ADFS only works for SAML bindings.

The ADFS IDPInitiated URL is:
https://xxx/adfs/ls/IdpInitiatedSignOn.aspx



ADFS looks through all the configured RP to find any with a SAML binding and then displays them all in the dropdown.

The user can either sign in first using the first option and then navigate directly to one of the dropdown applications or first select a dropdown entry using the second option and then sign in.

After the user is logged in, the application gets the SAML token.

The SAML token is the same for both IP and SP initiated.

Enjoy!

ADFS : General SAML problems

 

From experience, make sure you:

• Map email in a transform rule to “NameID – Transient”
• Use SHA1 not SHA 256 (In the RP Advanced tab).

Enjoy!

ADFS : NameID / qualifier in claims

 

Firstly, there’s an excellent write-up here:

ADFS – SAML 2.0 Identity Provider and SaaS Service Providers

I was busy configuring a SAML provider in ADFS v2.0 when I got this error:

“The SAML Single Logout request does not correspond to the logged-in session participant.
Requestor: sp_test
Request name identifier: Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient, NameQualifier: http://xxx/adfs/services/trust SPNameQualifier: sp_test, SPProvidedId: 
Logged-in session participants:
Count: 1, [Issuer: sp_test, NameID: (Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient, NameQualifier:  SPNameQualifier: sp_test, SPProvidedId: )] 

This request failed.

User Action
Verify that the claim provider trust or the relying party trust configuration is up to date. If the name identifier in the request is different from the name identifier in the session only by NameQualifier or SPNameQualifier, check and correct the name identifier policy issuance rule using the AD FS 2.0 Management snap-in.”

I had a custom claims rule:

c:[Type == "http://mycompany/internal/sessionid"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",  Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "sp_test");

So I had the sp_test part but not the http://xxx/adfs/services/trust part. The key was in the “User Action” message above. As my two messages only differed by NameQualifier, I needed to expand my rule to:

c:[Type == "http://mycompany/internal/sessionid"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = http://xxx/adfs/services/trust, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "sp_test");

Enjoy!