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.
Related
How do I install a signing certificate in Keycloak when using Keycloak as a Service Provider (SP) that should connect to a (non-Keycloak) Identity Provider (IdP)?
To be more precise, Keycloak should be used as an Identity Broker (as described in the Keycloak documentation) and the communication between the Keycloak SP and the IdP is going to be facilitated via the SAML 2.0 protocol.
The Keycloak documentation contains information on how to install SSL certificates for doing "normal" HTTPS communication e.g. in the browser, but I cannot find anything regarding the installation of signing certificates to be used in the backend-to-backend SAML communication with the IdP. Does anyone know how to do this?
(Maybe only one certificate is installed into Keycloak, i.e. this certificate is used for both SAML communication and other non-SAML Keycloak HTTPS communication?)
How do you see which Certificate is used by your SP for signing/encrypting SAML messages for/to the external IDP?
Go to Identity Providers -> your configured SAML IDP -> Export. The export contains the certificate which is used for signing/encryption. There must be at least one activated signing/encryption config in your IDP, otherwise you will not see a cert in the export
How can I change the Certificate used by my configured IDP?
When creating a realm, keycloak generates a RSA-SHA256 Cert which will by default be used by your configured IDP-Brokering Settings.
Go to Realm Settings -> Keys and you will see this one RS256 (RSA) with the provider (rsa-generated)
If you need another cert, switch to Providers Tab, Add Keystore e.g. rsa. Import your private key and certificate (both as PEM format!)
Back on the overview, disable the rsa-generated provider, your new generated provider should be the only active one with type RS256
If you now check the Export of your IDP again, the imported cert should be used inside the XML
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.
We are trying to federate our application, so that our customers can gain access to our application using their respective corporate identities.
Well, I understand the mechanism of federation process, I’ve been able to setting up ADFS and I’ve modified the code of our application for accepting claims into my lab environment and all work fine.
In the next weeks I’m going to build a federation trust between ADFS and our customer’s product (Ping Identity) and I need your help to understand what kind of information I’ll have to exchange with customer’s IT department to complete that step.
I’ve never been experience with Ping Identity products.
Appreciate any help.
Many Thanks
I am going to make a couple of assumptions about your application, mainly that it is .NET application hosted on IIS. This type of application integrates Windows Identity Foundation (WIF) using tags in the web.config and then reads the authenticated users identity information via the Claims Identity object passed to your application. In this case your application is referred to as the Service Provider (SP).
If your customer is using PingFederate, the integration is straightforward in that a WS-Federation SP Connection would be configured on their server referred to as the Identity Provider (IdP). If your customer is using PingOne, then the integration will be tricky.
The information to exchange for PingFederate is driven by the configuration in the configuration in web.config. You need to configure the thumbprint which is based on the digital signing certificate of the WS-Federation response containing the SAMLv1.1 token. Your customer will be able to provide the thumbprint value. You will also need to configure the federated authentication URL, issuer, and realm, which is the information about PingFederate IdP server. The issuer is the URL for your SP application to redirect to the PingFederate IdP server, along with the realm which equates to the PingFederate SP Connection. Be sure that you configure the audienceUris to be the same value as the realm. The PingFederate administrator will need to know your Service URL endpoint which is your SP application endpoint to receive the WS-Federation response with the SAMLv1.1 token.
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.
I've got a site acting as an Identity Provider (IdP) for Single Sign on and another 2 service providers that authenticate against it using SAML 2. At the moment, both service providers use the same certificate to validate the SAML response from the IdP.
I've now got a 3rd Service Provider joining shortly and I wondered whether I should really be issuing separate certificates to each party so that we could potentially revoke their access, if required, without affecting the other Service Providers? What approach have others taken and why?
I'm using SimpleSamlPHP as the IdP.
As I understand, what you want is to be able to revoke SSO access for one SP but not all.
I would think this should not be done by revoking certificates but rather by removing the metadata from SimpleSamlPHP.
The problem with this is that the certificate information is in the IDP metadata that is sent to the SP and the metadata normally only allows for one certificate for one task (can be different tasks e.g. for signing and encryption).
Coming back the other way e.g. signing the SP Authn request, all the SP's can have different cetificates or they can share.
Some products e.g. ADFS 2.0 before Rollup 3 do not allow SP to share certificates.