Shibboleth IDP Connected to OIOSAML.net dk.nita.saml20 Service Provider

[Andrew A. DeVries]

Thanks for clarifying how the encryption works so it sounds like anyone with my Metadata which can be downloaded with the right URL can fake being my the IDP.  This is a major issue so I will spend some time this weekend figuring out how to get OIOSAML.net to validate the signature.  Am I correct in that the public key used to validate the signature is included in the returned assertion?  Is it mandatory by spec that it is returned?  After thinking about it if the AuthNRequest is Signed the same way as the Assertion then I should be able to easily add that functionality using the .net XML crypto library calls.

I will do some work on it this weekend and see what I come up with.  I know the AssertionValidation check works with Ping Federation as I have another vendor using that so at least I have a working example to play with.

Thanks again for all of the help.

Andy

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Friday, August 01, 2014 6:32 PM
To: users at shibboleth.net
Subject: Re: Shibboleth IDP Connected to OIOSAML.net dk.nita.saml20 Service Provider

* Andrew A. DeVries <adevries at digitalexample.com> [2014-08-01 23:54]:
> Issue 1 is hard coded to true in the code and there are no methods in 
> the code to allow the AuthNRequest to be Signed, so as far as I can 
> tell this is the only option without lengthy code changes.

OK

> Issue 2.  The source code is specifically looking at the metadata and 
> only the metadata for a <q1:KeyDescriptor use="signing">, Shibboleth 
> does not return the use="signing: so no key is found so it fails to 
> verify the signature.

OK. Note future releases may default to seperate keys for encryption and signing and so would need to make use of the 'use' limitation in metdata.

> I see the Assertion has two keys and with my provider they match the 
> metadata but manualy adding use="signing" caused it to find the key 
> but still failed signature verification as the Microsoft .Net 
> System.Security.Cryptography.Xml CheckSignature().  This is a MS.Net 
> call so I assume it is a XML standard and the code base here should be 
> valid so assume there must be some difference in the way the Assertion 
> is signed.

OK, nothing Shibboleth can help with.

> I set this setting to false as my assumption is that the SAMLResponse 
> is the Assertion and it is encrypted using the Private key of the IDP 
> and can be decrypted using the Public key in the Metadata.

No, you encrypt using the public key of the relying party and sign with your private key.

> What senerio are we protecting against where the Assertion would be 
> modified and its signature be invalid yet the Encrypted data still be 
> encrypted by the IDP.

Anyone with access to your SAML metadata would be able to encrypt data to you and you wouldn't know from whom the data was (couldn't verify the issuer), at least assuming SAML WebSSO without SOAP attribute queries.
I.e., for an SP it would be very unwise to give access to its resources based on data from an unverified party.

> I am new to SAML so maybe there is a sernerio I don't understand where 
> the assertion can be modified.

This is not specific to SAML but basic public key crypto. Encryption gives you Confidentiality but only signing also gives you Authencitity/Integrity. The info doesn't need to be modified, it can just be replaced with any other.

> It is another layer of security and I would prefer to have it enabled.  
> Can some one on this list point me to the document on how the 
> assertion text is signed and how the key is determined and I can 
> figure out a work around.

Try <saml-dev at lists.oasis-open.org> for general SAML questions.

> Issue 3
> I think you miss understand the issue. The issue is with OIOSAML as 
> from what I read SubjectID is not required to contain a NameID so not 
> returning it is fine by the spec. The issue is OIOSAML.net is hard 
> coded to expect it so the Assertion parsing failss when it is not 
> present. This is a bug in OIOSAML.net not Shibboleth

Right, though OIOSAML wouldn't be the only implementation falling over without a NameID in the Subject. (IIRC SimpleSAMLphp also suffers from
that.)

> Issue 4.   
> The source code calls this function for each Binding in the loaded 
> meta data so the Default is hit and throws an error if any but the 
> coded ones exist. Its just a bug that OIOSAML needs to fix.

OK.

Thanks for the additional info and context. Would be great if you could add some of that to the wiki page.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net