SEARCH
0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Prev | Current Page 261 | Next

Vittorio Bertocci, Garrett Serack, Caleb Baker

"Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities"


WS-Security token
generality makes
WS-Security ideal
as an encapsulating
protocol
STSs are natural
claim transformers
WS-* Web Services Speci?¬?cations: The Rei?¬?cation of the Identity Metasystem 159
The Canonical Scenario
Again we have one subject, S, one relying party, RP, and an
identity provider, IP. The RP is implemented as a web service;
the IP offers its functions by mean of an STS. (An STS that offers
IP functions is often referred to as an IP-STS.) S was and remains
a person, a human user of the system. For the purpose of this
walkthrough, we will assume that S uses some sort of agent that
hides the complexities of the web services interactions. We will
get back to that agent in greater detail in the section ???Presenting
Windows CardSpace.???
With this web services mapping in mind, let??™s revisit the original
sequence under a new light (see Figure 2-7):
1. S wants to call RP. The S??™s agent reaches out to the RP
via WS-MetadataExchange, to acquire the RP??™s policy
and requirements. The WS-MetadataExchange returns a
WS-Policy document containing some WSSecurityPolicy
assertions. The RP states that it will consider
for authentication only the users presenting an
identity issued by IP??™s STS, in SAML1.


Pages:
249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273