لطفا منتظر باشید ...
Secure Sessions
Some mechanisms for message authentication and confidentiality can be computationally expensive. In particular, many encryption techniques consume substantial processing power. These costs are generally unavoidable when messages are secured individually. However, when two Web services exchange many messages, more efficient and robust approaches for message confidentiality than those defined in WS-Security are available. These mechanisms, based on symmetric encryption, should be used when securing sessions of messages.WS-SecureConversation [WS-SecConv] defines extensions to WS-Security for establishing a security context and sharing it between two communicating parties based on shared secrets, such as symmetric encryption. A security context is shared between the parties for the lifetime of a session. Session keys are derived from a shared secret and are used to decrypt the individual messages sent in the conversation. The security context is represented on the wire as a new security token type, the Security Context Token (SCT). Lifetime management of SCTs is flexible, in that the lifetime can be specific to the token or it can be bound to a resource that has its own lifetime.Three different ways of establishing a security context among the parties of a secure conversation are defined. First, a security token service might create them, and the initiating party has to fetch it to propagate it. Second, one of the communicating parties creates the security context and propagates it in a message to the other party. Third, the security context is created through negotiation and exchanges. Web services select the approach most appropriate for their needs.Security contexts can be amended when necessary. An example of a requirement to update a security context is the need to extend the context's expiration time.A security context token implies or contains a shared secret. This secret is used for signing and/or encrypting messages. When using a shared secret, the parties can choose a different key derivation pattern to use. For example, four keys can be derived so that two parties can sign and encrypt using separate keys. To keep the keys fresh and to maintain a high level of security, subsequent derivations should be used. Securing sessions using this approach is preferred. The WS-SecureConversation specification defines a mechanism to indicate which derivation is being used within a given message. Each derivation algorithm is identified with a URI.WS-SecureConversation defines a special binding for SCT requests when using WS-Trust operations. This binding is based on defining two Action URIs specifically for this purpose. Other bindings are also allowed. When a SCT must be changed, such as when it must carry additional claims, explicit requests for these operations are defined. These requests also have Action URIs defined for them for use with WS-Trust.
