IdP v4.0.1 issues with CBC relying-party overrides and SPs with cipher-suite metadata

[Robert Bradley]

After our recent upgrade to IdP 4.0.1, we came across an unusual example 
of an SP that apparently does not support GCM-based ciphers, but 
nevertheless contains metadata that advertises support for them.  (For 
general interest, these are simitive.com SPs that have Shibboleth-like 
published metadata, but are actually SimpleSAMLphp-based.)  Until we can 
get the published metadata fixed, I was hoping to use a 
relying-party.xml override like this one:

<bean parent="RelyingPartyByName" 
c:relyingPartyIds="https://arbitrary.it.ox.ac.uk/shibboleth">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO"
  p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
</list>
</property>
</bean>

to allow us to force the use of CBC ciphersuites instead of GCM. 
However, when SAML assertions are produced, the encrypted attribute 
block still claims to be GCM:

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
 
Destination="https://arbitrary.it.ox.ac.uk/Shibboleth.sso/SAML2/POST"
                  ID="_953372beca9714a536090c611504d038"
                  InResponseTo="_af4553dbe886c401d685efbfd5915f6b"
                  IssueInstant="2020-11-12T14:28:15.199Z"
                  Version="2.0"
                  >
<!-- snip irrelevant data -->
<saml2:EncryptedAssertion 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData
  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
  Id="_88d1fadfcca9ba43aa36f65ecfacdec7"
  Type="http://www.w3.org/2001/04/xmlenc#Element">
  <xenc:EncryptionMethod
   Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" />
<!-- snip --->
</xenc:EncryptedData>
</saml2:EncryptedAssertion>
</saml2p:Response>

This is after both a reload-service call and restarting the IdP 
container.  I've managed to override security configuration elsewhere 
for SPs limited to SHA-1, so I don't believe it's a syntax error, but 
none of those SPs had metadata to advertise cipher support.  Has anyone 
else seen any similar behaviour, and should I be filing this as a 
potential IdP bug?

-- 
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x9461A7CA76AFE3BE.asc
Type: application/pgp-keys
Size: 16768 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20201112/9fa7ecab/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20201112/9fa7ecab/attachment.sig>