X.509 Binary Security Token
An X.509 binary security token is the base64 encoded representation of an X.509 public certificate. X.509 tokens are generally used to protect a SOAP message with XML Digital Signature or XML Encryption. Although not recommended, an X.509 token can also be used as an authentication token.
The following table describes the X.509 token type.
X.509 token type Description X.509 version 1 Contains just the X.509 public certificate. X.509 version 3 Contains just the X.509 public certificate. PKIPath Contains an ordered list of X.509 public certificates packaged in a PKIPath. The X509PKIPathv1 token type may be used to represent a certificate path. PKCS7 Contains a list of X.509 certificates and, optionally, certificate revocation lists (CRLs) packaged in a PKCS#7 wrapper. The PKCS7 token may be used to represent a certificate path.
Use X.509 tokens for Authentication
When we authenticate a token, we are verifying that the sender of a token is who he says he is. You take a piece of public information sent in the message, such as a a user id, and verify it somehow with a piece of private information that only they can provide, such as a password.
As a very simple example, when you authenticate a UsernameToken, the user name and password are passed in the SOAP message and they are checked against the user registry at the endpoint.
For an X.509 certificate, the public information is the public key/DN and the private information is the private key. Unlike the password for a UsernameToken, the private key is not sent in the message.
When an X.509 token is used to sign a message, the following process is used:
- If trust is enabled, the certificate is evaluated against the trust store and cert store, if configured. This will catch trust errors, certificate chaining errors, revocation errors, certificate expiration, etc. For example, we can have specific DNs in the trust store to trust each certificate explicitly, or just the root CA to trust all certificates issued from this CA, but no others.
- The runtime verifies that the sender of the message has the private key associated with the certificate by verifying the signature. If the signature cannot be verified, then one of the following conditions occurred:
- The message was signed with a private key that did not match the public key in the message.
- The message was modified after it was sent.
After the signature is verified, you know that the sender of the message is the holder of the private key; you know that he is who he says he is.
If we pass an X.509 token in a message without using its private key to sign the message, we will not perform step #2. You will not verify that the sender of the message is the holder of the private key, or he is who he says he is. When we sign a message, we are doing something that only the holder of the private key can do.
With an unprotected X.509 token, that is, the x.509 token was not used to sign the message, the system can be compromised in the following way:
- Capture of the valid message and substitution of an attacker's X.509 token in the same message.
It is not recommend an unprotected X.509 token be sent in a message. If an X.509 token is to be used for authentication, it is recommend that one X.509 token be sent in the message and that X.509 token be used for both Digital Signature and authentication, with a caller configuration. The signing part reference is used in the caller settings.
The following table describes the X.509 token value types.
X.509 token type Value type X.509 Version 1 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509 X.509 Version 3 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 PKIPath http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1 PKCS7 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#PKCS7
Related:
Binary security token