I am trying to implement SSO for a service and using ADFS and PingFederate as IDP.
SSO works when I avoid signing the AuthRequest (both with ADFS and PingFederate), but fails with following error "SAML Message has wrong signature. Issuer: 'My SP entityID' " when AuthRequest is signed.
I had updated corresponding Relying trust part with certificate of my SP. I think, i am doing something wrong in the IDP configuration. Any help is appreciated.
I had tried this answer without any luck: MSIS0038: SAML Message has wrong signature - ADFS error
This error on ADFS is received when the AuthnRequest is signed but the SP's certificate configured is incorrect. Make sure that you have provided the correct certificate, go to Relying Party Properties > Signature tab. You should see the certificate provided by you. Verify the thumbprint to be sure.
Also, if you are sending the SAMLRequest as a query parameter (HTTP-Redirect binding), make sure you are using the SHA1 certificate for signing the AuthnRequest. Signing using the SHA256 certificate is not supported in HTTP-Redirect binding by ADFS.
Related
I'm a Service Provider, and the SME for the Identity Provider has specified that they require that the SP provide them a certificate different from the standard server certificate.
Every SSO Integration I've accomplished so far has had the IdP provide me with the certificate.
Is a SP able create and provide a separate certificate to the IdP?
Currently, the IdP SME is advising that unless I can provide this, he won't enable Solicited SSO(SP-Initiated SSO).
Background:
1. Originally SAML based on the ADFS works fine, but after the ADFS certificate update, it can't work fine. Since the certificate of the ADFS will be expired, so we update the certificate, but unfortunately can not work fine with updated certificate ADFS
The exception is "Signature is not trusted or invalid" which thrown in the spring SAML. Does there exist some especially needed to be noticed when update the ADFS certificate?
You need to regenerate the Identity provider (IDP) XML file i.e federation-metadata.xml and exchange with the client i.e Service provider. As you mentioned that ADFS certificates were expired and you reconfigured the new certificates, so those play a significant role for encryption and signing of assertions issued from the IDP based on how the system is configured. You have made the changes on the IDP side but on SP side still, old federation-metadata.xml is in use with old certificates. When IDP issued assertions or response, that response is validated by using those certificates. When you regenerate that file it will contain the latest details related to certificates. So you need to regenerate the federation-metadata.xml and share with the service provider (SP) in order to fix the issue.
Hi I have multiple IDPs registered under our ADFS Claims Trust Provider. One of the IDP's federation metadata has expired certificate. Corresponding party has successful integration (with expired certificate) with other 3rd party Service Provider (non MS platform). So basically I was told to integrate this IDP with expired certificate under our ADFS SP.
Now every time when User from this IDP logs in and try to get redirected via ADFS we get following error in event log.
An error occurred during an attempt to build the certificate chain for the claims provider trust 'https://xyz.com/opensso' certificate identified by thumbprint 'D13412341231312312311231313123'.
Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the claims provider trust's signing certificate revocation settings or certificate is not within its validity period.
You can use Windows PowerShell commands for AD FS to configure the revocation settings for the claims provider trust's signing certificate.
Claims provider trust's signing certificate revocation settings: None
The following errors occurred while building the certificate chain:
MSIS2013: A required certificate is not within its validity period when verifying against the current system clock.
User Action:
Ensure that the claims provider trust's signing certificate is valid and has not been revoked.
Ensure that AD FS can access the certificate revocation list if the revocation setting does not specify "none" or a "cache only" setting.
Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).
I already tried following cmdlets but no success so far.
Set-ADFSClaimsProviderTrust -TargetName "ABC Test" -SigningCertificateRevocationCheck "None"
Set-ADFSClaimsProviderTrust -TargetName "ABC Test" -EncryptionCertificateRevocationCheck "None"
We are using ADFS 3.0 in farm setup. Is it really possible to use Claims Identity Provider with expired certificate?
Thanks
No - it's not.
All based on trust and if the certificate has expired so has the trust.
The commands that you are running are simply telling ADFS not to verify the validity of the certificate in terms of the CA signing authority.
There is no command to unexpire a certificate - you need to get a new, valid one.
And that's the way it should it should be from a security PoV.
Here's the question:
Is there any benefit to securing a SAML assertion with a CA cert? I understand how using a CA cert is of benefit when establishing the SSL connection over which the SAML assertion is transported, but what about a CA cert for the PKI handshake that occurs when the SP accepts the SAML assertion itself? I have one side contending that within the SAML exchange there's no way for the SP to iterate through the chain of trust to the root CA cert, while on the other side I have someone saying that it can.
Bonus points if you can point me to an authoritative source that supports your answer.
If I understand you correctly you wonder if there is any point in using a certificate sign by a CA when signing the SAML assertion.
In my opinion you should not need this. When you establish the initial trust and exchange metadata you can include the public key of the entity in the metadata.
If you can trust that the exchange of metadata is secure, you can just verify the signature against the public key in metadata.
I can not see how a CA would give any value to this situation.
I agree too. Although in standard Shibboleth Metadata sharing mechanism (Federation) the whole published metadata block is sign by Federation certificate. So PKI may be (and probably is) used to distribute service and IdP metadata between security partners. But as Stefan wrote, there is no point in signing Assertion with Certificate signed by trusted CA
Is it possible to sign a SAML 2.0 post with a self-signed certificate? I am in charge of implementing a new SSO procedure with a vendor using SAML 2.0 and we trying to determine if we can sign the SAML post with a self-signed certificate or if we need to buy one.
If we can use a self-signed certificate, does the Service Provider need to do any additional steps to verify the signature? We are creating the SAML 2.0 post as the Identity Provider.
Thanks in advance.
Yes, I assume you mean signing the Assertion that is returned via POST binding (see SAML 2.0 Profiles, section 4.1.4.5). The SAML 2.0 specification mandates it be signed for SSO, but doesn't get into specifics of CA signed vs. self-signed.
Check with your software (both IdP and SP side) to see what is supported - some have limitations in this regard.
The SAML spec actually recommends that you use long-lived self-signed certificates. See this document for more info