<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/19/20 4:09 PM, Martin Schneider
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1269196906.2235.1584648551500@appsuite-dev-gw1.open-xchange.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<div class="default-style"> Hi, </div>
<div class="default-style"> <br>
</div>
<div class="default-style"> I just started the migration from
OpenSAML 2 to v3.</div>
</blockquote>
<p>As Scott said, if you've just started, you would probably want to
use 4.0. The security config stuff is mostly or entirely unchanged
from v3 however.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1269196906.2235.1584648551500@appsuite-dev-gw1.open-xchange.com">
<div class="default-style"> In v2 we used
org.opensaml.xml.security.SecurityConfiguration.getSignatureAlgorithmURI(String)
to get the algorithm URI based on
java.security.Key.getAlgorithm(). </div>
</blockquote>
<p><br>
</p>
<p>The security configuration machinery works differently in v3/v4.
There is no direct replacement for that v2 method. Note that that
is not a simple mapping, there can be many algorithm URIs for say
key algo of "RSA": RSA with SHA-1, RSA with SHA-256, etc. What
that method returned was what was presently configured for that
key type. It defaulted to something, but it could be changed.<br>
</p>
<p>In v3 and v4, it works very differently. For signing: You have 1
or more instances of SignatureSigningConfiguration, which
enumerates (among other properties) the allowed algorithms in
precedence order for a given key type (e.g. "RSA"). If you have
2+ then those are explicitly used in a precedence order (think for
relying party overrides vs profile defaults vs library-wide
defaults, etc). You pass those -Configuration instances to a
SignatureSigningParametersResolver, which evaluates the
-Configuration instances to produce a SignatureSigningParameters,
which is what you sign with.</p>
<p>For examples of usage, the best thing would just be to look at
the unit tests for say the SignatureSigningParametersResolver.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:1269196906.2235.1584648551500@appsuite-dev-gw1.open-xchange.com">
<div class="default-style"> </div>
<div class="default-style"> I tried to find a comparable method in
v3 but without success. It seems that the algorithm URI is
always known while processing. Is it somehow possible to get the
algorithm URI based on the 'standard algorithm name' for keys
(like "DSA")?</div>
<br>
</blockquote>
<p><br>
</p>
<p>Note that there is no "standard algorithm name" for "DSA", "SHA",
etc. You have to also factor in the digest method it composes
with. Similar for encryption algorithms. There's multiple
choices for a given key type. In v2 it just defaulted one of
them.<br>
</p>
<p>The new machinery makes it easy to have different behavior for
different relying parties, or different profiles, or whatever else
makes sense. That's via multiple ordered -Configuration instances
that get turned by a -Resolver into a -Parameters at runtime.</p>
<p>--Brent</p>
<p><br>
</p>
</body>
</html>