SHA 256 XMLEnc Signature support - possible interoperability issue

1,238 views
Skip to first unread message

Stefano Gargiulo

unread,
Jul 21, 2010, 8:06:24 AM7/21/10
to simple...@googlegroups.com
Hi, i'm testing interoperability between simplesamlphpￜ SP and Micrsosoft ADFSv2 IdP (using SAML not ws-fed). I've some trouble in validation of the xml signature of the saml assertion received from the idp.

If i modifiy the line 193 (SS version 1.5) inￜ /simplesamlphp/modules/saml2/lib/Message.phpￜ in this way:
ï¿œreturn true;// $element->validate($key);
i can get all stuff workin, elsewhere i getￜ signature validation failed.

looking around in the code it seems to me that simplesamlphp support just SHA1 digest algorithm,ￜ while i realized that geneva server (ADFSv2) is sending to me SHA256 digests..ￜ

But maybe i'm wrong and this is just a configuration issue.

So my question is is simplesamlphp able to use SHA-256 algorithm for the digests of the XMLEnc saml assertions?ￜ (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256si)

Best regards,
Stefano.


Olav Morken

unread,
Jul 21, 2010, 8:58:49 AM7/21/10
to simple...@googlegroups.com
On Wed, Jul 21, 2010 at 14:06:24 +0200, Stefano Gargiulo wrote:
> Hi, i'm testing interoperability between simplesamlphp SP and

> Micrsosoft ADFSv2 IdP (using SAML not ws-fed). I've some trouble in
> validation of the xml signature of the saml assertion received from
> the idp.
>
> If i modifiy the line 193 (SS version 1.5) in
> /simplesamlphp/modules/saml2/lib/Message.php in this way:

> > return true;// $element->validate($key);
> i can get all stuff workin, elsewhere i get signature validation failed.

>
> looking around in the code it seems to me that simplesamlphp support
> just SHA1 digest algorithm, while i realized that geneva server

> (ADFSv2) is sending to me SHA256 digests..

Just to be clear: It is the DigestMethod that uses the
«http://www.w3.org/2001/04/xmlenc#sha256» algorithm? It isn't the
SignatureMethod algorithm?

> But maybe i'm wrong and this is just a configuration issue.
>
> So my question is is simplesamlphp able to use SHA-256 algorithm for

> the digests of the XMLEnc saml assertions? (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256si <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256>)

I believe the «http://www.w3.org/2001/04/xmlenc#sha256» digest
algorithm should be supported by the library we use, though I have
never tested it.

Some other things to check:
- Make sure that you are running at least version 5.2 of PHP. Older
versions may have problems performing the canonicalization step of
the signature validation.
- Check that the certificate you have added in the idp-remote metadata
actually matches the certificate the message is sent with.


You can dump the received message by inserting something like the
following in any code that executes before the error (for example
right before the modification you made in Message.php):

file_put_contents('/tmp/response.xml', base64_decode($_REQUEST['SAMLResponse']));

--
Olav Morken
UNINETT / Feide

Hans Zandbelt

unread,
Jul 21, 2010, 9:03:24 AM7/21/10
to simple...@googlegroups.com
Stefano Gargiulo wrote, On 7/21/10 2:06 PM:
> Hi, i'm testing interoperability between simplesamlphp SP and

> Micrsosoft ADFSv2 IdP (using SAML not ws-fed). I've some trouble in
> validation of the xml signature of the saml assertion received from the
> idp.
>
> If i modifiy the line 193 (SS version 1.5) in
> /simplesamlphp/modules/saml2/lib/Message.php in this way:
>> return true;// $element->validate($key);
> i can get all stuff workin, elsewhere i get signature validation failed.

>
> looking around in the code it seems to me that simplesamlphp support
> just SHA1 digest algorithm, while i realized that geneva server

> (ADFSv2) is sending to me SHA256 digests..
>
> But maybe i'm wrong and this is just a configuration issue.

The SHA256 is the default algorithm in ADFSv2; you can reconfigure it to
use SHA1.

Regards,

Hans.

>
> So my question is is simplesamlphp able to use SHA-256 algorithm for the

> digests of the XMLEnc saml assertions?
> (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256si
> <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256>)
>

> Best regards,
> Stefano.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "simpleSAMLphp" group.
> To post to this group, send email to simple...@googlegroups.com.
> To unsubscribe from this group, send email to
> simplesamlph...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/simplesamlphp?hl=en.


--
Hans Zandbelt hans.z...@surfnet.nl
SURFnet http://www.surfnet.nl

Stefano Gargiulo

unread,
Jul 21, 2010, 10:49:18 AM7/21/10
to simple...@googlegroups.com, Olav Morken
Il 21/07/2010 14:58, Olav Morken ha scritto:
Just to be clear: It is the DigestMethod that uses the 
ￜhttp://www.w3.org/2001/04/xmlenc#sha256ￜ algorithm? It isn't the 
SignatureMethod algorithm?
Both:
ADFS IdP SAML message headers were the following:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#_67ccfc9e-1c6c-4d4a-b93a-e3407ed35733">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ds:DigestValue>bNoowHZaosAVHCYUHT1raY9+ge/x3kyx+8HeyQHTEg4=</ds:DigestValue></ds:Reference></ds:SignedInfo>

But this was printed on a Shibboleth2 SP, from the same ADFSv2 IdP

On the simpleSAMLphp SP we never was able to initiate the SAML "dialog" (it failed on ADFS side after first redirect)
So sysadmin of the ADFSv2 IdP told me that he saw in the logs an error message reporting that the simpleSAMLphp
was signing messages in SHA1 instead the expected SHA256.

After that he "enforced" SHA1 for my SP on the IdP and SAML2 session initiation worked well (ipd accepted my SHA1 signed messages),
but the process failed on my SP assertion consumer service as i reported in latter mail.

But i was wrongly beliving that ADFS IDP was sending to me SHA-256 signed messages,ￜ but it wasn't:

it seemsￜ that it is not signing the assertions and sending to me an encryptedkey, this is last dump:

<samlp:Response ID="_2a360437-880c-4d7e-853e-00a7d0583198" Version="2.0" IssueInstant="2010-07-21T13:53:19.357Z" Destination="https://sp.urlomississ" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_bcb76913a9c35eebfd5c0b16cc3558d195f5e4e52d" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://adfs.urlomississ</Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status><EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
</e:EncryptionMethod>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509IssuerSerial><ds:X509IssuerName>CN=SP, OU=CN, O=Omissis, L=Rome, S=Italy, C=IT</ds:X509IssuerName>
<ds:X509SerialNumber>16352355047834284434</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X509Data>
</KeyInfo>
<e:CipherData><e:CipherValue>...encrypted data of key omissis...</e:CipherValue></e:CipherData></e:EncryptedKey>
</KeyInfo>
<xenc:CipherData><xenc:CipherValue>...encryped data omissis..</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></EncryptedAssertion></samlp:Response>

So my questions now are:

1) why i get following error if there isn't any signature in the saml message (or if there is, it is yet encrypted at this point of the processing)? 
Unable to validate Signature

0: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Utils.php:100 (SAML2_Utils::validateSignature)
1: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Assertion.php:490 (SAML2_Assertion::validate)
2: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:193 (sspmod_saml2_Message::checkSign)
3: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:684 (sspmod_saml2_Message::processResponse)

is this a bug? wrong moment to try to get the signature? or idp assertion is malformed? (i don't know, i've no deep knowlegde of saml)
2) Can i enforce simplesamlphp to use SHA256 to sign all outgoing saml requests (also the initiation)?ￜ (in this way i can ask the ADFS IdP sysadmin to restore him intial SHA-256 configuration)?

Some other things to check:
- Make sure that you are running at least version 5.2 of PHP. Older
i'm runningￜ PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 
- Check that the certificate you have added in the idp-remote metadata 
  actually matches the certificate the message is sent with.
yes it matches,ￜￜ SP also able to decrypt and get SAML attributes of an user from the encrypted assertion reported above. (if i leave the hack on signature validation code)


You can dump the received message by inserting something like the 
following in any code that executes before the error (for example
right before the modification you made in Message.php):

    file_put_contents('/tmp/response.xml', base64_decode($_REQUEST['SAMLResponse']));
Awesome, i was looking for a way to do this, thank you!


Thank you for the attention.

Best regards,
Stefano.


Olav Morken

unread,
Jul 22, 2010, 2:56:41 AM7/22/10
to simple...@googlegroups.com
On Wed, Jul 21, 2010 at 16:49:18 +0200, Stefano Gargiulo wrote:
> Il 21/07/2010 14:58, Olav Morken ha scritto:
> >Just to be clear: It is the DigestMethod that uses the
> >«http://www.w3.org/2001/04/xmlenc#sha256» algorithm? It isn't the

> >SignatureMethod algorithm?
> Both:
> ADFS IdP SAML message headers were the following:
[...]

>
> But this was printed on a Shibboleth2 SP, from the same ADFSv2 IdP
>
> On the simpleSAMLphp SP we never was able to initiate the SAML
> "dialog" (it failed on ADFS side after first redirect)
> So sysadmin of the ADFSv2 IdP told me that he saw in the logs an
> error message reporting that the simpleSAMLphp
> was signing messages in SHA1 instead the expected SHA256.
>
> After that he "enforced" SHA1 for my SP on the IdP and SAML2 session
> initiation worked well (ipd accepted my SHA1 signed messages),
> but the process failed on my SP assertion consumer service as i
> reported in latter mail.
>
> But i was wrongly beliving that ADFS IDP was sending to me SHA-256
> signed messages, but it wasn't:
>
> it seems that it is not signing the assertions and sending to me an

> encryptedkey, this is last dump:
[...]

> So my questions now are:
>

> *1)* why i get following error if there isn't any signature in the


> saml message (or if there is, it is yet encrypted at this point of
> the processing)?
>
> >Unable to validate Signature
> >
> >0: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Utils.php:100 (SAML2_Utils::validateSignature)
> >1: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Assertion.php:490 (SAML2_Assertion::validate)
> >2: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:193 (sspmod_saml2_Message::checkSign)
> >3: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:684 (sspmod_saml2_Message::processResponse)
> is this a bug? wrong moment to try to get the signature? or idp assertion is malformed? (i don't know, i've no deep knowlegde of saml)

Since the assertion is encrypted, you cannot see the signature on it at
that point, since the signature is within the encrypted data.
Decryption obviously works, since you wouldn't reach that point in the
code without decrypting the assertion.

To dump the decrypted assertion, in lib/SAML2/Utils.php, in the
decryptElement()-method, right after the line that reads:

$decrypted = $enc->decryptNode($symmetricKey, FALSE);

insert something like:

file_put_contents('/tmp/assertion.xml', $decrypted);

> *2)* Can i enforce simplesamlphp to use SHA256 to sign all outgoing
> saml requests (also the initiation)? (in this way i can ask the


> ADFS IdP sysadmin to restore him intial SHA-256 configuration)?

No, at the moment we only support the rsa-sha1 signature method. Adding
support for others will require rather large changes. In addition, PHP
didn't introduce support for the rsa-sha256 algorithm before version
5.3, so any such changes would also require a newer version of PHP.


For now, I have added issue 331 about this, but I don't think it
will be implemented in the near future:

http://code.google.com/p/simplesamlphp/issues/detail?id=331

Stefano Gargiulo

unread,
Jul 27, 2010, 9:04:31 AM7/27/10
to simple...@googlegroups.com
Since the assertion is encrypted, you cannot see the signature on it at 
that point, since the signature is within the encrypted data. 
Decryption obviously works, since you wouldn't reach that point in the 
code without decrypting the assertion.

To dump the decrypted assertion, in lib/SAML2/Utils.php, in the 
decryptElement()-method, right after the line that reads:

    $decrypted = $enc->decryptNode($symmetricKey, FALSE);

insert something like:

    file_put_contents('/tmp/assertion.xml', $decrypted);



Thank you so much! this is the result:


<Assertion ID="_ba878e7d-cd97-4cb7-91ac-1ee31375721f" IssueInstant="2010-07-27T12:46:08.090Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://...omissis....</Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_ba878e7d-cd97-4cb7-91ac-1ee31375721f">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>3NdJyG7j/owFuHXmVLgKQGA7vSs=</ds:DigestValue></ds:Reference></ds:SignedInfo>
<ds:SignatureValue>KkOJzeT3sIidOyea5/Op5g...omissis...</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3DCCAcSgAwIBAg=...omissis...</ds:X509Certificate></ds:X509Data>
</KeyInfo></ds:Signature>
<Subject><NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"....omissis


So ADFS IdP is sending correclty SHA1 signature and digest, but i'm stuck getting this error:

Unable to validate Signature

0: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Utils.php:100 (SAML2_Utils::validateSignature)
1: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Assertion.php:490 (SAML2_Assertion::validate)
2: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:196 (sspmod_saml2_Message::checkSign)
3: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:687 (sspmod_saml2_Message::processResponse)
4: /var/www/idemauth/components/com_idemauth/simplesamlphp/www/saml2/sp/AssertionConsumerService.php:107 (N/A)
			

Maybe is due to the fact that in federation metadata the ADFS IdP exposes sha256 signature and digest hashes and simpleSAMLphp validate against this????


<EntityDescriptor ID="_5baeecbf-5302-48fa-9fed-fa6307e6209c" entityID="http://omissis...">
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
                  <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
                  <ds:Reference URI="#_5baeecbf-5302-48fa-9fed-fa6307e6209c">
                        <ds:Transforms>

                              <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform
>
                              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
                        <ds:DigestValue>Gmutw/Mci1vYwujUm....omissis</ds:DigestValue>
                  </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>VJk


Anyway i wanna goo deeper into debug but i'm not able to do this

the code throwing the exception is:


 $objXMLSecDSig = $info['Signature'];

                /* Check the signature. */
                if (! $objXMLSecDSig->verify($key)) {
                        throw new Exception("Unable to validate Signature");
                }



where can i find the method $objXMLSecDSig->verify($key) to put some prints?

Thank you,

Stefano.


    

    

    Il 22/07/2010 08:56, Olav Morken ha scritto:
    

      
On Wed, Jul 21, 2010 at 16:49:18 +0200, Stefano Gargiulo wrote:


      

        
 Il 21/07/2010 14:58, Olav Morken ha scritto:


        

          
Just to be clear: It is the DigestMethod that uses the
ￜhttp://www.w3.org/2001/04/xmlenc#sha256ￜ algorithm? It isn't the
SignatureMethod algorithm?


        
Olav Morken
unread,
Jul 29, 2010, 1:49:05 AM7/29/10
to simple...@googlegroups.com
On Tue, Jul 27, 2010 at 15:04:31 +0200, Stefano Gargiulo wrote:
> 
> 
> >Since the assertion is encrypted, you cannot see the signature on it at
> >that point, since the signature is within the encrypted data.
> >Decryption obviously works, since you wouldn't reach that point in the
> >code without decrypting the assertion.
> >
> >To dump the decrypted assertion, in lib/SAML2/Utils.php, in the
> >decryptElement()-method, right after the line that reads:
> >
> >     $decrypted = $enc->decryptNode($symmetricKey, FALSE);
> >
> >insert something like:
> >
> >     file_put_contents('/tmp/assertion.xml', $decrypted);
> 
> 
> Thank you so much! this is the result:
> 
[...]

> 
> 
> So ADFS IdP is sending correclty SHA1 signature and digest, but i'm stuck getting this error:
> 
> 
> Unable to validate Signature
> 
> 0: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Utils.php:100 (SAML2_Utils::validateSignature)
> 1: /var/www/idemauth/components/com_idemauth/simplesamlphp/lib/SAML2/Assertion.php:490 (SAML2_Assertion::validate)
> 2: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:196 (sspmod_saml2_Message::checkSign)
> 3: /var/www/idemauth/components/com_idemauth/simplesamlphp/modules/saml2/lib/Message.php:687 (sspmod_saml2_Message::processResponse)
> 4: /var/www/idemauth/components/com_idemauth/simplesamlphp/www/saml2/sp/AssertionConsumerService.php:107 (N/A)
> 			
> 
> 
> Maybe is due to the fact that in federation metadata the ADFS IdP exposes sha256 signature and digest hashes and simpleSAMLphp validate against this????
[...]
No, it doesn't look at the signature on the metadata at all.
> Anyway i wanna goo deeper into debug but i'm not able to do this
> 
> the code throwing the exception is:
> 
> >  $objXMLSecDSig = $info['Signature'];
> >
> >                 /* Check the signature. */
> >                 if (! $objXMLSecDSig->verify($key)) {
> >                         throw new Exception("Unable to validate Signature");
> >                 }
> 
> where can i find the method $objXMLSecDSig->verify($key) to put some prints?
This is in lib/xmlseclibs.php, line 1042. It should be noted that at 
this point most of the assertion is verified. This function just 
verifies the signature on the SignedInfo element itself. This means 
that except for the signature method (rsa-sha1) there is only two 
things that can be wrong at that point:
 - The canocalization of the SignedInfo element.
 - The key used to validate the SignedInfo element.
Have you verified that the certificate you have registered for the IdP 
is the same as the one located in the <ds:X509Certificate>-element?
-- 
Olav Morken
Stefano Gargiulo
unread,
Jul 29, 2010, 5:12:26 AM7/29/10
to simple...@googlegroups.com, Olav Morken

> This is in lib/xmlseclibs.php, line 1042. It should be noted that at
> this point most of the assertion is verified. This function just
> verifies the signature on the SignedInfo element itself. This means
> that except for the signature method (rsa-sha1) there is only two
> things that can be wrong at that point:
>
>   - The canocalization of the SignedInfo element.
>   - The key used to validate the SignedInfo element.
>
> Have you verified that the certificate you have registered for the IdP
> is the same as the one located in the<ds:X509Certificate>-element?
The key matches.
This is the certificate we got into metadata:
>
> <KeyDescriptor use="encryption">
> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:X509Data>
> <ds:X509Certificate>MIIC4jCCAcqgAwIBAgIQeq8XiFWW3KNJ44ydf9RQ7zANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJBREZTIEVuY3J5cHRpb24gLSBpZHB0ZXN0LnVuaWJvLml0MB4XDTEwMDcwODA5Mjg1NVoXDTExMDcwODA5Mjg1NVowLTErMCkGA1UEAxMiQURGUyBFbmNyeXB0aW9uIC0gaWRwdGVzdC51bmliby5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxyKjWDtY2/Cb3c9rBgwjho5DC2vvN/EI7VvPNEBWXh2Chfv5ff9Hy0FAxQFZ3QIOlRPua1cOuJ522/snatDYARfMmy/SM8si9bxO+JLjuTzVuyf+ddGaj5z+kjriauY2IpLRbfjLxo3iMPDUUrXUvAUCYAs7rTFGIQHt+WOU7vDn5emDpPg55xIcgRXP/PZQz7mxbwUHClQ1JamIex/Q8A4xuvUGHrc9/lee083ei4xztyT9ARffs1byovkE5dA3I7CkY8Cm+37hrUTa6tEwqfprq+P1mYnITOwouhuzgEDRsWmMPsGQmOgdks1JM0mOqP+0lHOpcnS4dwZxxiqjECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAgF6BA3zlvgo1abgUlimt+Y9gjQaDVP/GZ7PooxLSOaBaem9upz8K1aO3j/j+9b6GzX2sfHci6tkB8ljrZ+JOkz73wb6sc+7jE2HNKjEnkEHEeTgkVfP2reTMPpeKSnetCIJ/khq1s811xyl+3+goFAiNZ8BMwHSjseSpsll69BiN4OVa75X/QTU7etAFmsjWNe468Q/KRfy1CV1qbDA4D2Ve/y5/4qd8PuZhSyKeTyCt44FKY/2C54hhkWZAXcThmBsTJqSY703sKD+544Lk6TxqjeJ6wnatOS31G+Vv5KV5aaQ48lHBe0UTnOjy9H7c46Y/cMi+..OMISSISS...</ds:X509Certificate> 
>
> </ds:X509Data>
> </ds:KeyInfo>
> </KeyDescriptor>
> <KeyDescriptor use="signing">
> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:X509Data>
> <ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQaXB/Z8qMjYdOIuCfNx+doTANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBpZHB0ZXN0LnVuaWJvLml0MB4XDTEwMDcwODA5Mjg1NFoXDTExMDcwODA5Mjg1NFowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gaWRwdGVzdC51bmliby5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvN/up9rC27MVBJ2dA0L8bry+L4B9s23Aoh5ovHEEl0x972Axhxz9JSc6muLXtNyezegcYfmMVLUXOU/pNoBHRtRns89B0o/sJ1OeKdQmUdJuSbzD2hzsxQiIJCyOPbRfRvmBA0TouvNPyOoAmIBhrfG1vACXncgdOKE1sVZY5nmS9plJMrINjmVwvNS2yo5XKCSjw1GlbW4Iw+Jr1YNM7yxNEvk0jKYYAazoQYBO/bD3LGdKplSp02if00uDDNCRugsF/4rJL5FzIeKkvR07UYwSiV1yIOgTwsBbUEZ8JLBN0nc3VrLsQKwJGfiosWytO3jzGBU3silqiIW/C5nNECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEASJDuHiVITi64TJg0w3NMeZvzCdFcTfk/1KGhdjLeV0vI/B6pA1NLr7bqKZEGIDTwMMVvS2vuLsymnkNFu/kdUNZYLw5RpmiEvVYjC20lPI538xdts9hK6GQ4wQFD5MxyHKpsj028pXZFXlCfxsajmTtLCRBjHVQ1GBU78z3rxe2Md6jvbGOyKe9qfvWYyyO+n3Sn64SNmjRqauupcZd67WhHeHno51frZmF4t65v3pC+yqz1jvAVXlE7rm29O3bG+nS0/atcZE08Q6FM0ZY+...OMISSIS...</ds:X509Certificate> 
>
> </ds:X509Data> 
and this the one into the SAML response signature:
> <KeyInfo 
> xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQaXB/Z8qMjYdOIuCfNx+doTANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBpZHB0ZXN0LnVuaWJvLml0MB4XDTEwMDcwODA5Mjg1NFoXDTExMDcwODA5Mjg1NFowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gaWRwdGVzdC51bmliby5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvN/up9rC27MVBJ2dA0L8bry+L4B9s23Aoh5ov
> HEEl0x972Axhxz9JSc6muLXtNyezegcYfmMVLUXOU/pNoBHRtRns89B0o/sJ1OeKdQmUdJuSbzD2hzsxQiIJCyOPbRfRvmBA0TouvNPyOoAmIBh
> rfG1vACXncgdOKE1sVZY5nmS9plJMrINjmVwvNS2yo5XKCSjw1GlbW4Iw+Jr1YNM7yxNEvk0jKYYAazoQYBO/bD3LGdKplSp02if00uDDNCRug
> sF/4rJL5FzIeKkvR07UYwSiV1yIOgTwsBbUEZ8JLBN0nc3VrLsQKwJGfiosWytO3jzGBU3silqiIW/C5nNECAwEAATANBgkqhkiG9w0BAQsFAAOCA
> QEASJDuHiVITi64TJg0w3NMeZvzCdFcTfk/1KGhdjLeV0vI/B6pA1NLr7bqKZEGIDTwMMVvS2vuLsymnkNFu/kdUNZYLw5RpmiEvVYjC20lPI538xdt
> s9hK6GQ4wQFD5MxyHKpsj028pXZFXlCfxsajmTtLCRBjHVQ1GBU78z3rxe2Md6jvbGOyKe9qfvWYyyO+n3Sn64SNmjRqauupcZd67WhHeHno51frZmF4
> t65v3pC+yqz1jvAVXlE7rm29O3bG+nS0/atcZE08Q6FM0ZY...</ds:X509Certificate>

> </ds:X509Data></KeyInfo></ds:Signature>
So  what can i do to test if canocalization is done correctly?

Best regards,
Stefano.
Olav Morken
unread,
Jul 29, 2010, 6:25:04 AM7/29/10
to simple...@googlegroups.com
Hmmm... those are two different keys, one for encryption and one for 
signing. This isn't supported properly by simpleSAMLphp yet, so maybe 
it is trying to verify the signature with the encryption-key? Could you 
check which certificate is added as certData in the parsed metadata?
> and this the one into the SAML response signature:
> 
> ><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQaXB/Z8qMjYdOIuCfNx+doTANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBpZHB0ZXN0LnVuaWJvLml0MB4XDTEwMDcwODA5Mjg1NFoXDTExMDcwODA5Mjg1NFowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gaWRwdGVzdC51bmliby5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvN/up9rC27MVBJ2dA0L8bry+L4B9s23Aoh5ov
> >HEEl0x972Axhxz9JSc6muLXtNyezegcYfmMVLUXOU/pNoBHRtRns89B0o/sJ1OeKdQmUdJuSbzD2hzsxQiIJCyOPbRfRvmBA0TouvNPyOoAmIBh
> >rfG1vACXncgdOKE1sVZY5nmS9plJMrINjmVwvNS2yo5XKCSjw1GlbW4Iw+Jr1YNM7yxNEvk0jKYYAazoQYBO/bD3LGdKplSp02if00uDDNCRug
> >sF/4rJL5FzIeKkvR07UYwSiV1yIOgTwsBbUEZ8JLBN0nc3VrLsQKwJGfiosWytO3jzGBU3silqiIW/C5nNECAwEAATANBgkqhkiG9w0BAQsFAAOCA
> >QEASJDuHiVITi64TJg0w3NMeZvzCdFcTfk/1KGhdjLeV0vI/B6pA1NLr7bqKZEGIDTwMMVvS2vuLsymnkNFu/kdUNZYLw5RpmiEvVYjC20lPI538xdt
> >s9hK6GQ4wQFD5MxyHKpsj028pXZFXlCfxsajmTtLCRBjHVQ1GBU78z3rxe2Md6jvbGOyKe9qfvWYyyO+n3Sn64SNmjRqauupcZd67WhHeHno51frZmF4
> >t65v3pC+yqz1jvAVXlE7rm29O3bG+nS0/atcZE08Q6FM0ZY...</ds:X509Certificate>
> ></ds:X509Data></KeyInfo></ds:Signature>
> 
> So  what can i do to test if canocalization is done correctly?
This is difficult to test, but I would be suprised if it wasn't 
correct. It has already verified the canonicalization of the entire 
Assertion-element (minus the ds:Signature-element, since that is 
removed before the canonicalization step), and it uses the same 
canonicalization-method as the SignedInfo element.
-- 
Olav Morken
Stefano Gargiulo
unread,
Jul 29, 2010, 9:59:16 AM7/29/10
to simple...@googlegroups.com, Olav Morken

    

    
    

      
Could you 
check which certificate is added as certData in the parsed metadata?

    

    


      Yes, if you help me another time telling me where i can put print
      to get this...ￜ 

      (really thanks Olav!)

      

      Anyway something now brings to me closer to thinking that problemￜ
      is in canocalization method:

      

      Casually i pointed the SP toￜ a signed-metadata.xml (i'm using xml
      federation metadata) 

      when before i was pointing to an unsigned metadata...

      

      Now i get errors just parsing the federation metadata!!!

      

    
    

        
<b>Warning</b>:ￜ
            DOMNode::C14N() [<a
            href='domnode.c14n'>domnode.c14n</a>]: Internal
            error : parsing namespace uri in
            <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

            on line <b>655</b><br /> 

      

    

      that's a canocalization related question!!! (malformed??)

      

      But no one other in the federation got this problem (Shibboleth
      SPs) and they all uses singed-metadata.xml

      

      so to debug this i put this print:

      

      vim
/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php

      


        
        

            ￜￜￜ private function canonicalizeData($node,
            $canonicalmethod, $arXPath=NULL, $prefixList=NULL) {

          
            ￜￜￜￜￜￜￜ $exclusive = FALSE;

          
            ￜￜￜￜￜￜￜ $withComments = FALSE;

          
            ￜￜￜￜￜￜￜ .....omississ....

          
            ￜￜￜￜￜￜￜￜￜￜￜ }

          
            ￜￜￜￜￜￜￜￜￜￜￜ return C14NGeneral($node, $exclusive,
            $withComments);

          
            ￜￜￜￜￜￜￜ }

           ￜￜￜￜￜￜￜ $xmls =
              $node->ownerDocument->saveXML($node); //addedd for
              debug

          
              ￜￜￜￜￜￜￜ print($xmls); //addedd for debug

          
            ￜￜￜￜￜￜￜ return $node->C14N($exclusive, $withComments,
            $arXPath, $prefixList);

          
            ￜￜￜ }

      

    

      and from the discovery service page i get:

      

      ￜ
    

      


          ￜￜￜ <ds:SignedInfo> 

          <ds:CanonicalizationMethod
          Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/>
          

          <ds:SignatureMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 

          <ds:Reference URI=""> 

          <ds:Transforms> 

          <ds:Transform
          Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          

          </ds:Transforms> 

          <ds:DigestMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 

          <ds:DigestValue>fZC+oB3tgdQZbucHMRA2wTLlXik=</ds:DigestValue>
          

          </ds:Reference> 

          </ds:SignedInfo><br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : parsing namespace uri in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : checking for relative namespaces in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : processing childrens list in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : processing childrens list in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : processing childrens list in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : processing childrens list in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Warning</b>:ￜ DOMNode::C14N() [<a
          href='domnode.c14n'>domnode.c14n</a>]: Internal error
          : processing docs children list in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>655</b><br /> 

          <br /> 

          <b>Fatal error</b>:ￜ Call to a member function
          saveXML() on a non-object in
          <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>

          on line <b>653</b><br /> 

    

    

      after </ds:SignedInfo> (that's last node canocalizated
      without errors) there's :

      

          
    
<ds:SignatureValue>
            

        F9bTxiSDvUlWMffWSZ4Y6mEPFE65ZRtQnwrTXqrhKcdO1HCsIiVDzdNsOXs2BKpPl9DmLJz2Hloi

        R3IbhjjIX3dO4iEDfLuXLOfty7kLEjsxmOMDIAdHkc3BOt+r5i4Zf5K1Wnznx25u3561fPcOoMiw

        IK7Ty9/kyRpEWWS13hzAK++m9ufDOqS269sM1RYVMXzeEcIUmNpI4C1/7gprszYDfF40DYWl6naa

        Ys1VD4nW9OVfYzhr2sw+kChKjcsVMcuGUMiZYQLARALSejSOF0hZIhR4ozOOAds4nW2zYozzDTew

        r0SMp3BjWwA7Hg0W48+Z56wPRg5OgfyOsURs3g==

        </ds:SignatureValue>
            

      

    ￜ

      

    my signed-federation metadata starts with:

      

    
    

      
<EntitiesDescriptor
          xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          Name="urn:mace:garr.it:idem-test"
          validUntil="2020-01-01T00:00:00Z"
          xsi:schemaLocation="urn:oasis:names:tc:SAML:2.0:metadata
          sstc-saml-schema-metadata-2.0.xsd
          urn:mace:shibboleth:metadata:1.0 shibboleth-metadata-1.0.xsd
          http://www.w3.org/2001/04/xmlenc# xenc-schema.xsd
          http://www.w3.org/2000/09/xmldsig#
          xmldsig-core-schema.xsd"><ds:Signature
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo>
          <ds:CanonicalizationMethod
          Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"></ds:CanonicalizationMethod>
          <ds:SignatureMethod
          Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod>
          <ds:Reference URI=""> 

        

    

    ...

      

      

      Thanks,

      Stefano.
Olav Morken
unread,
Jul 30, 2010, 2:35:39 AM7/30/10
to simple...@googlegroups.com
On Thu, Jul 29, 2010 at 15:59:16 +0200, Stefano Gargiulo wrote:
> 
> >Could you
> >check which certificate is added as certData in the parsed metadata?
> 
> Yes, if you help me another time telling me where i can put print to
> get this...
The PEM-encoded certificate is available in lib/saml2/Message.php, in 
the checkSign function. Just dump $pemCert right before:
    $key->loadKey($pemCert);
> (really thanks Olav!)
You're welcome!
> Anyway something now brings to me closer to thinking that problem
> is in canocalization method:
> 
> Casually i pointed the SP to  a signed-metadata.xml (i'm using xml

> federation metadata)
> 
> when before i was pointing to an unsigned metadata...
> 
> Now i get errors just parsing the federation metadata!!!
> 
> >    <b>Warning</b>:  DOMNode::C14N() [<a

> >    href='domnode.c14n'>domnode.c14n</a>]: Internal error : parsing 
> >    namespace uri in
> >    <b>/var/www/idemauth/components/com_idemauth/simplesamlphp/lib/xmlseclibs.php</b>
> >    on line <b>655</b><br />
> 
> 
> that's a canocalization related question!!! (malformed??)
> 
> But no one other in the federation got this problem (Shibboleth SPs)
> and they all uses singed-metadata.xml
[...]
I took the liberty of downloading the test metadata, and doing a 
validation of it. I received the same error. I passed the metadata file 
to the xmllint command line tool, and it pointed to the source of the 
error:
    $ xmllint signed-test-metadata.xml >/dev/null
    signed-test-metadata.xml:2307: parser warning : xmlns:shibmd: 'urn:mace:shibboleth:metada ta:1.0' is not a valid URI
                    <shibmd:Scope xmlns:shibmd="urn:mace:shibboleth:metada ta:1.0" r
                                                                                  ^
The problem is the space-character in the namespace URI on line 2307. 
When I removed it, canonicalization worked.

Btw.: If you want to load the full federation metadata from XML, I 
suggest that you look at configuring the metarefresh-module:
    http://simplesamlphp.org/docs/1.6/simplesamlphp-automated_metadata
The parsing of metadata from XML format can be quite expensive, and 
there is no caching of the result.
Peter Schober
unread,
Jul 30, 2010, 4:12:09 AM7/30/10
to simple...@googlegroups.com
Jfyi:
* Olav Morken <olav....@uninett.no> [2010-07-30 08:36]:

> I took the liberty of downloading the test metadata, and doing a 
> validation of it. I received the same error. I passed the metadata file 
> to the xmllint command line tool, and it pointed to the source of the 
> error:
> 
>     $ xmllint signed-test-metadata.xml >/dev/null
>     signed-test-metadata.xml:2307: parser warning : xmlns:shibmd: 'urn:mace:shibboleth:metada ta:1.0' is not a valid URI
>                     <shibmd:Scope xmlns:shibmd="urn:mace:shibboleth:metada ta:1.0" r
>                                                                                   ^
> The problem is the space-character in the namespace URI on line 2307. 
> When I removed it, canonicalization worked.
I've added a buch of tools for SAML 2.0 metadata checking to the Shib
wiki (well-formedness, schema validity, XMLsig signature validation):
https://spaces.internet2.edu/display/SHIB2/MetadataCorrectness#MetadataCorrectness-ApproachesandTools
Also includes hints on installation on GNU/Linux systems, example
command line usage, etc.
-peter
Stefano Gargiulo
unread,
Aug 3, 2010, 12:11:00 PM8/3/10
to simple...@googlegroups.com, Olav Morken


  
    
  
  

    Hi Olav, 

      I did the test you suggested and final conclusion is that:

      the problem is the use of different singing and encryption keys by
      the IdP as you hypothesized.

      

      The file_put_contents('/tmp/pemCert.dump',
        print_r($pemCert,true)); relevated, that the certificate
      loaded into the

      key before singature validation was the one with use="encryption"
      instead of the one with use="singing" in xml IdP metadata.

      

      So i tried to dump the message issuer metadata array in
      Message.php to see if the use="signing" one is available
      somewhare but no luck:

      
file_put_contents("/tmp/srcmd.dump",print_r($srcMetadata->toArray(),true));

          Array

          (

          ￜￜￜ [entityid] =>
          http://idptest.unibo.it/adfs/services/trust

          ￜￜￜ [entityDescriptor] =>
PD94bWwgdmVyc2lvbj0iMS4wIj8+CjxFbnRpdHlEZXNjcmlwdG9yIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6bWV0YWRhdGEiIHhtbG5zOnNoaWJtZD0idXJuOm1hY2U6c2hpYmJvbGV0aDptZXRhZGF0YToxLjAiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIiBJRD0iXzViYWVlY2JmLTUzMDItNDhmYS05ZmVkLWZhNjMwN2U2MjA5YyIgZW50aXR5SUQ9Imh0dHA6Ly9pZHB0ZXN0LnVuaWJvLml0L2FkZnMvc2VydmljZXMvdHJ1c3QiPgoKICAgICAgPElEUFNTT0Rlc2NyaXB0b3IgcHJvdG9jb2xTdXBwb3J0RW51bWVyYXRpb249InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCI+CiAgICAgICAgIDxFeHRlbnNpb25zPgogICAgICAgICAgICAgICAgPHNoaWJtZDpTY29wZSB4bWxuczpzaGlibWQ9InVybjptYWNlOnNoaWJib2xldGg6bWV0YWRhdGE6MS4wIiByZWdleHA9ImZhbHNlIj51bmliby5pdDwvc2hpYm1kOlNjb3BlPgogICAgICAgICA8L0V4dGVuc2lvbnM+CiAgICAgICAgICAgIDxLZXlEZXNjcmlwdG9yIHVzZT0iZW5jcnlwdGlvbiI+CiAgICAgICAgICAgICAgICAgIDxkczpLZXlJbmZvIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj4KICAgICAgICAgICAgICAgICAgICAgICAgPGRzOlg1MDlEYXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZHM6WDUwOUNlcnRpZmljYXRlP
k1JSUM0akNDQWNxZ0F3SUJBZ0lRZXE4WGlGV1czS05KNDR5ZGY5UlE3ekFOQmdrcWhraUc5dzBCQVFzRkFEQXRNU3N3S1FZRFZRUURFeUpCUkVaVElFVnVZM0o1Y0hScGIyNGdMU0JwWkhCMFpYTjBMblZ1YVdKdkxtbDBNQjRYRFRFd01EY3dPREE1TWpnMU5WbwpYRFRFeE1EY3dPREE1TWpnMU5Wb3dMVEVyTUNrR0ExVUVBeE1pUVVSR1V5QkZibU55ZVhCMGFXOXVJQzBnYVdSd2RHVnpkQzUxYm1saWJ5NXBkRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFLeHlLaldEdFkyL0NiM2M5ckJnd2pobzVEQzJ2dk4vRUk3VnZQTkVCV1hoMkNoZnY1ZmY5SHkwRkF4UUZaM1FJT2xSUHVhMQpjT3VKNTIyL3NuYXREWUFSZk1teS9TTThzaTlieE8rSkxqdVR6VnV5ZitkZEdhajV6K2tqcmlhdVkySXBMUmJmakx4bzNpTVBEVVVyWFV2QVVDWUFzN3JURkdJUUh0K1dPVTd2RG41ZW1EcFBnNTV4SWNnUlhQL1BaUXo3bXhid1VIQ2xRMUphbUlleC9ROEE0eHV2VUdIcmM5L2xlZTA4M2VpNHh6dHlUOUFSZmZzMWJ5b3ZrRTVkQTNJN0NrWThDbSszNwpoclVUYTZ0RXdxZnBycStQMW1ZbklUT3dvdWh1emdFRFJzV21NUHNHUW1PZ2RrczFKTTBtT3FQKzBsSE9wY25TNGR3Wnh4aXFqRUNBd0VBQVRBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQWdGNkJBM3psdmdvMWFiZ1VsaW10K1k5Z2pRYURWUC9HWjdQb294TFNPYUJhZW05dXB6OEsxYU8zai9qKzliNkd6WDJzZkhjaTZ0a0I4bGpyWitKT2t6NzN3Ygo
2c2MrN2pFMkhOS2pFbmtFSEVlVGdrVmZQMnJlVE1QcGVLU25ldENJSi9raHExczgxMXh5bCszK2dvRkFpTlo4Qk13SFNqc2VTcHNsbDY5QmlONE9WYTc1WC9RVFU3ZXRBRm1zaldOZTQ2OFEvS1JmeTFDVjFxYkRBNEQyVmUveTUvNHFkOFB1WmhTeUtlVHlDdDQ0RktZLzJDNTRoaGtXWkFYY1RobUJzVEpxU1k3MDNzS0QrNTQ0TGs2VHhxamVKNnduYQp0T1MzMUcrVnY1S1Y1YWFRNDhsSEJlMFVUbk9qeTlIN2M0NlkvY01pK1FobEJKcnA4MmtrYmRRPT08L2RzOlg1MDlDZXJ0aWZpY2F0ZT4KICAgICAgICAgICAgICAgICAgICAgICAgPC9kczpYNTA5RGF0YT4KICAgICAgICAgICAgICAgICAgPC9kczpLZXlJbmZvPgogICAgICAgICAgICA8L0tleURlc2NyaXB0b3I+CiAgICAgICAgICAgIDxLZXlEZXNjcmlwdG9yIHVzZT0ic2lnbmluZyI+CiAgICAgICAgICAgICAgICAgIDxkczpLZXlJbmZvIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj4KICAgICAgICAgICAgICAgICAgICAgICAgPGRzOlg1MDlEYXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZHM6WDUwOUNlcnRpZmljYXRlPk1JSUMzRENDQWNTZ0F3SUJBZ0lRYVhCL1o4cU1qWWRPSXVDZk54K2RvVEFOQmdrcWhraUc5dzBCQVFzRkFEQXFNU2d3SmdZRFZRUURFeDlCUkVaVElGTnBaMjVwYm1jZ0xTQnBaSEIwWlhOMExuVnVhV0p2TG1sME1CNFhEVEV3TURjd09EQTVNamcxTkZvWERURQp4TURjd09EQTVNa
mcxTkZvd0tqRW9NQ1lHQTFVRUF4TWZRVVJHVXlCVGFXZHVhVzVuSUMwZ2FXUndkR1Z6ZEM1MWJtbGlieTVwZERDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSnZOL3VwOXJDMjdNVkJKMmRBMEw4YnJ5K0w0QjlzMjNBb2g1b3ZIRUVsMHg5NzJBeGh4ejlKU2M2bXVMWHROeWV6ZWdjWWZtTVZMVVhPVQovcE5vQkhSdFJuczg5QjBvL3NKMU9lS2RRbVVkSnVTYnpEMmh6c3hRaUlKQ3lPUGJSZlJ2bUJBMFRvdXZOUHlPb0FtSUJocmZHMXZBQ1huY2dkT0tFMXNWWlk1bm1TOXBsSk1ySU5qbVZ3dk5TMnlvNVhLQ1NqdzFHbGJXNEl3K0pyMVlOTTd5eE5FdmswaktZWUFhem9RWUJPL2JEM0xHZEtwbFNwMDJpZjAwdURETkNSdWdzRi80ckpMNUZ6SWVLa3ZSMAo3VVl3U2lWMXlJT2dUd3NCYlVFWjhKTEJOMG5jM1ZyTHNRS3dKR2Zpb3NXeXRPM2p6R0JVM3NpbHFpSVcvQzVuTkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFTSkR1SGlWSVRpNjRUSmcwdzNOTWVadnpDZEZjVGZrLzFLR2hkakxlVjB2SS9CNnBBMU5McjdicUtaRUdJRFR3TU1WdlMydnVMc3ltbmtORnUva2RVTlpZTHc1UnBtaUV2VgpZakMyMGxQSTUzOHhkdHM5aEs2R1E0d1FGRDVNeHlIS3BzajAyOHBYWkZYbENmeHNham1UdExDUkJqSFZRMUdCVTc4ejNyeGUyTWQ2anZiR095S2U5cWZ2V1l5eU8rbjNTbjY0U05talJxYXV1cGNaZDY3V2hIZUhubzUxZnJabUY0dDY1djNwQyt5cXoxanZBVlhsRTdybTI5TzNiRyt
uUzAvYXRjWkUwOFE2Rk0wWlkrRjFuZkVETmQyWDFJV0xmMnVuYwpKU3Z2d0REdFpSZmRXUDVjRUR6RmxrUnVYZ2I4N1liakpFSWxoMmdPcnI1VFNpZz09PC9kczpYNTA5Q2VydGlmaWNhdGU+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvZHM6WDUwOURhdGE+CiAgICAgICAgICAgICAgICAgIDwvZHM6S2V5SW5mbz4KICAgICAgICAgICAgPC9LZXlEZXNjcmlwdG9yPgogICAgICAgICAgICA8U2luZ2xlTG9nb3V0U2VydmljZSBCaW5kaW5nPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1SZWRpcmVjdCIgTG9jYXRpb249Imh0dHBzOi8vaWRwdGVzdC51bmliby5pdC9hZGZzL2xzLyIvPgogICAgICAgICAgICA8U2luZ2xlTG9nb3V0U2VydmljZSBCaW5kaW5nPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1QT1NUIiBMb2NhdGlvbj0iaHR0cHM6Ly9pZHB0ZXN0LnVuaWJvLml0L2FkZnMvbHMvIi8+CiAgICAgICAgICAgIDxOYW1lSURGb3JtYXQ+dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6ZW1haWxBZGRyZXNzPC9OYW1lSURGb3JtYXQ+CiAgICAgICAgICAgIDxOYW1lSURGb3JtYXQ+dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm5hbWVpZC1mb3JtYXQ6cGVyc2lzdGVudDwvTmFtZUlERm9ybWF0PgogICAgICAgICAgICA8TmFtZUlERm9ybWF0PnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9yb
WF0OnRyYW5zaWVudDwvTmFtZUlERm9ybWF0PgogICAgICAgICAgICA8U2luZ2xlU2lnbk9uU2VydmljZSBCaW5kaW5nPSJ1cm46bWFjZTpzaGliYm9sZXRoOjEuMDpwcm9maWxlczpBdXRoblJlcXVlc3QiIExvY2F0aW9uPSJodHRwczovL2lkcHRlc3QudW5pYm8uaXQvYWRmcy9scy8iLz4KICAgICAgICAgICAgPFNpbmdsZVNpZ25PblNlcnZpY2UgQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUmVkaXJlY3QiIExvY2F0aW9uPSJodHRwczovL2lkcHRlc3QudW5pYm8uaXQvYWRmcy9scy8iLz4KICAgICAgICAgICAgPFNpbmdsZVNpZ25PblNlcnZpY2UgQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgTG9jYXRpb249Imh0dHBzOi8vaWRwdGVzdC51bmliby5pdC9hZGZzL2xzLyIvPgogICAgICA8L0lEUFNTT0Rlc2NyaXB0b3I+CiAgICAgIDxPcmdhbml6YXRpb24+CiAgICAgICAgICAgIDxPcmdhbml6YXRpb25OYW1lIHhtbDpsYW5nPSJpdC1JVCI+VW5pdmVyc2l0YScgZGVnbGkgU3R1ZGkgZGkgQm9sb2duYWkgLSBpZHAgZGkgdGVzdDwvT3JnYW5pemF0aW9uTmFtZT4KICAgICAgICAgICAgPE9yZ2FuaXphdGlvbkRpc3BsYXlOYW1lIHhtbDpsYW5nPSJpdC1JVCI+VW5pdmVyc2l0YScgZGVnbGkgU3R1ZGkgZGkgQm9sb2duYSAtIElkUCBkaSB0ZXN0PC9Pcmdhbml6YXRpb25EaXNwbGF5TmFtZT4KICAgICAgICA
gICAgPE9yZ2FuaXphdGlvblVSTCB4bWw6bGFuZz0iaXQtSVQiPmh0dHA6Ly93d3cudW5pYm8uaXQvPC9Pcmdhbml6YXRpb25VUkw+CiAgICAgIDwvT3JnYW5pemF0aW9uPgogICAgICA8Q29udGFjdFBlcnNvbiBjb250YWN0VHlwZT0ic3VwcG9ydCI+CiAgICAgICAgICAgIDxHaXZlbk5hbWU+QWxkbzwvR2l2ZW5OYW1lPgogICAgICAgICAgICA8U3VyTmFtZT5TY2hpYXZpbmE8L1N1ck5hbWU+CiAgICAgICAgICAgIDxFbWFpbEFkZHJlc3M+YWxkby5zY2hpYXZpbmFAdW5pYm8uaXQ8L0VtYWlsQWRkcmVzcz4KICAgICAgICAgICAgPFRlbGVwaG9uZU51bWJlcj4rMzkwNTExMjM0NTY3ODk8L1RlbGVwaG9uZU51bWJlcj4KICAgICAgPC9Db250YWN0UGVyc29uPgo8L0VudGl0eURlc2NyaXB0b3I+Cg==

          ￜￜￜ [name] => Array

          ￜￜￜￜￜￜￜ (

          ￜￜￜￜￜￜￜￜￜￜￜ [it-IT] => Universita' degli Studi di Bologna -
          IdP di test

          ￜￜￜￜￜￜￜ )

          

          ￜￜￜ [description] => Array

          ￜￜￜￜￜￜￜ (

          ￜￜￜￜￜￜￜￜￜￜￜ [it-IT] => Universita' degli Studi di Bolognai
          - idp di test

          ￜￜￜￜￜￜￜ )

          

          ￜￜￜ [url] => Array

          ￜￜￜￜￜￜￜ (

          ￜￜￜￜￜￜￜￜￜￜￜ [it-IT] => http://www.unibo.it/

          ￜￜￜￜￜￜￜ )

          

          ￜￜￜ [expire] => 1577836800

          ￜￜￜ [scopes] => Array

          ￜￜￜￜￜￜￜ (

          ￜￜￜￜￜￜￜￜￜￜￜ [0] => unibo.it

          ￜￜￜￜￜￜￜ )

          

          ￜￜￜ [SingleSignOnService] =>
          https://idptest.unibo.it/adfs/ls/

          ￜￜￜ [SingleLogoutService] =>
          https://idptest.unibo.it/adfs/ls/

          ￜￜￜ [certFingerprint] => Array

          ￜￜￜￜￜￜￜ (

          ￜￜￜￜￜￜￜￜￜￜￜ [0] => c97ac8892b95a35cb8713abc8eaf0e2bd3138b51

          ￜￜￜￜￜￜￜ )

          

          ￜￜￜ [certData] =>
MIIC4jCCAcqgAwIBAgIQeq8XiFWW3KNJ44ydf9RQ7zANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJBREZTIEVuY3J5cHRpb24gLSBpZHB0ZXN0LnVuaWJvLml0MB4XDTEwMDcwODA5Mjg1NVoXDTExMDcwODA5Mjg1NVowLTErMCkGA1UEAxMiQURGUyBFbmNyeXB0aW9uIC0gaWRwdGVzdC51bmliby5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxyKjWDtY2/Cb3c9rBgwjho5DC2vvN/EI7VvPNEBWXh2Chfv5ff9Hy0FAxQFZ3QIOlRPua1cOuJ522/snatDYARfMmy/SM8si9bxO+JLjuTzVuyf+ddGaj5z+kjriauY2IpLRbfjLxo3iMPDUUrXUvAUCYAs7rTFGIQHt+WOU7vDn5emDpPg55xIcgRXP/PZQz7mxbwUHClQ1JamIex/Q8A4xuvUGHrc9/lee083ei4xztyT9ARffs1byovkE5dA3I7CkY8Cm+37hrUTa6tEwqfprq+P1mYnITOwouhuzgEDRsWmMPsGQmOgdks1JM0mOqP+0lHOpcnS4dwZxxiqjECAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAgF6BA3zlvgo1abgUlimt+Y9gjQaDVP/GZ7PooxLSOaBaem9upz8K1aO3j/j+9b6GzX2sfHci6tkB8ljrZ+JOkz73wb6sc+7jE2HNKjEnkEHEeTgkVfP2reTMPpeKSnetCIJ/khq1s811xyl+3+goFAiNZ8BMwHSjseSpsll69BiN4OVa75X/QTU7etAFmsjWNe468Q/KRfy1CV1qbDA4D2Ve/y5/4qd8PuZhSyKeTyCt44FKY/2C54hhkWZAXcThmBsTJqSY703sKD+544Lk6TxqjeJ6wnatOS31G+Vv5KV5aaQ48lHBe0UTnOjy9H7c46Y/cMi+QhlBJrp82kkbd
Q==

          ￜￜￜ [metadata-index] =>
          http://idptest.unibo.it/adfs/services/trust

          ￜￜￜ [metadata-set] => saml20-idp-remote

          )

      

      

      So just one certificate is stored into php array. 

      

      Is the feauture to support 2 different certs planned to be
      implemented? 

      

      If i wanna try to write a temporary patch (feeling a lot
      adventourose :) ), where's the file that parses xml metadata to
      generate the php array?

      

      Is it different if i use the metarefresh module as you suggested?ￜ
     (read: the metadata parser used by metarefresh module is
      the same that's used live?)


    

    

      
  signed-test-metadata.xml:2307: parser warning : xmlns:shibmd: 'urn:mace:shibboleth:metada ta:1.0' is not a valid URI
                    <shibmd:Scope xmlns:shibmd="urn:mace:shibboleth:metada ta:1.0" r
                                                                                  ^
The problem is the space-character in the namespace URI on line 2307. 
When I removed it, canonicalization worked.

    

    

    
Thank you i reported this to the federation manager.


    

    

      
Btw.: If you want to load the full federation metadata from XML, I 
suggest that you look at configuring the metarefresh-module:

    http://simplesamlphp.org/docs/1.6/simplesamlphp-automated_metadata

The parsing of metadata from XML format can be quite expensive, and 
there is no caching of the result.


    

    

    
yes i had some problem using live xml parsing with large
      federations, 

      so thank you for this suggestion!

    

    

      Best regards,

      Stefano.
Olav Morken
unread,
Aug 4, 2010, 1:58:55 AM8/4/10
to simple...@googlegroups.com
On Tue, Aug 03, 2010 at 18:11:00 +0200, Stefano Gargiulo wrote:
>  Hi Olav,
> I did the test you suggested and final conclusion is that:
> the problem is the use of different singing and encryption keys by
> the IdP as you hypothesized.
> 
> The /file_put_contents('/tmp/pemCert.dump',
> print_r($pemCert,true));/ relevated, that the certificate loaded

> into the
> key before singature validation was the one with use="encryption"
> instead of the one with use="singing" in xml IdP metadata.
> 
> So i tried to dump the message issuer metadata array in Message.php
> to see if the /use="signing"/ one is available somewhare but no
> luck:
[...]

> 
> 
> So just one certificate is stored into php array.
> 
> Is the feauture to support 2 different certs planned to be implemented?
It is something that we want to support, but we don't have a timeframe 
for when it will be supported. (Actually we want to support an 
unlimited number of certificates, as that can be used for key rollover 
and storing ssl/tls certificate in metadata (for SOAP).)
> If i wanna try to write a temporary patch (feeling a lot
> adventourose :) ), where's the file that parses xml metadata to
> generate the php array?
I saved you the trouble, and fixed the immediate problem (i.e. that we 
chose the wrong certificate when faced with two certificates where one 
supports supports signing while the other does not). The change is in 
r2474: http://code.google.com/p/simplesamlphp/source/detail?r=2474
> Is it different if i use the metarefresh module as you suggested?
> (read: the metadata parser used by metarefresh module is the same
> that's used live?)
The metarefresh module uses the same classes for parsing and processing 
metadata.

Regards,
Stefano Gargiulo
unread,
Aug 4, 2010, 1:36:19 PM8/4/10
to simple...@googlegroups.com, Olav Morken

    

      
I saved you the trouble, and fixed the immediate problem (i.e. that we 
chose the wrong certificate when faced with two certificates where one 
supports supports signing while the other does not). The change is in 
r2474: http://code.google.com/p/simplesamlphp/source/detail?r=2474


    

    
Awesome, thank you again.

      

      Ps. i will test it in next days (now i'm a little busy with other)

      

      But just one question:

      

      I'm not so expert in SAML and XMLEnc, so i can be wrong, but
      looking at the changeset it seems (to me) that now the parser is
      looking for the use="signing" certificate, and is enforcing the
      selection of it for keeping into the php array, while the
      encryption one is just skipped. 

      I'm not sure if this can be an issue for decryption when you need
      to access the metadata's public "encryption" key (i think one case
      can be when IdP uses EncryptedKey in assertions), or i'm wrong and
      the metadata issuer public key is never needed for SAML assertion
      decryption? ￜ 

      

      Another (more generic) question:

      

      It's a question that i ever asked to myself:ￜ what kind encryption
      can do some enitities that shares just public keys (metadata)? 

    is the reply in the following text (bring from
      XMLEnc specs)?

      

      If yes, if as i understand it's based on a secret derivated from 2
      public keys, is it really secure to publish the whole federation
      metadata on the web when there are some non HTTPS endpoints and
      privacy is granted just by SAML AssertionEncryption?

      
          

                
5.5ï¿œKey Agreement

                
A Key Agreement algorithm provides for the derivation
                  of a shared secret key based on a shared secret
                  computed from certain types of compatible public keys
                  from both the sender and the recipient. Information
                  from the originator to determine the secret is
                  indicated by an optionalï¿œOriginatorKeyInfoï¿œparameter
                  child of anï¿œAgreementMethodelement
                  while that associated with the recipient is indicated
                  by an optionalï¿œRecipientKeyInfo.
                  A shared key is derived from this shared secret by a
                  method determined by the Key Agreement algorithm.

                
Note: XML Encryption does not provide an on-line key
                  agreement negotiation protocol. Theï¿œAgreementMethodï¿œelement can be
                  used by the originator to identify the keys and
                  computational procedure that were used to obtain a
                  shared encryption key. The method used to obtain or
                  select the keys or algorithm used for the agreement
                  computation is beyond the scope of this specification.

                
Theï¿œAgreementMethodï¿œelement
                  appears as the content of aï¿œds:KeyInfoï¿œsince, like
                  otherï¿œds:KeyInfoï¿œchildren, it
                  yields a key. Thisï¿œds:KeyInfoï¿œis in turn a
                  child of anEncryptedDataï¿œorï¿œEncryptedKeyï¿œelement. Theï¿œAlgorithmï¿œattribute andï¿œKeySizeï¿œchild of theï¿œEncryptionMethodï¿œelement under
                  thisï¿œEncryptedDataï¿œorï¿œEncryptedKeyï¿œelement are
                  implicit parameters to the key agreement computation.
                  In cases where thisï¿œEncryptionMethodï¿œalgorithm URI
                  is insufficient to determine the key length, aï¿œKeySizeï¿œMUST have been
                  included. In addition, the sender may place aï¿œKA-Nonceï¿œelement underï¿œAgreementMethodï¿œto assure that
                  different keying material is generated even for
                  repeated agreements using the same sender and
                  recipient public keys. For example:

                
 <EncryptedData>
   <EncryptionMethod Algorithm="Example:Block/Alg"
     <KeySize>80</KeySize>
   </EncryptionMethod>
   <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <AgreementMethod Algorithm="example:Agreement/Algorithm">
       <KA-Nonce>Zm9v</KA-Nonce>
       <ds:DigestMethod
       Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>
      <OriginatorKeyInfo>
         <ds:KeyValue>....</ds:KeyValue>
       </OriginatorKeyInfo>
       <RecipientKeyInfo>
         <ds:KeyValue>....</ds:KeyValue>
       </RecipientKeyInfo> 
     </AgreementMethod>
   </ds:KeyInfo>
   <CipherData>...</CipherData>
</EncryptedData>

                
If the agreed key is being used to wrap a key, rather
                  than data as above, thenï¿œAgreementMethodï¿œwould appear
                  inside aï¿œds:KeyInfoï¿œinside anï¿œEncryptedKeyï¿œelement.

                
The Schema forï¿œAgreementMethodï¿œis as follows:

                
  Schema Definition:

  <element name="AgreementMethod" type="xenc:AgreementMethodType"/>
  <complexType name="AgreementMethodType" mixed="true">
    <sequence>
      <element name="KA-Nonce" minOccurs="0" type="base64Binary"/>
      <!-- <element ref="ds:DigestMethod" minOccurs="0"/> -->
      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      <element name="OriginatorKeyInfo" minOccurs="0" 
               type="ds:KeyInfoType"/>
      <element name="RecipientKeyInfo" minOccurs="0" 
               type="ds:KeyInfoType"/>
    </sequence>
    <attribute name="Algorithm" type="anyURI" use="required"/>
  </complexType>

              

        

      

      Best regards,

      Stefano.
Peter Schober
unread,
Aug 4, 2010, 2:58:42 PM8/4/10
to simple...@googlegroups.com
* Stefano Gargiulo <rast...@gmail.com> [2010-08-04 19:48]:
> Another (more generic) question:
> 
> It's a question that i ever asked to myself:  what kind encryption

> can do some enitities that shares just public keys (metadata)?
> is the reply in the following text (bring from XMLEnc specs)?
> 
> If yes, if as i understand it's based on a secret derivated from 2
> public keys, is it really secure to publish the whole federation
> metadata on the web when there are some non HTTPS endpoints and
> privacy is granted just by SAML AssertionEncryption?
I probably don't understand the question, but does this help?
http://en.wikipedia.org/wiki/Public-key_cryptography
-peter
Stefano Gargiulo
unread,
Aug 4, 2010, 3:20:46 PM8/4/10
to simple...@googlegroups.com
Thanks now i get it. So no problems having metadata public, Sorry for my stupid question.


But, then, my first question is more valid: i need the Idp encryption public key To compute the shared secret and then decrypt an IdP assertion (and i need it in metadata when the key is not directly sent in the message, such as the encryptedkey case, that's my adfs case) . So the patch will not work in this case or i'm wrong?



Thank you,

Stefano.


Il giorno 04/ago/2010 20:58, "Peter Schober" <sp+lists....@univie.ac.at> ha scritto:

* Stefano Gargiulo <rast...@gmail.com> [2010-08-04 19:48]:



> Another (more generic) question:
> 
> It's a question that i ever asked to myself:  what kind encr...
I probably don't understand the question, but does this help?


http://en.wikipedia.org/wiki/Public-key_cryptography


-peter

-- 
You received this message because you are subscribed to the Google Groups "simpleSAMLphp...


Olav Morken
unread,
Aug 5, 2010, 2:25:27 AM8/5/10
to simple...@googlegroups.com
On Wed, Aug 04, 2010 at 19:36:19 +0200, Stefano Gargiulo wrote:
> 
> >I saved you the trouble, and fixed the immediate problem (i.e. that we
> >chose the wrong certificate when faced with two certificates where one
> >supports supports signing while the other does not). The change is in
> >r2474: http://code.google.com/p/simplesamlphp/source/detail?r=2474
> Awesome, thank you again.
> 
> Ps. i will test it in next days (now i'm a little busy with other)
> 
> But just one question:
> 
> I'm not so expert in SAML and XMLEnc, so i can be wrong, but looking
> at the changeset it seems (to me) that now the parser is looking for
> the use="signing" certificate, and is enforcing the selection of it
> for keeping into the php array, while the encryption one is just
> skipped.
> I'm not sure if this can be an issue for decryption when you need to
> access the metadata's public "encryption" key (i think one case can
> be when IdP uses EncryptedKey in assertions), or i'm wrong and the
> metadata issuer public key is never needed for SAML assertion
> decryption?
The encryption key is fetched from the recipients metadata by the 
sender of the message. This means if the IdP wants to send an encrypted 
message to the SP, it needs to look up the encryption key from the SP's 
metadata. If I recall correctly, you are using simpleSAMLphp as an SP, 
which means that you never need to access the encryption keys of the 
IdP, since you never send encrypted messages to the IdP.
But yes, the solution I added is far from perfect. It simply makes the 
default behaviour more sane. An SP is always interrested in the signing 
key of the IdP, since it is needed to verify the assertions received 
from the IdP.
When running simpleSAMLphp as an IdP on the other hand, this change may 
break configurations that used to work. If the IdP was configured to 
encrypt assertions, but not to verify signatures, it may have relied on 
the encryption key being loaded instead.
We want to add proper support for multiple keys in the metadata, but I 
do not know when we will do that.
Reply all
Reply to author
Forward
0 new messages