(2013年07月17日 21:25), Jonathan Gagnon wrote:
On Tue, Jul 16, 2013 at 12:16 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
Jonathan Gagnon wrote:
It does not work when the SAML document is not referring to
any DTD. In my case, I receive the following exception when I
call the CheckSignature method :
System.Security.Cryptography.CryptographicException: Malformed
reference object: [referenceId]
at
System.Security.Cryptography.Xml.SignedXml.GetReferenceHash
(System.Security.Cryptography.Xml.Reference r, Boolean
check_hmac) [0x0] in filename unknown:0
at
System.Security.Cryptography.Xml.SignedXml.CheckReferenceIntegrity
(System.Collections.ArrayList referenceList) [0x0] in
filename unknown:0
at
System.Security.Cryptography.Xml.SignedXml.CheckSignatureInternal
(System.Security.Cryptography.AsymmetricAlgorithm key)
[0x0] in filename unknown:0
at System.Security.Cryptography.Xml.SignedXml.CheckSignature
(System.Security.Cryptography.AsymmetricAlgorithm key)
[0x0] in filename unknown:0
at TestSAML.Program.Main (System.String[] args) [0x0] in
filename unknown:0
Of course it happens because you should be processing
corresponding DTD or XML Schema.
The same code works in .NET and it does work if I modify the
GetIdElement method to check for ID.
So in your opinion, I should create a class that derives from
SignedXml and override GetIdElement?
I'm not sure I would like to answer yes (if you want to have ID
being processed) or no (you should actually process DTD or XSD).
I added references to the corresponding XSDs but it doesn't seem to
help. I'm still getting the same exception.
Because you didn't set up XmlDocument properly to process XSDs. (You're
discussing you're doing right without showing code.)
It does fix the problem for me. But wouldn't it be better to
modify SignedXml.GetIdElement() to behave more like .NET so
that other users don't encounter the same problem?
I don't support any use of API that violates W3C specification.
From what I understand, the W3C specification is only about the
signature part of a signed xml. There is nothing regarding other
parts of the signed XML, and the SAML standard defines the id
differently. So I'm not sure that supporting SAML ids would violate
the W3C specification.
I don't understand your discussion. Any additional local attributes that
do not conform to the XML Schema defined in xmldsig specification
violates XML schema validation.
Atsushi Eno
Though I'm just pointing out the facts. There may be people who
want to take responsibility on the entire XML Signature stuff and
go ahead to apply the changes.
Atsushi Eno
Thanks,
Jonathan
On Tue, Jul 16, 2013 at 10:24 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
Whenever SAML document instance refers to its schema or
DTD that
will validate ID attribute as expected, since SignedXml
internally uses XmlDocument.GetElementById () which is
expected to
collect IDs where IDs means a validated ID by
XmlValidatingReader or any XmlReader that has
XmlReaderSettings to
consider XmlSchema or DTD. Hence that does not cause any
problem
for SAML.
(Also note that SignedXml implementation could override
SignedXml.GetIdElement(). Mono's WCF implementation makes
use of
it to support WS-Security ID attribute.)
Atsushi Eno
Jonathan Gagnon wrote:
This is true for the signature, but not true for SAML
assertions, where ids are defined as ID :
http://schemas.stylusstudio.com/saml/nea261b70/complexType_AssertionType.html
I don't know in which case we would need id in
lowercase,
but since .NET supports it, there is probably a valid
reason
for it too.
*Jonathan Gagnon*
Responsable des architectures systèmes
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 tel:450-662-6101 tel:450-662-6101
tel:450-662-6101 poste 234
http://www.croesus.com
