Signature-limitations on HTTPRedirectDeflateEncoder

[Brent Putman]

On 8/31/16 9:41 AM, Cantor, Scott wrote:
> On 8/31/16, 8:35 AM, "dev on behalf of Lasse Højgaard" <dev-bounces at shibboleth.net on behalf of lash at stibosystems.com> wrote:
>
>> So: is the documentation wrong, or is there some technical explanation for this
>> limitation?
> I suspect it's documentation copied from older versions and is wrong. 

Yes, it is copied from v2 and it is wrong.  It actually was never even
true in v2.  Even there in v2 we always pulled the algorithm to use from
the global SecurityConfiguration in use.  However, the setting was
global, so not as useful in practice.

In v3 you can supply the algorithm just like for other signing, via the
SignatureSigningParameters of the SecurityParametersContext of the
outbound MessageContext.

I think this actually may have just come from the language in the
binding spec, which only explicitly mentions RSA and DSA with SHA1.

In any case, I'll fix the Javadocs.


> The algorithm identifiers come from the XML Signature standard, so as long as we have the necessary mappings in place, any of them should work, including ECDSA.

Yes, exactly.  For example, any of the RSA, DSA and ECDSA variants with
any of the SHA-2 variants should work, as long as the algorithm URI is
known to the library via an appropriate AlgorithmDescriptor, and the JVM
has the corresponding runtime support.  Even an HMAC one would work, if
you supplied a symmetric key credential (with SecretKey) and the
appropriate algorithm URI.

New locally-defined AlgorithmDescriptors can be registered on the
AlgorithmRegistry instance used.  So even algorithms that don't come
with OpenSAML out-of-the-box can be used, as long as you have a JCA
security provider that implements it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160901/a52a990f/attachment.html>