However, there cannot be any explicit dependency in the speci-
?¬?cation; otherwise, the good cross-technology properties would
be lost. The WS-Security authors devised a clever trick for solving
the impasse. The speci?¬?cation assumes that the
cryptographic material travels in a WS-Security security token, a
generic data construct, and refers to it for de?¬?ning the various
encryption and signing operations on the message. Then they
separately provided satellite speci?¬?cations, named token pro-
?¬?les. Each token pro?¬?le describes how to derive a WS-Security
token from an existing security technology, mapping the peculiarities
of the particular system to generic WS-Security features.
For example, a web service may mandate that the body of the
message be signed without specifying the kind of key used. A
certain caller may sign using a security token derived from an
X.509 certi?¬?cate, whereas another may use a security token
derived from a Kerberos ticket. As long as the receiving end can
verify the validity of the signature??”for example, by choosing by
a pool of well-known certi?¬?cates or by being part of the same
Kerberos domain??”everything goes as expected.
Pages:
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255