Getting PowerFAIDS NetPartner to work with Shibboleth 3
Peter Schober
peter.schober at univie.ac.at
Fri May 11 12:00:07 EDT 2018
* Daudt, Carl <crdaudt at taylor.edu> [2018-05-11 17:30]:
> My Net Partner logs indicate an ERROR that "SSO Response Digital
> Signature could not be validated".
Simple: You gave the IDP the wrong cert.
> In my Net Partner configuration, I have specified that the Public
> Key Certificate" for my IdP is my idp-encryption.crt file (I have
> also tried idp-signing.crt - to be honest, I am not sure which to
> use).
In order to validate your signature the SP needs your signing cert,
not encryption. (And you only have to even deal with these sorts of
questions because the SP doesn't support standard SAML 2.0 Metadata).
> I have also specified that my IdP URL is
> https://myshibbolethserver.myuniversity.edu/idp/profile/SAML2/Redirect/SSO
> my Protocol Binding is POST, and my Requested NameId Format is
> unspecified (other options include persistent, transient,
> emailAdress, and various other options).
Hard to say, not knowing the SP. And there are 2 "protocol bindings"
involved: How the authenticaton request from the SP is sent to the
IDP, and how to send the response from the IDP back to the SP.
Given your SSO URL above this means the SP would have to send the
request using HTTP-Redirect binding. If they do, that will be fine.
If they send the request using HTTP-POST (which you'll know from the
error message the IDP will generate in that case) you'd have to give
them the URL of your HTTP-POST SSO endpoint instead (s/Redirect/POST/
in the URL above). For the response your IDP will use the HTTP-POST
binding, so if "Protocol Binding is POST" refers to the response then
that's fine. (If it means the request then change the SSO URL as per
above.)
You don't provide sufficient details to give specific advise about
NameID configuration. I'd avoid using unspecified if at all possible.
According to the post from the archives you reference the expected
data is some form of "employeeID"? None of the NameID formats OASIS
defined are suitable for that.
Maybe the don't even check the format, though, many "vended" SPs don't
even bother. In that case you can send any NameID format URI you like,
including e.g. urn:oid:... for the LDAP attribute you're sending them.
That at least avoids having to dig into activation conditions when the
next SP comes along that specifically expects you to send something
very differently but also in an "unspecified" NameID.
-peter
More information about the users
mailing list