Office365 & using STM as a ADFS 3.0 Reverse Proxy Replacement

[[email protected]]

Trying to configure a VS to decrypt an ADFS SAML Internet request as part of an Office365 login process, then encrypt and forward onto an Internal ADFS server, so in esence replacing the ADFS Proxy service.

I am getting a 500 Response error and an incorrect Content Type (text/html) being returned.

But if I configure the VS not to decrypt the SSL and use the SSL(HTTPS) protocol, then the SAML authentication process works.

But what I was wanting to acheive was to be able to decrypt and then interegate the SAML requests and direct to approriate pools.

Has anybody been able to do this?

[Tony Watkins]

Hi,

We are doing the pass-through version without the decryption and as you mention it does seem to authenticate ok.  Butto add to the problems, even with this working, setting up health monitoring for the proxies is proving difficult.

I've tried simple ping, tcp connect and even http monitor to the https://<servname>/federationmetadata/2007-06/federationmetadata.xml url without much success.

The two former methods work until around 8:10 am then fail and don't auto recover in spite of visits to the metadata url still succeeding.

Using the url just fails pretty much straight away.  I'm not sure if this relates to the MIME type of application/samlmetadata+xml in some way?  Restarting a traffic manager fixes it - but it's far from ideal.

Sorry for hijacking your question - but perhaps the 500 Content Type (txt/html) does tie in with the application/samlmetadata+xml MIME type?

Thanks