OpenSAML 3: how to get algorithm URI?

[Brent Putman]

On 3/19/20 4:09 PM, Martin Schneider wrote:
> Hi,
>
> I just started the migration from OpenSAML 2 to v3.

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.


> In v2 we used 
> org.opensaml.xml.security.SecurityConfiguration.getSignatureAlgorithmURI(String) 
> to get the algorithm URI based on java.security.Key.getAlgorithm().


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.

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.

For examples of usage, the best thing would just be to look at the unit 
tests for say the SignatureSigningParametersResolver.


> 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")?
>

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.

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.

--Brent


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20200319/d552871c/attachment-0001.html>