Working with an ADFS Proxy server.

[Friedrich Clausen]

Hi Yannick, All,

Just to follow up in case someone reads the archives one day and wants
to know the conclusion. That MS Technet article [1] about DNS changes
was key; by asking the customer to set up split DNS, as described in
the article, we can now complete the transaction and are returned to
the SP.

Now I am just trying to map the attributes properly but that might be
the stuff of another post if I get stuck. First I'll read all there is
to read on the Wiki interop page.

Thanks!

Fred.

[1] http://technet.microsoft.com/en-us/library/dd807055(v=ws.10).aspx

On Thu, Aug 16, 2012 at 4:33 PM, Friedrich Clausen <fred at derf.nl> wrote:
> Hi All,
>
> Thanks for the information! I understand why it can't work as I
> previously described. There is hope however - Yannick, that technet
> article was especially useful and I will be asking the customer to
> make the requisite DNS changes for this to work.
>
> From what understand of the technet article [1] (referencing my
> previous examples) is that there need only be one DNS record,
> adfs.a.example.com. This would resolve differently depending on the
> source location of the request; e.g. an internal lookup will resolve
> an internal federation server IP whereas an external lookup will
> resolve the public IP of the ADFS proxy. I believe this is similar to
> the ISC Bind name server's "views" but in a Windows DNS environment.
>
> Cheers,
>
> Fred.
>
> [1] http://technet.microsoft.com/en-us/library/dd807055(v=ws.10).aspx
>
> On Wed, Aug 15, 2012 at 8:38 PM, Yannick Béot <yannick.beot at gmail.com> wrote:
>> Hi,
>>
>> The only way to make it work is to have the same URL for the Proxy and the
>> back-end server. You have to play on DNS to make it work
>> Everything is explained there:
>> http://technet.microsoft.com/en-us/library/dd807055(v=ws.10).aspx
>>
>> Yannick
>>
>>
>> On Wed, Aug 15, 2012 at 7:38 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>>
>>> >The problem is that the ADFS proxy (sso.a.example.com) requires the
>>> >"Destination" XML attribute be set to "adfs.a.example.com".
>>>
>>> That's a bug. The analagous scenario is a load balancer doing SSL
>>> offloading. Even though the back end server is at a different physical
>>> location, it must pretend to be the virtual location of the load balancer
>>> when it performs such comparisons. People screw this up with the SP and
>>> IdP all the time, because it's the web server's responsibility to do these
>>> adjustments.
>>>
>>> Note that IIS does not support those adjustments either, which is probably
>>> relevant to an ADFS situation.
>>>
>>> If MS supports a proxied scenario but does not support virtualizing the
>>> back end, you can't make it work.
>>>
>>> >The ADFS administrators says that the HTTP POST/Redirect URLs need to
>>> >be set to sso.a.example.com while the "Destination" AuthnRequest
>>> >attribute must be set to "adfs.a.example.com". How can I achieve this?
>>>
>>> You can't. Well, you could change the code (or add plugins that duplicate
>>> but tweak this value), but I'm ignoring that option.
>>>
>>> I could imagine some very ugly hacks such as an option to override the
>>> Destination value based on some kind of mapping table, but that's not
>>> implemented now.
>>>
>>> >How have other people interoperated with ADFS proxies?
>>>
>>> I would imagine they have not. A page to document things that don't work,
>>> or how to work around issues is here:
>>>
>>> https://wiki.shibboleth.net/confluence/display/SHIB2/MicrosoftInterop
>>>
>>> -- Scott
>>>
>>> --
>>> To unsubscribe from this list send an email to
>>> users-unsubscribe at shibboleth.net
>>
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net