Announcement Announcement Module
Collapse
No announcement yet.
protocolCache Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • protocolCache

    What is the intent of the protocolCache in Spring Security SAML? I was surprised to see that kind of state maintained. Is there a reason you want the SP to verify it was the sender of the AuthNRequest?

  • #2
    The SAMLMessageStorage (or ProtocolCache) is used for message correlation and is one of the mechanisms preventing replay attacks and message insertion/deletion attacks.

    Each message originated from the Service Provider is assigned an unique messageId and IDP is obliged to include it in the inResponseTo field of the SAML response. Without information whether the SP originally sent the request or not it could be possible to reuse the same Assertion multiple times and such event would go unnoticed. The stored original message is also used to perform validation of the data returned from the IDP (like used authentication context or requested subject).

    Message correlation and checking of the inResponseTo field is also required by the SAML standard.

    Comment


    • #3
      I understand, however we are running into a bug where a browser with two tabs, both accessing the same protected resource launches. The first tab causes a request and a key is generated in the protocol cache. The second tab also causes a request to be sent but because its the same session, the "new" key in the protocolCache is the same key as the previous request. On the response, the key is removed and whichever response comes in 2nd, a verification failure occurs.

      In thinking about this, it could be argued that its a bug in the way the protocol cache keys are generated since they don't distinguish across multiple requests.
      Last edited by richardl; Apr 27th, 2011, 01:47 PM.

      Comment


      • #4
        It seems to me like you're using the old version of the SAML Extension from https://jira.springsource.org/browse/SEC-1004. The project has gone a long way since then and until there's an official release the best way to get the latest version is using "git clone git://git.springsource.org/spring-security/se-security".

        I was trying to reproduce the problem you describe with this version, but without success. In case the version change doesn’t help could you please open a Jira issue at http://jira.springsource.org/browse/SES?

        Comment


        • #5
          Ive mostly got a test running but our SDP metadata was completely different than what is being generated by the newest code. I don't really understand how you are supposed to get your own metadata but I used the saml2-sample to generate metadata.

          I get the error::
          Metadata for entity https://<hostname>:443 and role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescrip tor wasn't found. I'm not even sure what its looking for here.

          Comment


          • #6
            The system seems to think that there should be a service provider entity with entityID "https://<hostname>:443" in the configured metadata, but can't find it. Can you please check what the value of property "hostedSPName" in the "metadata" bean of your springSecurity configuration is? Does it correspond to attribute "entityId" of your service provider metadata?

            As a resume - metadata can be created in multiple ways. In case you have included "metadataFilter" in your configuration the metadata will be generated automatically upon first request (unless it was already configured). This approach should be used only for development purposes, in production the metadata file should be always fixed by updating "metadata" bean inside springSecurity.xml and pointing it to a prepared metadata file.

            The sample application also contains a user interface for metadata generation, just click "Metadata information" on the index page and follow the instructions which enable you to customize the generated content. Once done store everything in a file and point to it from the springSecurity.xml. In case you don't use extended metadata you need to set hostedSP property to the value of entityId of your service provider.

            Comment


            • #7
              I was finally able to get our application migrated to the latest code and generating default metadata. I dont see any differences in the way the protocolCache is handled within WebSSOProfileConsumerImpl that would make a difference in what we are seeing. Can you provide some insight into why you think this might address the issue we are seeing?

              Comment


              • #8
                I was trying to reproduce the problem you describe, but without success. Each tab generates a different MessageID and the responses can be consumed correctly in my environment. The only way I see the same messageID could get generated is to send both requests from both tabs at exactly the same time (same ms), is that the case? Could you please send me some more information about how to get this reproduced and if possible open an issue at https://jira.springsource.org/browse/SES?

                Comment

                Working...
                X