Hence, C
must secure the RST message in a way that will convince STS of
the correct provenance of the message. In WS-Security terms,
this means that C must secure the RST using some security token.
For example, C may secure its request to the STS using a
Kerberos-derived security token.
When the STS receives the RST, it examines the incoming token
and checks that it was properly secured. If everything is as expected,
the STS considers C??™s identity as veri?¬?ed and proceeds
to generate the requested SAML token. The newly generated
token is sent back to C inside another WS-Trust-de?¬?ned message
called a Request for Security Token Response (RSTR). When C
receives the RSTR, it can extract the requested SAML token and
use it for invoking S. Upon receipt of the invocation, S can extract
the SAML token and verify whether the claim about C satis-
?¬?es its requirements. Figure 2-6 shows the exchange just
described. The end result is straightforward. The STS received a
Kerberos token and issued a SAML token in return.
At this point, you might be asking yourself where the ???trust???
aspect in all of this is. The answer to that is simple: The scenario
just described was just a fairly elaborate dance for allowing C to
bene?¬?t from the trust relationship between S and STS.
Pages:
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260