<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>hi, <br>
</p>
<div class="moz-cite-prefix">On 21/02/2024 13:21, Peter Schober via
users wrote:<br>
</div>
<blockquote type="cite" cite="mid:ZdXq4gatV4PHek+m@aco.net">
<pre class="moz-quote-pre" wrap=""><a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:jehan.procaccia@tem-tsp.eu" moz-do-not-send="true">jehan.procaccia@tem-tsp.eu</a> <a
class="moz-txt-link-rfc2396E"
href="mailto:jehan.procaccia@tem-tsp.eu" moz-do-not-send="true"><jehan.procaccia@tem-tsp.eu></a> [2024-02-21 10:35 CET]:
</pre>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">2) in the Metadata of the SP (/**WantAssertionsSigned="true") *
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Again, this is actually telling the IDP "This SP has a bug and cannot
process signed Responses, please sign the Assertion instead".
Setting this it's not necessary to signal to the IDP "please sign, I
don't like to be sent SAML Responses/Assertions without any
authenticity/integrity at all" as that should be the norm, not
something you need explicit signalling for.
</pre>
</blockquote>
<p>OK then, so no need to override relying-party with <span
data-code-lang="xml" data-ds--code--code-block=""
class="prismjs cc-1j55rvq"><code class="language-xml"
style="white-space: pre;"><span class=""> </span><span
class="token tag token tag token punctuation"><</span><span
class="token tag token tag">bean</span><span class="token tag"> </span><span
class="token tag token attr-name">parent</span><span
class="token tag token attr-value token punctuation attr-equals">=</span><span
class="token tag token attr-value token punctuation">"</span><span
class="token tag token attr-value">SAML2.SSO</span><span
class="token tag token attr-value token punctuation">"</span><span
class="token tag"> </span><b><span
class="token tag token attr-name token namespace">p:</span><span
class="token tag token attr-name">signAssertions</span><span
class="token tag token attr-value token punctuation attr-equals">=</span><span
class="token tag token attr-value token punctuation">"</span><span
class="token tag token attr-value">true</span><span
class="token tag token attr-value token punctuation">"</span></b></code></span></p>
<p>nor <font size="2"><i> <span style="white-space: pre-wrap">Metadata of the SP (WantAssertionsSigned="true")</span></i></font></p>
<p>as it the default behaviour of the SP to sign (which indeed I saw
with BURP interceptions) <br>
</p>
<blockquote type="cite" cite="mid:ZdXq4gatV4PHek+m@aco.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">3) in the SP code implementation, it should verifiy the signature and hence
sees that the NameID value modification by the MITM broke the signature.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Did you say you removed the signature? Nothing broken, then?</pre>
</blockquote>
<p>yes removing the signature on the fly (MITM) allowed us to
impersonate on the SP, so this SP does not verify the signature. <br>
</p>
<p>it is up to the SP code (dotNet ) to check the signature, then I
must instruct the Vendor to do that, </p>
<p>in order to help them to patch their code, is there a
best-practice / doc of workflows , to do a correct <span
style="white-space: pre-wrap">authenticity/integrity of SAML exchanges which I can direct them to ?</span></p>
<blockquote type="cite" cite="mid:ZdXq4gatV4PHek+m@aco.net">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Moreover, which certificate should sign ?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The key the IDP publishes for that purpose, usually via its metadata?</pre>
</blockquote>
<p>Yes , IDP keys are in the Metadata, and there is one for encrypt
and another one for signing , as defaulted from IDP4 install
(idp.properties) [1] <br>
</p>
<p>[1]<br>
</p>
<p><i><font size="2">idp.signing.key=%{idp.home}/credentials/idp-signing.key<br>
idp.signing.cert=%{idp.home}<b>/credentials/idp-signing.crt</b><br>
idp.encryption.key=%{idp.home}/credentials/idp-encryption.key<br>
idp.encryption.cert=%{idp.home}/credentials/idp-encryption.crt</font></i></p>
<p>but the vendor SP doesn't provide certificate in its very
minimalist Metadata [2]</p>
<p>[2] <i><font size="2"><b><br>
</b></font></i></p>
<p><i><font size="2"><md:EntityDescriptor
cacheDuration="PT604800S" entityID=<a
class="moz-txt-link-rfc2396E"
href="https://vendor-sp.int.fr" moz-do-not-send="true">"https://vendor-sp.int.fr"</a>
validUntil="2030-10-18T09:55:33Z"><br>
<md:SPSSODescriptor AuthnRequestsSigned="false" <b>WantAssertionsSigned="false"</b>
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><br>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><br>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location=<a class="moz-txt-link-rfc2396E"
href="https://vendor-sp.int.fr/SpDotNet/Core/Log.aspx?"
moz-do-not-send="true">"https://vendor-sp.int.fr/SpDotNet/Core/Log.aspx?"</a>
index="1"/><br>
</md:SPSSODescriptor><br>
</md:EntityDescriptor><br>
</font></i></p>
<p>I guess that we must remove from that SP metadata the <b>WantAssertionsSigned="false"
</b>! or is doesn't matter as long as the IDP sign it anyway ?<i><font
size="2"><b> </b></font></i></p>
<blockquote type="cite" cite="mid:ZdXq4gatV4PHek+m@aco.net"><span
style="white-space: pre-wrap">
</span>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">finnaly it is safe not to encrypt SAML assertions as long a
signatures are well verified ?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">So definitively encrypting Responses/Assertions is safer/more secure,
it's widely supported (depending on whether you work more in
vendor-world or more in the open source or academic community) and
clearly the better choice -- assuming there even is a choice.
If the SP doesn't support it your only choice often comes down to not
using that SP's services. And whether that's an actual choice you have
possibly mostly depends on your relationship with your own management
and/or IT security / risk management team(s).</pre>
</blockquote>
<p>We are academic, but vendor not, and we need that SP services ,
so that's why I want to help them doing the right thing . <br>
</p>
<p>at least , if not encrypted, <b>sign</b> the SAML exchange so
that if a MITM occurs , the impersonate fails, which is not the
case right now ...</p>
<p>thanks , Jehan . <br>
</p>
<blockquote type="cite" cite="mid:ZdXq4gatV4PHek+m@aco.net">
<pre class="moz-quote-pre" wrap="">HTH,
-peter
</pre>
</blockquote>
</body>
</html>