Simulating Invalid Request From RP

[Zmuda, Matthew R]

What do I do / Where do I corrupt the signature?
This a code change needed or metadata change?

Thanks,

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Chad La Joie
Sent: Thursday, December 01, 2011 8:32 AM
To: Shib Users
Subject: Re: Simulating Invalid Request From RP

Depends on which rule you want to break.  If you want to break the
'ProtocolWithXMLSignature' rule then generate a request with an XML
signature, corrupt the signature, and send it.  For
'SAML2HTTPRedirectSimpleSign' generate a signature over a redirect
request, corrupt the signature, and send it.  etc.

On Thu, Dec 1, 2011 at 08:26, Zmuda, Matthew R <Matthew.R.Zmuda at td.com> wrote:
>
> What on RP side would I need to change to test the breaking of these rules?
> I have tried changing certs in RP and IDP metadata files in the RP application but the IDP still accepts the request.
>
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Chad La Joie
> Sent: Thursday, December 01, 2011 8:24 AM
> To: Shib Users
> Subject: Re: Simulating Invalid Request From RP
>
> Yes, those rules are the ones that deal with incoming requests and
> whether they are signed or not.
>
> On Thu, Dec 1, 2011 at 07:40, Zmuda, Matthew R <Matthew.R.Zmuda at td.com> wrote:
>> I have both an RP and IDP running locally. I'd like to test the scenario
>> where the request from RP is not signed appropriately (or has been tampered
>> with on the way over).
>>
>> What specifically in the IDP would cause it to reject a RP request that say
>> has not been signed as expected? I have tried modifying the certificates in
>> rp and idp metadata on RP side and have not been able to cause the IDP to
>> reject a AuthNRequest.
>>
>>
>>
>> My IDP does have the following defined in the SecurityPolicy:
>>
>>
>>
>>         <security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"/>
>>
>>         <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature"
>> trustEngineRef="shibboleth.SignatureTrustEngine"/>
>>
>>         <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign"
>> trustEngineRef="shibboleth.SignatureTrustEngine"/>
>>
>>         <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign"
>> trustEngineRef="shibboleth.SignatureTrustEngine"/>
>>
>>
>>
>> Thanks
>>
>> NOTICE: Confidential message which may be privileged. Unauthorized
>> use/disclosure prohibited. If received in error, please go to
>> www.td.com/legal for instructions.
>> AVIS : Message confidentiel dont le contenu peut être privilégié.
>> Utilisation/divulgation interdites sans permission. Si reçu par erreur,
>> prière d'aller au www.td.com/francais/avis_juridique pour des instructions.
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
> NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions.
> AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au www.td.com/francais/avis_juridique pour des instructions.
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net