A previously asked question touches on topics which are very similar to what I am having trouble understanding.

In a web application I am testing, SAML SSO is brokered using Keycloak. The SAML Response messages contain Encrypted Assertions (<saml:EncryptedAssertion>). Before the encrypted assertion is a Signature (<dsig:Signature>); if the signature is removed, the SP still accepts the user authentication.

  1. Can the content of these messages only be read by the SP/IdP/Keycloak?
  2. Can new assertions be encrypted using an available public key, thus replacing the original assertion? If so, where/how can the relevant public key be found?
  3. What is the purpose of the signature if removing it does nothing? Is this an issue with Keycloak (the broker)? Is the SP responsible for verifying the signature?

I may be missing some knowledge regarding Keycloak's way of brokering authentication, or the SAML flow itself, but I can't seem to find much info about any of this online, apart from the above linked question, which is still partially unanswered.

EDIT: Attaching an example of a SAML Response as I am seeing it:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response Destination="https://example.com/saml/SSO"
  IssueInstant="2020-06-29T00:00:0000Z" Version="2.0"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sso.example.com/auth/realms/MY-APP</saml:Issuer>
  <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <dsig:Reference URI="#ID_0000000-000-000-000-00000000">
          <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  <saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
  • I'm not familiar with Keycloak, but in standard SAML the SP is responsible for validating the signature. If signature is removed and the SSO still succeeds this indicates a problem with the SP.
    – Steve P
    Jun 29, 2020 at 16:38
  • Thanks for clarifying. Regarding the encrypted assertions, is the content only readable by the SP? Is there a public key I can easily obtain and use to encrypt new contents?
    – Charles
    Jun 30, 2020 at 13:35
  • 2
    Typical integrity and confidentiality requirements: IdP signs a response with its private key, ensuring no one but the IdP could have created the response and assertion, but letting anyone validate the response. The IdP encrypts an assertion with the SP's public key, ensuring ONLY the SP can decrypt with its private key. Together, these things make a very secure box. If Keycloak is not validating the signature on the response (the "envelope" of an encrypted assertion), then that's a defect in KeyCloak.
    – Andrew K.
    Jun 30, 2020 at 14:20
  • I admit I'm a bit confused. In this case, is it not the SP's responsibility to verify the signature received from Keycloak (since Keycloak is only the middleman/broker)? I think the SP is the one receiving the SAML Response and deciding on how to proceed.
    – Charles
    Jun 30, 2020 at 22:26

2 Answers 2


Not fully understand Keycloak service either, but here is the basic of SAML Response (IdP to SP), unless IdP-SP agreed to do something different on its own:

  • IDP encrypts sensitive content with SP's public key and signed with IdP's private key.
  • SP decrypts with its private key, and verify signature using IdP's public key.

So to pull off MITM's content replacement, MITM has to have SP's public. So, unless SP waves its public key around on Internet, it is seen by IdP and itself only. In addition, SP needs to skip signature check. Again, I don't see any library doing this by default.

But back to your question...

  1. Can the content of these messages only be read by the SP/IdP/Keycloak?

The original Encrypted content is visible to IdP (who generates the content) and whoever have IdP's private key

  1. Can new assertions be encrypted using an available public key, thus replacing the original assertion? If so, where/how can the relevant public key be found?

Definitely. Per protocol, IdP publishes its SAML2 metadata online for their clients to validate signature.

  1. What is the purpose of the signature if removing it does nothing? Is this an issue with Keycloak (the broker)? Is the SP responsible for verifying the signature?

Any encrypted message without signature is not trustworthy. It should not be accepted.

  • One of the answers in the question I linked to says the following: "In your scenario it's possible that the encrypted assertion is signed and the SP is verifying the assertion's signature. However, it's unusual for both the SAML response and assertion to be signed so I would question whether the assertion is actually signed." Can I clearly tell if an Encrypted Assertion is signed? Or is the signature itself part of an encrypted value?
    – Charles
    Jul 1, 2020 at 0:59

Since you mentioned that you are testing this application, I would like to suggest two more scenarios for you to try. You have observed that the signature is not being validated by the SP, hence it is possible that there is custom code written to process the IdP's response.

I would suggest you also test for replay attacks by sending an older SAML response from IdP to service provider. As the application is solely relying on the encrypted message and the integrity is not checked, it is possible that a replay attack may be successful

Another possibility is to try a signature wrapping attack. This would be easier to perform if you knew how the original assertion looked like. If you have access to that information it is worth a try. The idea here to add another assertion in the response without altering the original assertion. In some implementations it is possible that the application logic assumes that there will always be one assertion block in the response. This way you can trick the SP in using your Assertion block while authenticating the user.

See this paper on XML signature wrapping attacks. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf

  • Thank you for the suggestions. I have tested for replay attacks, I believe the timestamp is checked and therefore the attacks fail. I would also like to try a signature wrapping attack, but since I don't know what the encrypted assertion contains, I don't know what the SP expects. If I did know the assertion format, where would I be able to find info on how exactly the message should be encrypted? Do you know of any tools available to help with this?
    – Charles
    Jul 1, 2020 at 11:36
  • Encrypting the message would not be possible because whatever method you use the SP would never be able to decrypt a message that you encrypted. It would be worth trying to inject a plaintext assertion and see how the application responds. Again you would need to guess what the application expects in an assertion so it might take some trial and error.
    – Shurmajee
    Jul 1, 2020 at 12:48
  • I was able to speak with the developer and get a better understanding of the situation. The Encrypted Assertion contains the data being sent to the SP and also another signature. So it seems the SP is relying solely on the contents of the Encrypted Assertion, which includes "its own" signature; meaning the "outer" signature is somewhat useless (which raises the question of why it is even there). To clarify, when I said I would try to encrypt the message, I meant encrypting it using the SP public key so that SP would be able to read its contents.
    – Charles
    Jul 1, 2020 at 13:52
  • That might be a good way to verify the developers claim. You can encrypt an assertion and see how the app responds. It would make your life easy if the developer agrees to share the plaintext assertion for testing. If that is not possible , I feel this should at least go as as informational finding in the report based on what you observed.
    – Shurmajee
    Jul 1, 2020 at 14:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .