Configure ADFS as SP (Client) in Keycloak


i have the following scenario.

Application (WebApplication)
ADFS - with the Application as Relaying Party Trust
ADFS - with Keycloak as Claim Provider Trust.

Keycloak as IdP.

I would configure the ADFS Server via SAML Protocol as “Client” on the Keycloak Server.
The Configuration was made with the MetaData XML File from the ADFS Server.
So i assume that all the needed Entries are made automatically.

If i send the authentication request to the Application, i get redirected to the ADFS SP, afterwards i get redirected to the Keycloak Server, then i enter my Credentials, afterwards i get redirected to the ADFS Server in /adfs/ls/.

As soon as i got redirected to the ADFS SP again, i get an Error on the ADFS Server that says:

Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolException: MSIS1022: Cannot process SAML Response from ‘’.
Inner exception: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
IsReadOnly = False,
Count = 1,
Clause[0] = Microsoft.IdentityServer.Tokens.MSISSecurityKeyIdentifierClause
'. Ensure that the SecurityTokenResolver is populated with the required key.
at Microsoft.IdentityServer.Service.Tokens.SamlMessageSecurityTokenHandler.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.ReadSecurityToken(XmlElement securityTokenXml, SecurityTokenHandlerCollection securityTokenHandlers)
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.GetSecurityToken()
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.CreateSubject(XmlElement securityTokenXml, SecurityTokenHandlerCollection securityTokenHandlers)
at Microsoft.IdentityModel.Tokens.SecurityTokenElement.GetSubject()
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.GetEffectivePrincipal(SecurityTokenElement securityTokenElement)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest issueRequest)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message requestMessage)

First it looks like a missing Certificate - but i installed the Public Keys on the ADFS Server.

You have any Idea what this could be caused by?
Is there a “Best Practise” on how to add an ADFS Service / Application Provider?

Thanks and greetings


We got the exact same issue with Keycloak server and ADFS as a Client (imported via the federationmetadata.xml).

Did you find any solution/fix for this problem ?

Any help is welcome…



We had a similar scenario, the following settings worked for us:


Thank you for your answer @mbonn ; we just tried your configuration but got the same error.

Error details: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier ( IsReadOnly = False, Count = 3, Clause[0] = Microsoft.IdentityServer.Tokens.MSISSecurityKeyIdentifierClause, Clause[1] = Microsoft.IdentityServer.Tokens.MSISSecurityKeyIdentifierClause, Clause[2] = Microsoft.IdentityServer.Tokens.MSISSecurityKeyIdentifierClause ) '. Ensure that the SecurityTokenResolver is populated with the required key.

We are using Keycloak 20.0.3 deployed in our Kubernetes Cluster with Bitnami Helm Chart.

This is our Helm Chart values.yaml: values.yaml

And we’ve imported our letsencrypt cert/pub key into the Master Realm: screen of the conf

Is there any obvious config we’re missing to make Keycloak (IdP) works with ADFS (Client) ?

Have you tried to disable the non-letsencrypt RSA keys to make keycloak definitely sign with the key you have deployed in ADFS? SAML with having more than one RSA key enabled is a pita with keycloak… Also ADFS is not able to handle more than one key.

Just tried your idea, we deleted the others self-signed keys (except the hmac-generated one).

We still got the same error.

But when I activate the key provider (the letsencrypt one) in the Keycloal WebUI “Enabled” and “Active” checked (see third screen below), it does validate and save, but when I get back into the provider, the two button are back to “off”.

WebUI bug ? letsencrypt keys not compatible ?

Here’re the screens for my current Realm settings keys configuration:


Another thing, is there any specific things to do on the ADFS side ? Like importing a specific key or cert somewhere (idk, the ADFS is not managed by us).

Yes, you have to import the ceritficate in ADFS, without ther cert ADFS is not able to validate your SAML assertion response.

I have no idea about the new admin UI and certs, I am still using the old console. And I would not use Let’s Encrypt certificates as SSO singing cert, because of the 3-month lifetime, that’s impractical with SAML.

Ok, do you have by any chance any ressource/guide for importing the certificate into ADFS ?

Because I’ve already sent my letsencrypt certificate and public key to the Administrator of the remote ADFS but he seems like he wasn’t able to import it into ADFS (or it just doesn’t work with my setup or this letsencrypt cert…).

Also if you have the openssl command used to generate the proper cert/pub key for Keycloak, can you share it with me please ?

Do I have to use keytool (I don’t understand what Truststore and Keystore are used for, most of the guides dont mention them at all) or just openssl ?

Thanks a lot @mbonn

I have no guide, sorry, just Google:

(in our organization, we have Azure AD connected, where Configuration is automated via Powershell Scripts)
I do not have OpenSSL commands for self-signed certificates, I would first try the keycloak-generated certs. If that does not work, try OpenSSL, there’s also Google:

If using an OpenSSL sef-signed certificate, I would import it in keycloak’s database with the admin console, not use keystore. Keystore is password-protected and may be more secure (depends on who has access to your database), but keystore usage is painful crap… anyway, for keystore, I worked with keystore explorer:

Okay, well the Google part I already did (got about 60 bookmarks more or less related to find a way to fix this specific issue). :smiling_face_with_tear:

I’ve got a call with the ADFS Administrator and did a little more debug of the SAML request/answer in our setup.

I think the issue might be caused by the “KeyName” attribute containing the certificate ID.

ADFS check the CN and Thumbprint of the cert (in this case “master” since it’s the autogenerated cert of the master instance of Keycloak) but we’re sending the ID generated in Keycloak, not “master” as identifier of the cert.

[Subject] CN=master [Issuer] CN=master [SerialNumber] 0184C903B182
[Not Before] 11/30/2022 3:47:53PM
[Not After] 11/30/2032 3:49:33PM
[Thumbprint] B09FC849B129975A5434A68F027248831C82E300

Links related to the KeyName “usual suspect”:

Still don’t know how to fix this, I’m going to continue my test (it’s been two weeks of that mostly).

Anyway, thanks a lot for your answers @mbonn :+1:

Problem Solved.

It was a bug with the Keycloak v2 theme. The “SAML Signature Key Name” do not take into account the change to “CERT_SUBJECT” when using the new interface.

Value sent by new interface:
Value sent by old interface:
The ‘$’ character should not be here in the first value (new interface). See Keycloak source code.

If you want it to works, switch to the old Keycloak WebUI.

3 weeks working on this issue…

Adding new features or deprecating/removing working things seem to be more important than fixing bugs…

Hey Guys,

sorry for the Late Response. Was working on some other Stuff :smiley: .
I’m going to read the Thread and maybe the Solution is going to help us as well.
Big Thanks to @john_doe and @mbonn for your Time, Patience, and Work :smiley:

Currently, we discarded the “ADFS as SP (Client)” Method, BUT because i couldn’t Sleep for days because of this issue. I’m going to test it and give you feedback.

Thanks again - Great Work!

The Problem seems to be solved with keycloak v21.1.0.
I already tested it in my Lab-Enviroment.

Keycloak IdP - ADFS SP - Application.

#17808 “SAML signature key name” attribute is not well forged.