Shibd process crashes shibd.exe version 2.53
cantor.2 at osu.edu
Fri May 16 09:54:42 EDT 2014
On 5/16/14, 3:29 AM, "pvenkatesh at moxiesoft.com" <pvenkatesh at moxiesoft.com>
>The signing key is 4096 bits. I don't think its the response from the IDP
>that is crashing the process.
Ok. That's still fairly large. Whether it's too large is difficult to say,
but I would suggest they avoid anything over 3192 as a test.
>I tested and can confirmed that the crash happens only when the 'key'
>attribute is not provided in the <credentialresolver tag
Unless that credential is only used for metadata verification or something
like that, that's not really useful anyway. There might be a bug in some
of the code around handling keyless credentials, but since you don't ever
need that, it's minor.
>If I change it to , <CredentialResolver type="File" key="
>"certificate="qa-smfed.koccr.com.pem"/> Shibd process does not crash.
You need a private key. Or you don't install one at all. You don't install
a certificate as a credential with no key along with it.
>As the partner is using a private key to sign the message they are sending
>over to SP. Its was my understanding that to decrypt and verify the signed
>SAML response sent by IDP to Shib's SP I will have to provide the cert in
>the 'certificate attribute' of the <CredentialResolver Tag.
No, that's not how this works. You are confusing encryption and signing,
and in either event, I don't know what certificate you're talking about or
what that has to do with this. You don't install their certificate
anywhere, it's in the metadata you have to supply. If they're encrypting,
they have to have your public key, and you'd have to have your private key
>As,I didn't want the response back from SP to IDP to be signed , hence had
>removed the key information.
There is no response from SP to IdP. If you mean requests, those aren't
signed by default anyway.
More information about the users