Metadata Aggregator - Issues with XMLSignatureSigningStage

Chad La Joie lajoie at itumi.biz
Tue Jan 24 13:20:44 GMT 2012 

The only documentation is what is available on the website which
includes the general architecture.  Given that this is a general
processing pipeline, there is no right or wrong stage.  There are only
stages that either meet your particular needs and those that don't.

When I fix this bug, I'm going to create a stage that generates a
random ID.  Other users, I know, have particular ID generation
algorithms that use proprietary information to generate the ID.
Neither approach is right or wrong, just one meets some needs and the
other meets other needs.

On Tue, Jan 24, 2012 at 08:12, Dan McLaughlin
<dmclaughlin at tech-consortium.com> wrote:
> I'll file a new bug today.
>
> Is there an application requirements document, or even better, a design
> document for the MDA that you could share? If we were to spend the time to
> add the code to the MDA to fix this, I'd want to make sure we were doing it
> only if we were writing to and existing MDA design document. In other words,
> there's no since in us writing a fix to create this stage to add the ID if
> it's not how you had intended it to be written.
>
> On Tuesday, January 24, 2012, Chad La Joie <lajoie at itumi.biz> wrote:
>> You've correctly diagnosed the problem but not the solution.  The
>> EntityDescriptorItemIdPopulationStage is meant for something else[1].
>>
>> So, for now, you should do two things.  First, file a bug.  Second,
>> create a stage that generates and sets an ID on an EntityDescriptor or
>> EntitiesDescriptor (which is what I'll do when I fix the issue).
>>
>> [1] This stage is meant to take the identifier of an EntityDescriptor
>> and add it to the metadata of the given item.  That is, it takes a
>> SAML specific thing and copies it to a protocol agnostic location so
>> that other plugins can work on it.  Once the MDA web service is
>> available, this is also how it will look up information by ID.
>>
>> On Mon, Jan 23, 2012 at 23:25, Dan McLaughlin
>> <dmclaughlin at tech-consortium.com> wrote:
>>> The new version of the MDA seemed to work fine, then today I actually
>>> tried to get our SP to consume the metadata it aggregated and signed,
>>> but every time I enabled the Signature MetadataFilter to validate the
>>> signature I would get an error telling me "CRIT Shibboleth.Application
>>> : error initializing MetadataProvider: SignatureMetadataFilter unable
>>> to verify signature at root of metadata instance."
>>>
>>> I assumed maybe my private/public key pair I was using to sign and
>>> validate the metadata was bad, so I used openssl to verify that the
>>> private key I used with the MDA to sign the metadata matched the
>>> public key I was using in the SP to validate the signature.  Long
>>> story short, openssl confirmed they matched.
>>>
>>> Then I used xmlsectool to validate the signature on the metadata
>>> generated by MDA and it complained as well, but gave me a little more
>>> detail.
>>>
>>> xmlsectool.sh --verifySignature --certificate
>>> ./certs/my-signing-cert.pem --inFile
>>> /tmp/mda/federation/my-federation-metadata.xml
>>> INFO  XmlSecTool - Reading XML document from file
>>> '/tmp/mda/federation/my-federation-metadata.xml'
>>> INFO  XmlSecTool - XML document parsed and is well-formed.
>>> ERROR XmlSecTool - Unknown error
>>> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
>>> at java.lang.String.substring(String.java:1937) ~[na:1.6.0_29]
>>> at java.lang.String.substring(String.java:1904) ~[na:1.6.0_29]
>>> at
>>> edu.internet2.middleware.security.XmlSecTool.validateSignatureReferenceUri(XmlSecTool.java:623)
>>> ~[xmlsectool-1.1.5.jar:na]
>>> at
>>> edu.internet2.middleware.security.XmlSecTool.validateSignatureReference(XmlSecTool.java:602)
>>> ~[xmlsectool-1.1.5.jar:na]
>>> at
>>> edu.internet2.middleware.security.XmlSecTool.verifySignature(XmlSecTool.java:554)
>>> ~[xmlsectool-1.1.5.jar:na]
>>> at edu.internet2.middleware.security.XmlSecTool.main(XmlSecTool.java:156)
>>> ~[xmlsectool-1.1.5.jar:na]
>>>
>>> Which led me to
>>>
>>> https://issues.shibboleth.net/jira/browse/XSTJ-15?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
>>>
>>> Then I decided to add an XMLSignatureValidationStage to my MDA
>>> configuration to validate the signature after the MDA signed it, and I
>>> got the following error:
>>>
>>> mda.sh /tmp/mda/my-federation-config.xml validateSignature
>>> 2012-01-23 19:39:46,391 - WARN
>>> [org.apache.xml.security.signature.Reference:-1] - Verification failed
>>> for URI ""
>>> 2012-01-23 19:39:46,394 - WARN
>>> [org.apache.xml.security.signature.Reference:-1] - Expected Digest:
>>> I0I+qxu89yE2c6grAFkgO+IbgaEv9DIhCYiGe+JDA/Q=
>>> 2012-01-23 19:39:46,395 - WARN
>>> [org.apache.xml.security.signature.Reference:-1] - Actual Digest:
>>> usLmjOJIFNbagPGDEVXW0C0fhwLEtZ8jt0FWWx0/VIA=
>>>
>>> As I test I manually added an ID (ID=MYM20120123T194212) to the
>>> EntitiesDescriptor that the MDA created using the
>>> EntitiesDescriptorAssemblerStage, then I used xmlsectool to sign the
>>> metadata using --referenceIdAttributeName ID.  Now I had no issues
>>> validating the signature.
>>>
>>> ./xmlsectool.sh --sign --referenceIdAttributeName ID --inFile
>>> /tmp/mda/federation/my-federation-metadata-unsigned.xml --key
>>> ../certs/my-signing-key.pem --certificate ../certs/my-signing-cert.pem
>>> --outFile /tmp/mda/federation/my-federation-metadata.xml
>>> INFO  XmlSecTool - Reading XML document from file
>>> '/tmp/mda/federation/my-federation-metadata-unsigned.xml'
>>> INFO  XmlSecTool - XML document parsed and is well-formed.
>>> INFO  XmlSecTool - XML document successfully signed
>>> INFO  XmlSecTool - XML document written to file
>>> /tmp/mda/federation/my-federation-metadata.xml
>>>
>>> ./xmlsectool.sh --verifySignature --signatureRequired --certificate
>>> ../certs/my-signing-cert.pem --inFile
>>> /tmp/mda/federation/my-federation-metadata.xml
>>> INFO  XmlSecTool - Reading XML document from file
>>> '/tmp/mda/federation/my-federation-metadata.xml'
>>> INFO  XmlSecTool - XML document parsed and is well-formed.
>>> INFO  XmlSecTool - XML document signature verified.
>>>
>>> I think I'm on the right track...
>>>
>>> The signature that the MDA is adding isn't valid because the Reference
>>> URI for the Signature isn't getting set by my
>>> XMLSignatureSigningStage, the reason the Reference URI isn't getting
>>> set is because the EntitiesDescriptorAssemblerStage doesn't set the ID
>>> for the EntitiesDescriptor, the reason the ID isn't getting set for
>>> the EntitiesDescriptor is because I don't have a
>>> EntityDescriptorItemIdPopulationStage, and the reason I don't have an
>>> EntityDescriptorItemIdPopulationStage is because I used the examples
>>> to build my MDA configuration (which also don't use an
>>> EntityDescriptorItemIdPopulationStage), so I never realized until
>>> after several hours of debugging today that it was even necessary.
>>>
>>> Now for the difficult question...Does anyone have an example that
>>> shows how to properly define an EntityDescriptorItemIdPopulationStage
>>> so I can get an ID assigned to my EntitiesDescriptor?
>>> --
>>> To unsubscribe from this list send an email to
>>> dev-unsubscribe at shibboleth.net
>>
>>
>>
>> --
>> Chad La Joie
>> www.itumi.biz
>> trusted identities, delivered
>> --
>> To unsubscribe from this list send an email to
>> dev-unsubscribe at shibboleth.net
>>
>
> --
>
> --
>
> Thanks,
>
> Dan McLaughlin
> Technology Consortium, LLC
> dmclaughlin at tech-consortium.com
> mobile: 512.633.8086
> http://www.tech-consortium.com
>
> NOTICE: This e-mail message and all attachments transmitted with it are for
> the sole use of the intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure or
> distribution is strictly prohibited. The contents of this e-mail are
> confidential and may be subject to work product privileges. If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>
> Need to schedule a meeting??? http://www.tungle.me/DanMcLaughlin
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

More information about the dev mailing list