I have a customer scenario that includes an RP, RPSTS and IPSTS.

1. The RP uses the FAM to redirect to RPSTS
2. The RPSTS uses FAM to redirect to IPSTS and handle RSTR from IPSTS, and uses the STS control to handle the original RST from the RP (post RSTR processing from IPSTS)
3. The IPSTS uses STS control to handle RST from RPSTS

Everything works quite well. The IPSTS issues a token for a Windows user, the RPSTS processes the RSTR and provides the right claims identity so that the user is authenticated. After processing the RSTR the FAM redirects to the STS control page (Default.aspx) with the original RST as far as I can tell, and the token is issued.

Here comes the strange part. After the STS control issues a token, the Default.aspx page is called again with a POST and the STS issues a token a second time for the authenticated user. I am still looking for the place that triggers this, but I thought I might get an answer here in the meantime. Is it a bug in the STS control? Or, is the combination of FAM and STS control just not a good one for this scenario, and perhaps I need to roll my own RST handling instead?

The result is the following (in summary):

GET RP
GET RPSTS (RST 1)
GET IPSTS (RST 2)
POST RPSTS (RSTR 2)
GET RPSTS (RST 1)
POST RPSTS (RST 1) this is the extra call I am not expecting
POST RP (RSTR 1)
GET RP

---

Michele Leroux Bustamante | Chief Architect, IDesign | www.thatindigogirl.com

I found the problem, it was a bug I introduced by setting the SignInRequestMessage.Reply parameter. I accidentally set it to the RPSTS RequestUrl and thus the extra bounce at the RPSTS before returning to the RP. The FAM and STS control are handling things beautifully now so I will write a nice little article now on this solution!!!

---

Michele Leroux Bustamante | Chief Architect, IDesign | www.thatindigogirl.com