Because a MEX policy can describe multiple
endpoints, the issuer URL is used to select which to use.
In turn, the STS can then request a token from an IP, specifying
the usual options in the request, such as requested claims.
CardSpace will then allow a user to select a card that satis?¬?es
the STS??™s request. The token from the IP sent to the STS, which
returns a token that satis?¬?es the original request from the site. At
this point, the ?¬‚ow is the same as any other request. The token is
posted to the token-processing page and validated. That processing
code should verify that the identity of the token issuer is
the resource STS, and implement business logic based on the set
of normalized claims.
CardSpace uses the
RSTS token request
policy to match
cards
Identity
Provider Website
CardSpace
Resource
STS
Figure 4-7 Implementation of the pattern Brokered Trust
Federation with CardSpace 251
This interaction does not signi?¬?cantly change the user??™s experience.
The interaction with the R-STS isn??™t explicitly shown to the
user. That is, the user never sees the identity information for the
R-STS. Because the R-STS acts on behalf of the website, it is the
website??™s identity that is shown on the recipient identi?¬?cation
page in CardSpace.
Pages:
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378