Application security requires additional mechanisms beyond what we have presented so far. Identities, for example, are valid within a trust domain but most likely meaningless in other trust domains. Federation starts with a notion of identitythat is, the requestor or the requestor's delegate asserts an identity and the Identity Provider verifies this assertion. For services in different trust domains to be able to validate identities, appropriate mechanisms are needed. WS-Federation defines mechanisms to enable identity, account, attribute, authentication, and authorization information sharing across trust domains. By using these mechanisms, multiple security domains can federate by allowing and brokering trust of identities, attributes, and authentication among participating Web services. The specification extends the WS-Trust model to allow attributes and pseudonyms to be integrated into the token issuance mechanism, resulting in a multidomain identity-mapping mechanism. These mechanisms support single sign on, sign out, and pseudonyms and describe the role of specialized services for attributes and pseudonyms.In Figure 4-2, a requestor (1) obtains an identity security token from its identity provider and then (2) presents/proves this to the security token services for the desired resource. If successful and if trust exists and authorization is approved, the security token services (2) returns an access token to the requestor. The requestor (3) then uses the access token on requests to the Web service.
Figure 4-2. Roles of identity providers and security token services. WS-Federation allows for a variety of topologies, for which the one described in Figure 4-2 is just one.
A large variety of requirements can be addressed through identity federation. One example is associating an employee with its employer. In this case, Jane, from Company A, makes a purchase from alpineskihouse.com. Company A and alpineskihouse.com have a purchasing contract. Since Jane's identity is associated with Company A, she can be authorized to make a purchase under the contract.A second example is mapping a single person to multiple pseudonyms. Joe may be known at work as joe_andreshak@adatum.com. He may also have other identities, such as joe@alpineskihouse.com and josepha@contoso.com. Through identity federation, systems can determine that each of these identities is the same Joe. WS-Federation defines explicit operations to get, set, and delete pseudonyms.A sign-out operation is provided in order to enable cached state and security tokens to be removed from a federation. The sign-out operation serves as a hint that it is appropriate to flush cached data or state information for a specific principal. The exact mechanisms used for sign out varies depending on the kind of resource and the security policies in place.Two broad classes of requestors (message senders) are defined in the Web services federated security architecture: passive and smart (active). A passive requestor [WS-FedPassive] is a service that uses only HTTP and never issues security tokens. A smart requestor is a service capable of issuing messages containing security tokens, such as those described in WS-Security and WS-Trust. A traditional HTTP-based Web browser is an example of a passive requestor. Profile specifications have been developed to define the behaviors of these two kinds of requestors.For smart requestors, the active requestor profile [WS-FedActive] specifies how single sign on, sign out, and pseudonyms are integrated into the Web services security model using SOAP messages. In effect, the profile describes how to implement the model described in WS-Federation in the context of smart requestors. It specifies requirements on various kinds of security tokens. An example of one of these security token requirements is as follows: when not using a secure channel, tokens for X.509 certificates must contain the authority's name and a signature over the whole token. The profile also requires that X.509 tokens contain the subject identifier uniquely identifying the subject for whom the token was granted.
لطفا منتظر باشید ...
