ACE 4710 using SAML Tokens

gregforsythe · ‎10-07-2008

reposted from another forum:

Am using an ACE 4710 and am converting incoming WSS username tokens to SAML Tokens - authenicating against Tivoli directory.

The receiving web service is attempting to validate the SAML token but fails on digest verification. i.e. calculates the digest value over the SAML token and fails when comparing to the digest in the Xml Signature block.

Is anybody else using SAML tokens?

Has anyone else seen a similar problem?

wong34539 · ‎10-13-2008

By default, the WSS Username/Password credential resides in the message header unencrypted. Assuming transport-level encryption is used to secure the message as it crosses the network, the password nevertheless is unprotected once it arrives at its destination.

For more security, you can encrypt the credential through the use of WSS Password Digest. WSS Password Digest encrypts the password value, making it secure at the endpoint as well as in transit.

To evaluate a token, therefore, the ACE XML Gateway applies Base64 decoding of the Password from the message, producing a hexadecimal result. It then decodes the Nonce and combines it with the timestamp in the message and password (stored in the authenticator configuration). It then applies SHA1 encryption to the concatenated result. The hexadecimal results are compared to the decoded digest value. If they match, the request is validated.

gregforsythe · ‎10-13-2008

You are right we are using transport encryption (SSL) to protect the WSS Password.

We then use LDAP to authenticate the username/password and create a SAML token using attributes from LDAP. The ACE Xml Gateway creates this SAML token, signs it and inserts into the SOAP header that is forwarded to our service.

At our service we are trying to verify the signed SAML token. The error we are seeing is the Xml signature digest created by the ACE XML Gateway is wrong.

With XML signature some Xml referenced by an ID is canonicalised, hashed (digest created) and then this digest is encrypted using the private key of some certificate.

On receipt we repeat the process, canonicalise and hash the Xml referenced and compare our computed digest to the one created by the ACE device. This is where we get the error. We are using the standard canonicalisation and hashing algorithms (c14n and SHA1 respectively). Our code can successfully verify SAML tokens from other sources.