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

[Peter Schober]

* 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