-1

In our topography we have foo.com, myfoo.com, outletfoo.com and auth.idsrv.com.

For dev purposes, these are separate websites that live under 1 iis instance.
foo.com, myfoo.com and outletfoo.com are relying parties of auth.idsrv.com.

If user bookmarked any link in foo.com, myfoo.com or outletfoo.com and that link points to a resource requiring authentication, we redirect to auth.idsrv.com.

foo.com, myfoo.com and outletfoo.com are not https by default, one or more could be though. auth.idsrv.com is https.

After redirecting to auth.idsrv.com, I enter username/password all is well. cookie “idsrvauth” is expiry Session / http. However, upon redirect back, the idsrvauth cookie is gone because of expiry Session.

Perhaps only my configuration is incorrect. With foo.com, myfoo.com, outletfoo.com and auth.idsrv.com being separate domains, is there a supported scenario in the identity server configuration where relying parties can be separate domains? Can you point to the correct way to configure the relying parties so that each can receive the idsrvauth cookie.

When authentication is validated and the redirect happens, how would we have knowledge of the idsrvauth cookie in any (essentially cross domain) calling application in our example topography?

1 Answers1

0

IdSrv uses WS-Federation for authentication. WS-Fed does not rely on cookies but sends a SAML token via a form post to the relying party (see the spec: http://msdn.microsoft.com/en-us/library/bb608217.aspx)

So in other words - cross domain is absolutely supported.

leastprivilege
  • 18,196
  • 1
  • 34
  • 50
  • Got it. I was going to the idsvr first (in the proof) so that part of it sorted out. We are coming back to a relying party who is in a 2.o framework environment where that post you mention throws "A potentially dangerous Request.Form value was detected from the client" even with the target possessing the page directive [ValidateRequest= false] as well as the web config pages enableEventValidation = false hacks. Can you recommend what may need to be added to the 2.0 site(s) to support that post? – user251237 Feb 10 '14 at 16:49
  • Well if you want to use WIF to consume the SAML response you need .NET 3.5 or higher. – leastprivilege Feb 10 '14 at 20:42