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.
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.
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.
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...
Cisco Documents are usually accurate, but when it came to the document
on Cisco APIC Signature-Based Transactions it was slightly off the mark.
This document is for those novices to API like me who cant seem to
figure out how to go about performing signat...