 |  |  |  |  |
| | | | |
 |  |
Figure 13.2 gives an overview of what happens when a single sign-on client makes a secure invocation on a remote server.
The WS-Trust single sign-on scenario shown in Figure 13.2 can be described as follows:
Before invoking an operation on the server for the first time, the client initiates SSO login by contacting the Issue binding on the STS.
The client presents its own X.509 certificate, alice.jks,
during the TLS handshake. On the STS side of the connection, the JAX-WS
endpoint verifies the client certificate using the CA certificate,
trent-cert.pem, and on the client side, the client
verifies the STS certificate using the CA certificate,
sts-ca-cert.pem.
After the TLS handshake is complete, the JAX-WS endpoint is configured
to authenticate the client certificate. Effectively, this authentication
step consists of comparing the received certificate with a copy of the
certificate, alice-cert.pem, stored in the security
adapter. For more details, see Managing a File Authentication Domain and Managing an LDAP Authentication Domain.
If the authentication step is successful, the adapter layer returns a collection of realm and role data associated with the client.
The STS layer takes the realm and role data from the previous step and uses it to create a SAML token, as follows:
The client's realm and role data is reformatted as a SAML 1.1 token.
The client's identity (extracted from the client certificate's
subject) is encoded as authorization related content of a SAML
token. This identity represents the the
holder-of-key (shown as
HOK in the figure).
The token issuer private key is used to sign the SAML token
(where the signature is shown as # in the figure).
This enables relying parties (Artix servers) to verify the
integrity of the SAML token.
The STS replies to the client, sending back the signed SAML token.
The client initiates a connection to the server, in order to invoke an operation.
During the TLS handshake, the client presents its own X.509
certificate, alice.jks. On the server side of the
connection, the JAX-WS endpoint verifies the client certificate using
the CA certificate, trent-cert.pem, and on the client side,
the client verifies the server certificate also using the CA
certificate, trent-cert.pem.
After the connection is established, the client sends an invocation request to the server, which includes the SAML token embedded in a SOAP header.
The server tests the integrity of the received SAML token using the token issuer public key (which complements the token issuer private key used by the STS). If this test is successful, it proves that the SAML token has not been modified or corrupted since it was issued by the STS.
In addition, the server also checks that the holder-of-key identity embedded in the SAML token matches the subject from the received client certificate. If the identities match, this proves that the current client is indeed the owner of the SAML token and is entitled to present the token to the server. This is a stong extra level of control, which prevents the use of SAML tokens in contexts they were not meant for, even if an attacker somehow acquired one.
The server extracts the realm and role data from the SAML token and, in conjunction with the server's own ACL file, the server figures out whether the client is authorized to invoke the requested operation. If yes, the operation is allowed to proceed; otherwise an error would be generated.
A signed SAML token consists of the following parts:
SAML assertion—in Artix, this consists of realm and role data.
(Optional) Holder-of-key field—the identify of the client that owns the SAML assertion. Only the client identified by this field is allowed to present the current SAML token.
Digital signature—a signature obtained by calculating a digest of the SAML token and encrypting the digest with a private key (token issuer private key). The signature can later be verified using the corresponding public key (token issuer public key). Using a digital signature offers the following advantages:
Integrity—the contents of the SAML token cannot be tampered with or corrupted in any way. Any attempt to modify the token would cause a mismatch between the digest and the message contents.
Non-repudiation of origin—only the STS has access to the token issuer private key. Hence, by verifying the signature, you can prove that the SAML token originated from the STS that owns that private key.
If you consider the case where the holder-of-key field is not enabled, obtaining a signed SAML token is analogous to obtaining an electronic card key to gain access to a building. In order to obtain the key initially, you present some form of photo ID to a receptionist or security guard. Having verified your ID, the guard then issues you with an electronic key that gives you access to certain areas of the building. For example, you might gain access to the meeting rooms and ordinary offices, but you would probably not be able to access the systems room, the boiler room or the CEO's office.
If you were particularly keen to visit the boiler room and you were an inveterate hacker, you might be tempted to try and re-program the card key using equipment ordered over the Internet. But if the card key system is properly designed, this would be impossible, because the card issuer would have a secret code that is required for re-programming the card. The card key is thus tamper proof, like a signed SAML token.
The holder of key feature is a mechanism that provides proof of ownership of a signed SAML token. The key holder is the legitimate owner of the signed SAML token and only this key holder has the right to present the SAML token to a relying party. The holder of key mechanism works by embedding the key holder's identity in the SAML token before the SAML token is signed by the token issuer. If the key holder now presents its own credentials along with the SAML token when it contacts a relying party (for example, an Artix server), the relying party can then check that the key holder's identity matches the identity embedded in the SAML token.
If you consider the analogy with the card key system, you can see that a potential weakness in the card key system is that the card key could be used by anybody. In order to preserve security, therefore, you must take great care that you do not physically misplace the card key. If you went out to a cafe for lunch and accidentally left your card key behind, anyone could pick it up and use it to access the building. This is the kind of hazard that holder of key security is designed to protect against. One way of adding protection to the card key system would be to print your name on the card key as it is issued and to require all key holders to carry a photo ID with them at all times. Under this system, anyone in the building could challenge you to produce your photo ID and show that your name matches the name on the card. This enables you to prove that you are the legitimate owner of the card key.
In the scenario shown in Figure 13.2, a relatively large number of certificates and keys are used. These can be summarized as follows:
trent-cert
configuration authority—is responsible for
issuing the following certificates:
alice.jks—the client's own X.509
certificate and private key.
bob.jks—the server's own X.509 certificate
and private key.
sts-ca-cert
configuration authority—is responsible for
issuing the following certificate:
sts-server.jks—the STS server's own X.509
certificate and private key.
Token issuer keys—to support signed SAML tokens, the following public/private key pair is defined:
sts-token-issuer.jks—the token issuer
private key (for signing SAML tokens).
sts-token-issuer-cert.pem—he token issuer
public key (for verifying SAML tokens).
| |  | |
 |
