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

[Andrew A. DeVries]

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.

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. 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.
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. 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.  I am new to SAML so maybe there is a sernerio I don't understand where the assertion can be modified.  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.

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

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.


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Friday, August 01, 2014 5:30 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 22:48]:
> I added clarification to the NameID issue and added more info 
> regarding the Assertion Signature omitAssertionSignatureCheck="true"
> issue.  I also added this to the CommercialInterop Wiki
> 
> https://wiki.shibboleth.net/confluence/display/SHIB2/OIOSAML.net+v1.76

I tried to fix the wiki formatting a bit but I think at least some of the issues are misunderstandings rather than code bugs:

Issue 1 could be missing configuration on the OIOSAML side to provide it with a key to actually sign authnRequests, or setting something to actually make it sign. Just saying, I know nothing about that code.

Issue 2 could be both, but it's not clear whether OIOSAML.Net fails to understand that a KeyDescriptor without a 'use' limitation can in fact be used for all purposes (signing and encryption), or whether that is just an issue in your interpreation of what is happening.

Either way, recommending to turn off signature validation at the SP is not a sensible thing to do and I doubt OIOSAML cannot be made to work in that regard. I.e., there must be better methods and I would not like to have such recommendations in the Shib wiki (not even in the Contribution section).

Issue 3 is the one most likely based on misconceptions about what Shibboleth needs or does: The Shibboleth software has NO requirement or preference for 'persistent' NameIDs (or any other), it just does not come preconfigured any specific NameID format out of the box other than transient, particularly not X509SubjectName which requires configuration from the deployer.
Not sure your description of the IDP's behaviour is correct here, but if the SP only lists X509SubjectName in NameIDFormat in SAML metadata and the IDP cannot produce this, well, personally I would expect an error message from the IDP, but at least not sending a /different/ type of NameID instead seems acceptable.
So if the SP cannot be sure that all IDPs it needs to federate with support a specific NameIDFormat it probably shouldn't request just that specific one, but either also accept other formats or not request any specific format at all.
So 3 is most likely a deployment issue, not a code bug. At least it looks like it's /also/ a deployment issue.

Issue 4 looks like it should return a supported binding and only fail when none have been found but maybe I'm misreading that code snippet and I don't know the context in which that code is called.

So maybe you/we can improve that wiki page further.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net