Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-9403

Implement CRL checking for certificate-based authentication other than in the native Java parsing



    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 13.0.0
    • Fix Version/s: None
    • Component/s: configurator
    • Labels:
    • Rank:
    • Support Ticket IDs:


      Customer writes..
      We have a customer who would like us to enable CRL checking for their certificate-based authentication in OpenAM itself (we are protecting access to the OpenAM console and need to make sure we are checking CRLs). The customer's PKI is the DoD PKI, which has several active CAs, each of which have CRLs with about 600,000 entries, so they are very large CRLs.

      There have been many historical problems with parsing CRLs of this size using native Java - for instance, https://bugs.openjdk.java.net/browse/JDK-6670894 and the related issues linked there, some of which have existed for a very long time (8 years is the longest I remember seeing) and are unlikely to be fixed by Oracle. The net result is that CRLs of sizes over, I think, 16 megs cause large hangs in the JVM and consume far too much memory to make their use workable.

      OpenAM uses the native Java libraries for parsing and processing CRLs as far as I can tell. For instance, https://github.com/OpenRock/OpenAM/blob/master/openam-certs/src/main/java/com/sun/identity/security/cert/AMCertPath.java uses the CertificateFactory and other classes from java.security.cert that are the native way to parse and process CRLs.

      Is there any consideration to implementing something other than the native Java parsing? We have, for instance, used bouncycastle in other projects to implement CRL processing for these very large files, and that approach avoids the problems with the native Java classes. We are closed source and I can't provide the specific example, but something like this from Apache CXF is similar in nature: https://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.4/distribution/src/main/release/samples/sts_issue_operation/src/main/java/demo/sts/provider/cert/CRLVerifier.java .

      If it matters, we use both OpenAM 12.0.3 and OpenAM 13 in production, but I don't think CRL processing has changed in the product for a very long time, so the root problem is probably the same in each.

      I think it'd be great if the base product switched over to doing something like this, but even if it did not, if the base product allowed us to implement our own CRL checking plugins and gave us a hook with which to do it, that'd be fine too, as it'd allow us to implement our own approach to solving the problem.

      This customer accredits their information systems in accordance with the DIACAP and RMF control sets, defined by the US government. Under both DIACAP and RMF, use of revocation checking for certificate-based login is a required element of system configuration: without this checking, a system will fail to be accredited and cannot be used.

      An example of a specific DIACAP control is https://www.stigviewer.com/stig/application_security_and_development/2014-04-03/finding/V-6129 - V-6129 is a Category 1 finding, meaning it is of the highest severity and can block a system from making it to the field. The RMF control set is IA-5(2) from https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=IA-5 .

      In both cases, CRL checking is required (not just by this customer, but by all US federal customers, either now or soon). Combined with that, the customer's PKI issues very large CRLs: each of DoD CA 30, 31, and 32 have 600,000 entries and approach 30 megabytes of size, easily enough to trigger the JRE bugs related to CRL handling that we've been discussing.

      So, in terms of business justification, in order to satisfy PK login requirements to OpenAM using the OpenAM configuration available for this (see issue #10355 for my prior conversation with FR support about how to do this and how it is enabled for the administrative console, which is the current hot issue for this customer), CRL processing must be more efficient than the Java native processing. Information systems developed for this customer will fail to be accredited, and will not be fielded, and this will lead to loss of business for FR as customers move to solutions that work.

      Time frame:-
      I can't put a timeframe on when a solution would be ideally available - I am guessing that the customer will tell us "ASAP" when we bring this to their attention.




            peter.major Peter Major [X] (Inactive)
            darshan.bhatt Darshan Bhatt [X] (Inactive)
            0 Vote for this issue
            5 Start watching this issue