Uploaded image for project: 'OpenSAML - Java'
  1. OpenSAML - Java
  2. OSJ-269

JPA StorageService fails badly with case-insensitive tables

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 3.0.0, 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.4.0, 3.4.1, 3.4.2
    • Fix Version/s: 4.0.0, 3.4.3
    • Component/s: Storage
    • Labels:
      None
    • Environment:

      The Servlet Container is jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z

    • Operating System:
      Linux
    • Java Version:
      Other OpenJDK 8
    • Servlet Container:
      Other

      Description

      Some days ago I experienced an anomaly in Shibboleth IdP behavior. In fact, when a user that: 1) had already performed un authetication in the past and 2) also had approved the terms-of-use (that are stored in the StorageRecords table in the shibboleth database), try to authenticate using a wrong username (in which he mix of lowercase and uppercase character), using a browser that support a default language that are different from the one used when he have accepted the terms-of-use, we experienced an anomaly.
      Specifically, the Authentication succeeded always because the IdP automatically convert al the character in lowercase (and this is correct), but the same behavior doesn't occurs when the username is used from "intercept/terms-of-use" as a database key (so, in fact, it remains a mix of lowercase with uppercase). This situation causes an HibernateExecepion, of the type "Error committing transaction" and the subsequent losing of the db connection (we use a JPAStorageService).

      So, because for our privacy policy GDPR compliant, we use a StoredPersistentIdGenerator strategy, nobody can authenticate after this event.
      If we use the status.sh script we can see that all the shibboleth services are running (in fact we can notice an error only when we force the reload of the service "shibboleth.NameIdentifierGenerationService").

      Definitely, in order to reactivate the IdP's operation we must restart the Jetty service.

      Currently I have modified the "simple-subject-c14n-config.xml" files in orter to force, after the authentication, the username's lowercase transformation (I have used the following syntax: <util:constant static-field="java.lang.Boolean.TRUE" id="shibboleth.c14n.simple.Lowercase"/>).
      This protects us from errors in typing the username, but I fear that the problem may be more general

      So, I'm worried that another case can be determined that causes a committing transaction error, resulting in the loss of the connection to the database. In fact, I would expect that as a result of an error the connection will be restored anyway, without the need to restart the Jetty service.

        Attachments

        1. 2019_02_19_idp_process_log_EXTRACT.txt
          4 kB
          Francesco Ciclosi
        2. 2019_02_19_Status_Idp_AFTER_SERVICE_RELOAD.txt
          6 kB
          Francesco Ciclosi
        3. Screenshot_2019-03-06 OpenIdP Login Page - Uncaught Exception.png
          136 kB
          Takeshi Nishimura
        4. idp-warn-2019-03-06.log.SHIEN-3695
          23 kB
          Takeshi Nishimura
        5. idp-process-2019-03-07.log.SHIEN-3695
          3 kB
          Takeshi Nishimura
        6. idp-process-2019-03-16.log.OSJ-269
          7 kB
          Takeshi Nishimura
        7. idp-process-2019-03-19.log.OSJ-269
          6 kB
          Takeshi Nishimura

          Issue Links

            Activity

              People

              Assignee:
              dfisher@vt.edu Daniel W Fisher
              Reporter:
              f.ciclosi@unimc.it Francesco Ciclosi
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 2 days, 4 hours, 45 minutes
                  2d 4h 45m