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

[Peter Schober]

* 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