Posts Tagged 'rampart'

WS – Security Policy

Web services security policy language defines a way to express constraints and requirements of a soap message to provide security. These constraints and requirements are defined as policy assertions and these assertions define how messages are secured. These assertions can be categorized in to

  • Security binding assertions
  • Protection assertions
  • Token assertions
  • Supporting token assertions
  • WSS : Soap message security assertions
  • WS – Trust assertions

Security Binding Assertions

Security binding assertions defines main security mechanism used to secure the messages. This assertion defines some properties and these properties define how messages are secured. These also defines which tokens should be used to secure messages using Token assertions. There are 3 security binding assertions, Transport binding, Symmetric binding and Asymmetric binding. If transport binding is used, message protection is provided by means other than SOAP message security. For example, Transport biding can use HTTPS transport to secure the message between the client and the server. If we use Asymmetric binding assertion, we can easily make both the client and server authenticate them selves using the security tokens defined in this policy assertion. Under this assertion we can specify two requirements with initiator token assertion and recipient token assertion. These assertions defines what type of token should be used by initiator and recipient. When Symmetric binding is used , first encrypted key is derived using the recipients security token , defined in the either encryption token assertion or protection token assertion. Then this encrypted key is used to secure the message back and forth between the recipient and the initiator. This binding facilitates the need to secure the messages between anonymous clients and the server. Only the server has to posses a security token.

Security Binding Properties

Security biding assertions contain some properties which defines how messages are secured.

  • Algorithm Suite – this property defines a algorithmic suite to be used with cryptographic operations. So it is very easy to define all the algorithms using one property. What are the available algorithmic suites and which algorithms are used in those suites can be found in the WS – Security Policy specification.
  • Timestamp – defines whether timestamp should be included in the message
  • Protection Order – when we have to do both signature and encryption, this defines whether to sign then encrypt or encrypt then sign.
  • Signature Protection – defines whether signature should be encrypted. Signature confirmation elements also will be encrypted.
  • Token protection – defines whether signature should cover the security token which used to generate the signature
  • Entire Header and Body Signatures – defines whether signatures should cover only the entire body and entire header elements and not the descendant of elements.
  • Security Header Layout – defines layout rules which applies to security header

Protection Assertions

These assertions defined what message parts are protected and how they are protected. There are mainly two types of protection token assertions. Integrity Assertions and Confidentiality Assertions. Integrity assertions define what elements of the message should be signed and confidentiality assertions defines what elements should be encrypted. Four protections assertions are

  • Signed Parts Assertion – defines whether body should be signed and what soap header elements should be signed
  • Signed Elements Assertion – defines arbitrary elements to be signed using XPath
  • Encrypted Parts Assertion – defines whether body should be signed and what soap header elements should be encrypted
  • Encrypted Elements Assertion – defines arbitrary elements to be encrypted using XPath

Token Assertions

These assertions specify the type of the tokens to be used to protect the messages. These assertions also define two important properties about the tokens used to protect the message.

  • Token Inclusion – defines when to include the binary tokens in the message
  • Derived Keys – defines whether derived keys should be used

some of the token types defined in the WS – Security Policy specification are,

  • Username Tokens
  • X509 Tokens
  • Issued Tokens
  • Secure Conversation Tokens
  • SAML Tokens
  • Https Tokens

Supporting Token Assertions

These tokens defines additional tokens to augment the claims provide by the token which is used to generate the message signature. There are four types of supporting tokens.

  • Supporting Tokens – additional tokens to included in the security header
  • Singed Supporting Tokens – additional tokens to be included in the security header which are also covered by the message signature
  • Endorsing Supporting Tokens – These tokens sign the message signature ( entire ds:Signature element ). So we get an additional signature element which is the signature of the original message signature.
  • Signed Endorsing Supporting Tokens – Here the supporting token is covered by the message signature. And the message signature again is signed using the supporting token.

WSS – SOAP Message Security Options

These options defines the requirements that the initiator and the recipient must support. There are two assertions , Wss10 assertion and Wss11 assertion which defines these requirements.

Wss10 Assertion

  • Direct References – defines whether initiator and recipient must be able to process direct reference
  • Key Identifier References – defines whether initiator and recipient must be able to process key identifier references
  • Issuer Serial References – defines whether initiator and recipient must be able to process issuer serial references
  • External URI References – defines whether initiator and recipient must be able to process external URI references
  • Embedded Token References – defines whether initiator and recipient must be able to process embedded token references

Wss11 Assertion

  • Thumbprint References – defines whether initiator and recipient must be able to process thumbprint references
  • EncryptedKey References – defines whether initiator and recipient must be able to process encrypted key references
  • Signature Confirmation – defines whether signature confirmation as defined in SOAP Message Security 1.1 specification

WS – Trust Assertions

This assertion defines the requirements for exchanges based on WS-Trust, specifically with client and server challenges and entropy behaviors.

Advertisements