authn request signing

[Mike Flynn]

I asked the client to test after I made the sign="true" setting but he says he is still not getting a signed authNRequest:

I still do not see the signature in the AuthNRequest:
 
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://shib.lynda.com/Shibboleth.sso/SAML2/POST" Destination="https://alliancetest.qualcomm.com/fed/idp/samlv20" ID="_25673b8d16e076e3dc1caf2815a02a3a" IssueInstant="2011-11-03T20:02:51Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://shib.lynda.com/shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>

Any thoughts?



________________________________
From: Mark K. Miller <max at psu.edu>
To: Shib Users <users at shibboleth.net>
Sent: Thursday, November 3, 2011 12:37 PM
Subject: Re: authn request signing


Mike and I just finished testing again; it works now.  Scott was 
absolutely correct about the metadata.

Thanks for your help, Scott!

On Thu, 3 Nov 2011, Mark K. Miller wrote:

> On Thu, 3 Nov 2011, Cantor, Scott wrote:
>
>> On 11/3/11 11:26 AM, "Mike Flynn" <shibbolethlynda at yahoo.com> wrote:
>>>
>>> And then
>>> did a test with Max at PSU.  It failed.
>>
>> If it failed, then I would imagine your metadata must be wrong. The only
>> reason it should fail is if your signature wasn't trusted.
>
> I imagine that you imagine correctly (as always.)
>
> I feel real silly that I didn't realize this.  Especially, given that upon
> declaring the test a failure I went right off and updated my metadata
> because Mike was up to the steps in the key rollover process where he had
> added another cert to the metadata.
>
> In a separate note directly to Mike, I suggested we repeat the test and I
> expect it'll work now.
>
> Thanks, Scott!
>
>>> Do I need to include the encryption setting and have it set to true along
>>> with signing="true"?
>>
>> There is nothing in the request that's encrypted, the setting won't matter.
>>
>>> If these values are not present in the ApplicationDefaults, I presume
>>> that Shibboleth defaults them both to false - correct?
>>
>> Yes; you can find that out in the documentation. I documented every
>> setting.
>>
>>> Is this customer wrong when they indicate that authn request signing will
>>> have no impact on existing Idps?  I assume they are since PSU's shib
>>> connection attempt failed.  Or, would setting both encryption and signing
>>> on applicationdefaults have prevented the error?
>>
>> No, and any time the metadata is wrong, virtually anything can fail.
>>
>> You can also override the setting for the specific relying party, as
>> documented.
>>
>> -- Scott
>>
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111103/cd7b55ad/attachment-0001.html