Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I asked the same question on the Geneva Forum at <a href="http://http:social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required" rel="nofollow noreferrer" title="MS Geneva Forum">http://social.msdn.microsoft.com/Forums/en/Geneva/thread/d10c556c-1ec5-409d-8c25-bee2933e85ea?prof=required</a> and got this reply:</p> <p>Hi Dokie,</p> <p>I wondered this same thing when I read that article. As I've pondered how such a scenario would be implemented, I've come up w/ two ideas:</p> <ol> <li><p>The RP is actually configured to require claims from the RP-STS; the RP-STS requires a security token from the IP-STS. As a result, when the subject requests a resource of the RP, it bounces him to the RP-STS who bounces him to the IP-STS. After authenticating there, he is bounced back to the RP-STS, the identity-centric claims are transformed into those necessary to make an authorization decision and returned to the RP.</p></li> <li><p>The RP is configured to have an interceptor (e.g., an AuthorizationPolicy if it's a WCF service) that grabs the call, sees the identity-centric claims, creates an RST (using the WSTrustClient), passes it to the RP-STS, that service expands the claims into new one that are returned to the RP, and the RP makes an authorization decision.</p></li> </ol> <p>I've never implemented this, but, if I were going to, I would explore those two ideas further. </p> <p>HTH!</p> <hr> <p>Regards,</p> <p>Travis Spencer</p> <p>So I will try option 2 first and see if that works out then formulate an answer here.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload