STS Issued SAML 2.0 Token bug - WSS1613: The element EncryptedAssertion inside security header is not supported

**Working setup:** .Net WCF client making a call to a secured Metro Web Service hosted on Tomcat 7\. Netbeans IDE 7.0 used to specify the Service Security to be via an "STS Issues Token" SAML1.1 Token with a Symmetric Key. The STS in this scenario is ADFS 2.0. This works end to end with WCF requesting a token from ADFS and then sending it to the
Metro service.

**Failture Scenario:** When token type is changed from SAML token 1.1 to 2.0 the following error is returned:

WSS1613: The element EncryptedAssertion inside security header is not supported

**Cause:** The STS sends the **SAML 2.0 Token** wrapped in an ****. In the **SAML1.1** case an **** element is used. The **** is not supported
#### Environment
STS - ADFS2.0, SAML Token 2.0
WCF Client .Net Framework version 4 Windows7
Java Service JDK 1.6 Metro 2.1.1 Webservice on Tomcat 7
#### Affected Versions
[2.1]

Source: [https://github.com/javaee/metro-wsit/issues/1581](https://github.com/javaee/metro-wsit/issues/1581)
Author: glassfishrobot

Start by reproducing the failure with the described ADFS 2.0, WCF, Metro 2.1.1, and Tomcat setup, then trace how the Metro service processes the SAML 2.0 security header. Done means the EncryptedAssertion form is accepted instead of producing WSS1613, with coverage for the affected SAML 2.0 case.

Written by the indexing model from the issue text.