mace-opensaml-users - RE: [OpenSAML] Verifying SAML signed metadata files
Subject: OpenSAML user discussion
List archive
- From: Paolo Selvini <>
- To: "" <>
- Subject: RE: [OpenSAML] Verifying SAML signed metadata files
- Date: Fri, 2 May 2008 19:48:02 +0200
- Accept-language: it-IT, en-US
- Acceptlanguage: it-IT, en-US
sure, I am using the latest 2.1.0 as Brent suggested in another thread.
Originally I could not even get the signature attribute out of the signed
metadata after parsing them, due to the bug in the previous version. This is
sort of a different problem, I guess, and apparently occurs only when using
accented chars
-----Original Message-----
From: Chad La Joie
[mailto:]
Sent: venerdì 2 maggio 2008 16.09
To:
Subject: Re: [OpenSAML] Verifying SAML signed metadata files
Are you using the latest version of OpenSAML (2.1). There was a bug where
some of the metadata providers were not properly reading the incoming stream
and so messed up the encoding.
Paolo Selvini wrote:
> Hi again and thanks for the hint about the metadata filter.
> I did as you suggested and I managed to correctly verify a signed metadata
> file.
>
> Now I have a (hopefully) last problem: my original metadata file contains a
> SPSSODescriptor element with a number of AttributeConsumingService
> elements. According to the specification, each of those can store one or
> more RequestedAttribute elements, possibly including a FriendlyName
> attribute.
>
> However, if I use - for the value of such FriendlyName attribute - some
> accented chars (like à, è, ...) that are pretty common in the Italian
> language, the signature in the new signed file is no more verified. That
> is, the same code used to sign and verify a metadata file without accented
> chars, no longer works it I change even just a single char (say from "a" to
> "à") in the unsigned file, sign it and verify it. If I replace the accented
> char back with a normal char, sign and verify again, everything is ok.
> What happens is a MetadataProviderException with inner cause
> "org.opensaml.saml2.metadata.provider.FilterException: Signature trust
> establishment failed for metadata entry" when I invoke the initialize()
> method on the metadata provider.
>
> FYI: both the unsigned and the signed files have UTF-8 encoding without BOM
> (byte order mark).
>
> Any idea about the possible cause?
>
> thanks,
> Paolo
>
>
> ________________________________
> From: Brent Putman
> [mailto:]
> Sent: martedì 29 aprile 2008 1.22
> To:
>
> Subject: Re: [OpenSAML] Verifying SAML signed metadata files
>
>
>
> Paolo Selvini wrote:
> Hi,
> I need to parse a signed metadata file and verify its signature against a
> given certificate.
> I am using version 2.1.0 of the OpenSAML library and now in fact the
> getSignature() method of EntityDescriptor returns a non null object.
> :-)
>
> For a clear start I got a sample signed metadata from the OpenSAML-J 2.1.0
> source code, in the file
> src\test\resources\data\org\opensaml\saml2\metadata\metadata.switchaai_signed.xml.
> Then I extracted the public certificate in PEM format from such file and I
> have subsequently saved it, to use in the code.
>
> The following is the code I used for reading and verifying the signed
> metadata file:
>
> FilesystemMetadataProvider fsmd = new FilesystemMetadataProvider(new
> File(signedMetadataFilename)); fsmd.setParserPool(new
> BasicParserPool()); fsmd.initialize(); EntityDescriptor
> signedEntityDescriptor = fsmd.getMetadata();
>
> The MetadataProvider impls drop the cached DOM after the provider is
> initialized in order to save memory. On the signature element, this also
> includes dropping the Apache XMLSignature object which has been cached from
> unmarshalling. Both would be necessary to validate the signature. In your
> case I think the ValidationException is getting getting (correctly) thrown
> by the SAMLSignatureProfileValidator, because the Apache XMLSignature
> instance is unavailable.
>
>
>
>
> What's wrong with the former way to read a metadata from the file system? I
> assume the same would happen with a FileBackedURLMetadataProvider.
>
> Yeah, the same thing would happen with the other provider.
>
> So because of this, you can't really validate the signature on the metadata
> by pulling the root object off and processing it, nor anything else that
> requires access to the cached DOM elements of the tree, such as DOM-level
> schema validation. This is the expected behavior.
>
> I would like to keep using the providers for reading metadata, as they
> embed the caching mechanism.
>
> The correct approach is to use a MetadataFilter. See the
> SignatureValidationFilter in the saml2.metadata.provider package. This
> requires the use of a SignatureTrustEngine, which is a higher-level API
> than the low-level SignatureValidator. To replicate what you currently do
> (validate against a known key/cert trusted explictly in advance), just use
> an ExplicitKeySignatureTrustEngine, built with a StaticCredentialResolver
> containing your trusted keys/cert(s).
>
> After building the filter, you'll just add to the provider with
> setMetadataFilter *before* you call fsmd.initialize(). If if fails
> validation, you'll get a FilterException.
>
> For examples of how to build the filter, see also the
> SignatureValidationFilterTest in
> src\test\resources\data\org\opensaml\saml2\metadata\provider.
>
>
> --Brent
>
>
> ________________________________
> Le informazioni contenute in questa comunicazione e negli allegati sono
> riservate; e' vietato a soggetti diversi dai destinatari qualsiasi uso,
> copia, diffusione di quanto in essi contenuto.
> Se avete ricevuto questa copia per errore, vi preghiamo di distruggerla
> immediatamente ed informarci via e-mail.
>
> Prima di stampare questa e-mail consideratene l'impatto sull'ambiente.
> Grazie per la collaborazione.
>
>
> This e-mail and any attachment(s) are strictly confidential. This message
> must not be copied, disclosed or used by anybody other than the intended
> recipient(s).
> If you are not the intended recipient, please inform the sender by e-mail
> and destroy this message immediately.
>
> Please consider the environment before printing this e-mail. Thank you for
> your cooperation.
>
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021
Zürich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68
,
http://www.switch.ch
Le informazioni contenute in questa comunicazione e negli allegati sono
riservate; e' vietato a soggetti diversi dai destinatari qualsiasi uso,
copia, diffusione di quanto in essi contenuto.
Se avete ricevuto questa copia per errore, vi preghiamo di distruggerla
immediatamente ed informarci via e-mail.
Prima di stampare questa e-mail consideratene l'impatto sull'ambiente. Grazie
per la collaborazione.
This e-mail and any attachment(s) are strictly confidential. This message
must not be copied, disclosed or used by anybody other than the intended
recipient(s).
If you are not the intended recipient, please inform the sender by e-mail and
destroy this message immediately.
Please consider the environment before printing this e-mail. Thank you for
your cooperation.
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/02/2008
- Re: [OpenSAML] Verifying SAML signed metadata files, Chad La Joie, 05/02/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/02/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Scott Cantor, 05/02/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/02/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/05/2008
- Re: [OpenSAML] Verifying SAML signed metadata files, Chad La Joie, 05/05/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/05/2008
- Re: [OpenSAML] Verifying SAML signed metadata files, Chad La Joie, 05/05/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/05/2008
- RE: [OpenSAML] Verifying SAML signed metadata files, Paolo Selvini, 05/02/2008
- Re: [OpenSAML] Verifying SAML signed metadata files, Chad La Joie, 05/02/2008
Archive powered by MHonArc 2.6.16.