Date: Thu, 28 Mar 2024 18:47:19 +0000 (UTC) Message-ID: <1388095767.25.1711651639936@637274d5a2f3> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_24_1425447009.1711651639935" ------=_Part_24_1425447009.1711651639935 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In a typical XML Signature, when a private key is used for signing, the =
data being signed is bulk-digested using a hashing algorithm recorded in th=
e signature's <DigestMethod>
element. In addition, =
the <SignedInfo>
element is then signed using an as=
ymmetric signing algorithm that involves a separate, independent digest ste=
p. This is reflected by the designation of the digest algorithm used within=
the overall signature algorithm identifier, for example "rsa-sha1" or "rsa=
-sha256". Thus there are two types of algorithms one must specify when sign=
ing, the bulk digest method, and the signing algorithm itself. Both involve=
a digest algorithm, and these algorithms can be independent of each other,=
though they are typically chosen in tandem.
The default digest method used by the IdP for XML Signatures in both con= texts is SHA-1. These algorithms (and many other related = algorithms and settings) can be changed by injecting an IdP extension Sprin= g bean into the IdP configuration. This entails deploying an updated WAR fi= le with the extension jar, and then making a small configuration change to = load the new bean.
Changing the IdP signature/digest algorithm and related settings is curr= ently a global operation. The algorithm will be changed for all relying parties it interacts with. Do not make this change un= til you have verified that all your relying parties can handle responses us= ing the new algorithm(s) you choose.
Whether the Shibboleth SP can consume a message signed with an algorithm= other than SHA-1 depends on the underlying OpenSSL library. On Red Hat Ent= erprise Linux version 4 (a very old, unsupported version) the OpenSSL versi= on (0.9.7) is old enough that it cannot consume messa= ges signed, for example, with any of the digest algorithms collectively kno= wn as SHA-2 (SHA-224, SHA-256, SHA-384 or SHA-512). = SHA-2 support was introduced into OpenSSL with version 0.9.8 in July 2005, = but this was too late for inclusion in RHEL 4. RHEL 5.x and 6.x do in= clude OpenSSL version 0.9.8 or later.
A particularly difficult platform to assess is Solaris, and a lot of com= mercial vendors use it. Many different versions of OpenSSL may be in use de= pending on how open source software is managed in a particular Solaris envi= ronment. Heavy testing is recommended.
The Shibboleth Native SP versions 2.4.3 and 2.5.x, if the underlying Ope= nSSL library is recent enough, do not require any configuration changes to = consume messages or assertions signed with a digest method other than SHA-1= .
No statement can be made at this time about other SAML service provider = (SP) software, though in the case of commercial options, we believe that mo= st recent versions released since 2010 or so are likely to support at least= SHA-256. The only sensible approach is to thoroughly and completely test w= ith each SP that might receive an assertion from the IdP.
Download the latest version of the extension from http://shibboleth.net/downloads/identity-= provider/extensions/security-config/.
Detailed installation instructions may be found in the INSTALL.txt withi= n the distribution archive.
To deploy the new jar file with the new bean:
target
directory to the Redeploy:
./insta= ll.sh
To activate the new bean or extension for SHA-256, edit the IdP configur=
ation file internal.xml
by adding the following element:
<bea= n id=3D"shibboleth.idp.ext.OpensamlCustomSecurityConfig" class=3D"edu.internet2.middleware.shibboleth.idp.ext.securityconfig.Ope= nsamlCustomSecurityConfigBean" depends-on=3D"shibboleth.OpensamlConfig"> <!-- primary algorithms for use with RSA signing keys --> <property name=3D"signatureAlgorithmRSA" value=3D"http://www.w3.org/= 2001/04/xmldsig-more#rsa-sha256"/> <property name=3D"signatureReferenceDigestMethod" value=3D"http://ww= w.w3.org/2001/04/xmlenc#sha256"/> <!-- other signature algorithms for use with other signing keys --&g= t; <property name=3D"signatureAlgorithmDSA" value=3D"http://www.w3= .org/2009/xmldsig11#dsa-sha256"/> <property name=3D"signatureAlgorithmEC" value=3D"http://www.w3.org/2= 001/04/xmldsig-more#ecdsa-sha256"/> <property name=3D"signatureAlgorithmAES" value=3D"http://www.w3.org/= 2001/04/xmldsig-more#hmac-sha256"/> <property name=3D"signatureAlgorithmDESede" value=3D"http://www.w3.o= rg/2001/04/xmldsig-more#hmac-sha256"/> </bean>
See this important document for a complete list of algorithms and their = uses: http://www.w3.org/TR/2013/N= OTE-xmlsec-algorithms-20130411/
Restart the IdP and use a tool like the SAML tracer for Firefox to capture a response sent from the IdP = to an SP. Note that depending on the configuration for the relying party, t= he SAML assertion may be encrypted and therefore the signature (if present)= will not visible, so you will want to test using a relying party that is c= onfigured for signing only with no encryption, or alternatively sign the re= sponse with or without a signed assertion. You will see the following pair = of elements in the SAML message, wherever an RSA key is used to sign:
<ds:= SignatureMethod Algorithm=3D"http://www.w3.org/2001/04/xmldsig-more#rsa-sha= 256"/> ... <ds:DigestMethod Algorithm=3D"http://www.w3.org/2001/04/xmlenc#sha256"/&= gt;
In any case, you can always turn up IdP logging for more information.