Change RelayState in AD FS

Question

Consider following situation: We're currently in a migration phase where the majority of our users should still be forwarded to the existing application A. Other users that fulfil some certain criteria (let's call them beta-testers) should instead be forwarded to the new application B.

Users reach our AD FS with a POST request that contains the SAMLResponse and the RelayState. The RelayState-parameter tells our AD FS the desired target-application. Up to now it always contains "site A" since the users don't know about site B yet ;-)

I'm wondering if there's a way to dynamically change the process our ADFS determines the target application based on the value of the RelayState-parameter? So what I'm looking for is a way to somehow modify the RelayState based on a certain claim the user provides. E.g. if the user has a "beta-tester" entry in her role-claim, then our ADFS should forward her to site B instead of site A.

Is there a way to hook into the AD FS procssing pipeline? The only thing I found so far is this article describing how to "inject" a custom authentication method. But that's obvisiously not what I'm looking for.

So could anybody tell me if there are any other extension points I could utilize to achieve what I described above?

Answer 1

Sorry, no - there is no way to dynamically change RelayState.

ADFS is locked down (as it is a security system) and doesn't have extension points.

Could you have two RP during the transition?

Answer 2

One approach is to setup a proxy site where you can apply custom logic as necessary for scenarios like this. My experience is there are numerous times when it's handy to have a point of entry into the federation process, i.e. a psuedo-extension point, where you can apply custom logic. So, everyone from the IdP may go to https://proxy.mysite.com and then that site would make determinations based on claims and maybe querystring, posted variables or header attributes, as to where to send (redirect) the user to next, https://a.mysite.com or https://b.mysite.com.

DNS can also be folded in, to do things like direct https://a.mysite.com to the proxy site and the proxy site can then look at the hostname of the request and know that the user intended to go to a.mysite.com, but you can determine if a beta tester and direct to b.mysite.com or the actual A site.