CAC user registration no longer works as of 23.0.7-bb.1
As of Big Bang 2.23.0, which includes Keycloak release 23.0.7-bb.1, user registration with a CAC no longer works.
The browser displays message "An internal server error has occurred."
Associated log from the keycloak pod:
2024-03-27 20:09:00,035 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-3) Uncaught server error: java.lang.IllegalArgumentException: issuerCertificate cannot be null
Designs
Blocks
- #1762.30.01
Related merge requests 8
When these merge requests are accepted, this issue will be closed automatically.
- big-bang/customers/template !82
- big-bang/customers/template !812.29.0
Activity
added kindbug label
added keycloak label
Hi @jrb can we get a bit more log output and a sanitized version of your overrides please? Not very actionable with the current information.
Across dev/staging and our release environments CAC registration/update was successful during testing of this release
Sure.
Here is the helm command I'm using. Note that the bigbang
2.23.0tag is checked out.helm upgrade -i bigbang ~/git/repo1/bigbang/chart \ -n bigbang \ --create-namespace \ -f ~/git/repo1/bigbang/docs/assets/configs/example/policy-overrides-k3d.yaml \ -f ~/git/notes/overrides/registry-values.yaml \ -f ~/git/repo1/bigbang/chart/ingress-certs.yaml \ -f ~/git/notes/overrides/keycloak-issue.yamlAnd here are the contents of
keycloak-issue.yaml:comments: | This example values override file is provided FOR DEVELOPMENT/DEMO/TEST PURPOSES ONLY domain: bigbang.dev sso: url: https://keycloak.bigbang.dev/auth/realms/baby-yoda gatekeeper: enabled: false twistlock: enabled: false kyvernoPolicies: enabled: true values: validationFailureAction: "audit" grafana: enabled: false kiali: enabled: false loki: enabled: false monitoring: enabled: false neuvector: enabled: false promtail: enabled: false tempo: enabled: false flux: interval: 1m rollback: cleanupOnFail: false istio: ingressGateways: passthrough-ingressgateway: type: "LoadBalancer" gateways: passthrough: ingressGateway: "passthrough-ingressgateway" hosts: - "*.{{ .Values.domain }}" tls: mode: "PASSTHROUGH" values: values: # possible values found here https://istio.io/v1.5/docs/reference/config/installation-options (ignore 1.5, latest docs point here) global: # global istio operator values proxy: # mutating webhook injected istio sidecar proxy's values resources: requests: cpu: 0m # null get ignored if used here memory: 0Mi limits: cpu: 0m memory: 0Mi addons: argocd: enabled: false authservice: enabled: false minioOperator: enabled: false minio: enabled: false gitlab: enabled: false gitlabRunner: enabled: false nexusRepositoryManager: enabled: false sonarqube: enabled: false fortify: enabled: false anchore: enabled: false mattermostOperator: enabled: false mattermost: enabled: false velero: enabled: false vault: enabled: false metricsServer: # enabled: auto enabled: false harbor: enabled: false keycloak: enabled: true ingress: gateway: "passthrough" values: replicas: 1 command: - "/opt/keycloak/bin/kc.sh" args: # - "start" - "start-dev" - "--import-realm" # import-realm is not recommended for operational environments. # https://www.keycloak.org/server/all-config extraEnv: |- - name: KC_HTTPS_CERTIFICATE_FILE value: /opt/keycloak/conf/tls.crt - name: KC_HTTPS_CERTIFICATE_KEY_FILE value: /opt/keycloak/conf/tls.key - name: KC_HTTPS_TRUST_STORE_FILE value: /opt/keycloak/conf/truststore.jks - name: KC_HTTPS_TRUST_STORE_PASSWORD value: password - name: KC_HTTPS_CLIENT_AUTH value: request - name: KC_PROXY value: passthrough - name: KC_HTTP_ENABLED value: "true" - name: KC_HTTP_RELATIVE_PATH value: /auth - name: KC_HOSTNAME value: keycloak.bigbang.dev - name: KC_HOSTNAME_STRICT value: "true" - name: KC_HOSTNAME_STRICT_HTTPS value: "true" - name: KC_LOG_LEVEL value: "org.keycloak.events:DEBUG,org.infinispan:INFO,org.jgroups:INFO" - name: KC_CACHE value: ispn - name: KC_CACHE_STACK value: kubernetes - name: KC_METRICS_ENABLED value: "true" secrets: env: stringData: CUSTOM_REGISTRATION_CONFIG: /opt/keycloak/conf/customreg.yaml customreg: stringData: customreg.yaml: '{{ .Files.Get "resources/dev/baby-yoda.yaml" }}' realm: stringData: realm.json: '{{ .Files.Get "resources/dev/baby-yoda.json" }}' truststore: data: truststore.jks: |- {{ .Files.Get "resources/dev/truststore.jks" | b64enc }} quarkusproperties: stringData: quarkus.properties: '{{ .Files.Get "resources/dev/quarkus.properties" }}' extraInitContainers: |- - name: plugin image: registry1.dso.mil/ironbank/big-bang/p1-keycloak-plugin:3.3.0 imagePullPolicy: Always command: - sh - -c - | cp /app/p1-keycloak-plugin.jar /init ls -l /init volumeMounts: - name: plugin mountPath: "/init" extraVolumes: |- - name: customreg secret: secretName: {{ include "keycloak.fullname" . }}-customreg - name: realm secret: secretName: {{ include "keycloak.fullname" . }}-realm - name: plugin emptyDir: {} - name: truststore secret: secretName: {{ include "keycloak.fullname" . }}-truststore - name: quarkusproperties secret: secretName: {{ include "keycloak.fullname" . }}-quarkusproperties defaultMode: 0777 extraVolumeMounts: |- - name: customreg mountPath: /opt/keycloak/conf/customreg.yaml subPath: customreg.yaml readOnly: true - name: realm mountPath: /opt/keycloak/data/import/realm.json subPath: realm.json - name: plugin mountPath: /opt/keycloak/providers/p1-keycloak-plugin.jar subPath: p1-keycloak-plugin.jar - name: truststore mountPath: /opt/keycloak/conf/truststore.jks subPath: truststore.jks - name: quarkusproperties mountPath: /opt/keycloak/conf/quarkus.properties subPath: quarkus.propertiesThen, to reproduce the error:
- Navigate to https://keycloak.bigbang.dev using a CAC.
- At the bottom click "No account? Click here to register now.".
- "An internal server error has occurred" will be displayed in the browser.
Edited by Jonathan Braswell-
And here is the full stack trace from the keycloak-0 pod:
2024-03-28 16:29:04,882 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-4) Uncaught server error: java.lang.IllegalArgumentException: issuerCertificate cannot be null at org.keycloak.utils.OCSPProvider.check(OCSPProvider.java:84) at dod.p1.keycloak.registration.X509Tools.getX509IdentityFromCertChain(X509Tools.java:212) at dod.p1.keycloak.registration.X509Tools.getX509Identity(X509Tools.java:293) at dod.p1.keycloak.registration.X509Tools.getX509Username(X509Tools.java:112) at dod.p1.keycloak.registration.X509Tools.getX509Username(X509Tools.java:125) at dod.p1.keycloak.registration.RegistrationValidation.buildPage(RegistrationValidation.java:181) at org.keycloak.authentication.FormAuthenticationFlow.renderForm(FormAuthenticationFlow.java:304) at org.keycloak.authentication.FormAuthenticationFlow.processFlow(FormAuthenticationFlow.java:285) at org.keycloak.authentication.DefaultAuthenticationFlow.processSingleFlowExecutionModel(DefaultAuthenticationFlow.java:380) at org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:249) at org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:1028) at org.keycloak.authentication.AuthenticationProcessor.authenticate(AuthenticationProcessor.java:885) at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.buildRegister(AuthorizationEndpoint.java:349) at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.process(AuthorizationEndpoint.java:198) at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.buildGet(AuthorizationEndpoint.java:113) at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint$quarkusrestinvoker$buildGet_4b690b27439f19dd29733dc5fd4004f24de0adb6.invoke(Unknown Source) at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29) at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141) at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145) at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576) at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538) at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29) at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:840) -
Only one warning, immediately before the stack trace.
2024-03-28 18:19:23,106 WARN [org.keycloak.events] (executor-thread-24) type="LOGIN_ERROR", realmId="baby-yoda", clientId="account", userId="null", ipAddress="127.0.0.6", error="user_not_found", x509_cert_subject_distinguished_name="CN=BRASWELL.JONATHAN.XXXX.XXXXXXXXXX, OU=CONTRACTOR, OU=PKI, OU=DoD, O=U.S. Government, C=US", auth_method="openid-connect", auth_type="code", x509_cert_issuer_distinguished_name="CN=DOD ID CA-64, OU=PKI, OU=DoD, O=U.S. Government, C=US", response_type="code", redirect_uri="https://keycloak.dev.bigbang.mil/auth/realms/baby-yoda/account/login-redirect", code_id="2b146910-5322-48ef-b671-f223ff8c8ddd", response_mode="query", x509_cert_serial_number="1535332", username="BRASWELL.JONATHAN.XXXX.XXXXXXXXXX"Seems like that would be normal for a user that doesn't exist?
-
Yes, this is for a brand new user on a new install. I believe the issue is related to the change in the plugin mentioned in #138 (comment 1997533).
-
I just did the following:
- Switched to the bigbang
masterbranch and pulled latest changes - Changed all instances of
bigbang.devtodev.bigbang.milin my values - Redeployed
I'm still experiencing the same issue. These same values work fine for us with the keycloak chart bundled with bigbang
2.22.0, so there's definitely some sort of issue. We've reproduced it with multiple CACs.Edited by Jonathan Braswell - Switched to the bigbang
-
Looking at the stack trace, it looks like the p1-auth-plugin isn't able to extract the issuerCertificate from the cert chain on my CAC. This happens in getX509IdentityFromCertChain, here: https://repo1.dso.mil/big-bang/product/plugins/keycloak-p1-auth-plugin/-/blob/main/p1-keycloak-plugin/src/main/java/dod/p1/keycloak/registration/X509Tools.java?ref_type=heads#L194.
It looks like there is a debug log statement there that could be helpful. Do you know how I can enable debug logging for the plugin?
-
Here is the commit that added the new check two weeks ago big-bang/product/plugins/keycloak-p1-auth-plugin@3e9bc3af.
According to that logic, issuerCertificate would be set to null if there is only one certificate in the certificate chain. Then, the OCSP check itself seems to always throw an exception if the passed issuerCertificate is null.
I don't know why there would only be one certificate in the certificate chain. Maybe this logic doesn't work with all CACs all the time?
Edited by Jonathan Braswell -
We just tried @ryan.j.garcia's CAC against my "broken" instance, and he was able to register without any issue. So, the issue doesn't exist for all CACs.
-
More information: This seems to be a problem with macOS. Everyone who has reproduced the problem (several) is using macOS. It seems that macOS does not send the entire certificate chain up, but only the client certificate. The new OCSP checking code in p1-auth-plugin's user registration workflow throws an exception if there is only one certificate in the certificate chain. This means macOS users cannot register using a CAC.
I created a Windows virtual machine to test. Using Windows, everything worked just fine, and I was able to complete user registration with a CAC. With debug logging, I could see that the entire certificate chain was sent to the server, which allowed the new changes in p1-auth-plugin to get through the OCSP check without error.
Edited by Jonathan Braswell
removed keycloak label
added keycloak-p1-auth-plugin label
added teamService Mesh label
added triage-priority label
@zacw from P1 CNAP team might have some insight on this.
Hey guys, thanks for everyone's patience on this. I was finally able to carve out some time this evening to look at the issue at the code level. From everyone's feedback it appears we might have an issue with our OCSP check we introduced in 3.3.0 to address the activecac attribute getting set with a user that attempts a CAC login that fails OCSP check, but still proceeds to login via user/pw from the same session. This new feature was tested in Keycloak Proxy mode behind Istio, so my suspicion is that Istio might be adding the chain in to the XFCC header that Keycloak looks at in proxy mode, but this does not appear to happen when Keycloak is in edge/passthrough mode, so when certain browsers don't provide the full chain we hit this error.
The two solutions discussed were:
- Toggle this feature off via config (Pending)
- Check against the Keycloak truststore if the httpRequest does not include the chain "X509Certificate[] certs = provider.getCertificateChain(httpRequest);"
I updated the plugin code in a new branch with solution 2 implemented. This means make sure your truststore is complete and loaded, which goes without saying when using CAC.
I don't have a CAC so I can't test, but I pushed it to a container for testers. I did load it in our P1/CNAP staging cluster and it loaded fine, but staging is behind Istio proxy mode, so this was more to confirm it loaded and didn't blow up anything. Once we confirm this works we will add the needed test code coverage and get it pushed to IB.
Code changes - https://repo1.dso.mil/big-bang/product/plugins/keycloak-p1-auth-plugin/-/commit/ 5853f766e4f4ddbcdee62d2035d4179df2adb98b Container - registry.dso.mil/big-bang/product/packages/keycloak/cnap-keycloak/p1-keycloak-plugin:3.3.1-1-beta
@kevin.wilder @ryan.j.garcia @jrb @llahoz
-
I wonder if the truststore.jks needs to be updated with new DoD CA certs. With Linux Ubuntu CAC authentication I see this in the logs
2024-04-04 16:16:33,919 ERROR [dod.p1.keycloak.registration.X509Tools] (executor-thread-50) No trusted CA in certificate found: CN=DOD ID CA-65, OU=PKI, OU=DoD, O=U.S. Government, C=US. Add it to truststore SPI if valid.Mac might not be as forgiving.
Just to add content here from our testing together @kevin.wilder, we have 2 Mac users that it does work for on your dev Keycloak, so we will wait for your feedback once your Mac users re-test with your updated truststore dev Keycloak. Luis on our team will also test himself (Mac User) on his own dev Keycloak and once we get a confirmation we will work to push it into IB.
-
My team has tested Zac's beta plugin from Mac and the CAC authentication is working.
I had to create a new DoD CA cert truststore.jks for my deployment. The one provided in the bigbang keycloak helm chart is a year old and does not work on Mac for users with new CACs.
This is where the old one is in the keycloak helm chart
https://repo1.dso.mil/big-bang/product/packages/keycloak/-/blob/main/chart/resources/dev
This is how to create a new one
https://repo1.dso.mil/big-bang/product/packages/keycloak/-/tree/main/scripts/certs#create-a-clean-dod-ca-pem-bundle-file-without-expired-certs
https://repo1.dso.mil/big-bang/product/packages/keycloak/-/tree/main/scripts/certs#create-a-java-truststorejks
This is how to override the old bigbang truststore and deploy your own updated truststore.jkscat truststore.jks | base64 -w 0 > truststore-base64.txtcopy the single-line base64 encoded text and paste it into your bigbang values override config
addons: keycloak: values: secrets: truststore: data: truststore.jks: |- xxxxxxxxxxx...or a cleaner way would be to create your own k8s secret and point your extra volume mount to the secret
addons: keycloak: values: extraVolumes: |- - name: truststore secret: secretName: my-truststore-secretEdited by kevin.wilder -
There is still an error in the logs from the OCSP check
2024-04-04 19:37:12,749 ERROR [dod.p1.keycloak.registration.X509Tools] (executor-thread-17) No trusted CA in certificate found: CN=DOD ID CA-70, OU=PKI, OU=DoD, O=U.S. Government, C=US. Add it to truststore SPI if valid.Not sure if there is a plan to fix that.
-
@kevin.wilder do you still have access to create an MR? I went through the DOD certs and truststore process the other week but the script kept failing and couldn't tell if there were any actual changes
-
I created an issue but I don't have developer access to create an MR.
#146 (closed) -
Note: CNAP team has plans to fix the OCSP check error that shows in the logs. Not sure on the turnaround time.
2024-04-04 19:37:12,749 ERROR [dod.p1.keycloak.registration.X509Tools] (executor-thread-17) No trusted CA in certificate found: CN=DOD ID CA-70, OU=PKI, OU=DoD, O=U.S. Government, C=US. Add it to truststore SPI if valid. -
@kevin.wilder @jrb can you test with
23.0.7-bb.3tag just created to address the defaulttruststore.jksthat is shipped with the package.I believe we will also have an accompanying p1-auth-plugin release here soon
changed iteration to Big Bang Iterations Apr 2, 2024 - Apr 15, 2024
added priority3 label and removed triage-priority label
assigned to @ryan.j.garcia
added statusdoing label
The fix now supports toggling the feature on/off. By default it will be off.
To enable:
via command arg: "--spi-baby-yoda-ocsp-enabled=true" or via ENV: KC_SPI_BABY_YODA_OCSP_ENABLED: "true" These also need to be set so the code can find the truststore when the bundle isn't presented by CAC: KC_SPI_TRUSTSTORE_FILE_FILE: "/opt/keycloak/certs/truststore.jks" KC_SPI_TRUSTSTORE_FILE_PASSWORD: "trust_pw"Fix repo - https://repo1.dso.mil/big-bang/product/plugins/keycloak-p1-auth-plugin/-/tree/zacw/fix-ocsp-check?ref_type=heads Fix container - registry.dso.mil/big-bang/product/packages/keycloak/cnap-keycloak/p1-keycloak-plugin:3.3.1-3-beta
I can't fully test as I don't have a revoked CAC or active CAC, but hopefully this is good to go. We will wait for confirmation from testers before moving forward though.
Edited by Zachary Williamson-
I just ran some tests with
registry.dso.mil/big-bang/product/packages/keycloak/cnap-keycloak/p1-keycloak-plugin:3.3.1-3-beta. I think this probably still isn't functioning quite the way you intended.When OCSP checking is enabled and the issuer certificate can't be found, the OCSP check is skipped, and user registration is still allowed to continue. I would expect that when OCSP checking is enabled, failure to find the issuer certificate would behave the same as a failed OCSP check, blocking user registration.
Here are the three tests I ran. I strongly suggest writing unit tests for these conditions.
PASS Test OCSP checking disabled and no trust store set.
Environment variables:
- KC_SPI_BABY_YODA_OCSP_ENABLED unset
- KC_SPI_TRUSTSTORE_FILE_FILE unset
- KC_SPI_TRUSTSTORE_FILE_PASSWORD unset
Expected behavior:
- Keycloak will not attempt to find my issuer certificate.
- Keycloak will not attempt OCSP checking.
- I will be able to register.
Actual behavior:
- PASS Keycloak did not attempt to find my issuer certificate.
- PASS Keycloak did not attempt OCSP checking.
- PASS I was able to register.
Logs
2024-04-12 15:10:02,193 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-2) ZacsOCSPProvider Mode Set: false 2024-04-12 15:10:02,202 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-2) P1_X509_TOOLS_GET_X509_IDENTITY_FROM_CHAIN_5dff3e80-327b-40a2-9af3-e67bdb8dad0c checking cert policy 2.16.840.1.101.2.1.11.42 2024-04-12 15:10:02,376 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-2) ZacsOCSPProvider Mode Set: false 2024-04-12 15:10:02,377 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-2) P1_X509_TOOLS_GET_X509_IDENTITY_FROM_CHAIN_5dff3e80-327b-40a2-9af3-e67bdb8dad0c checking cert policy 2.16.840.1.101.2.1.11.42FAIL Test OCSP checking enabled, but trust store is not set.
Environment variables:
- KC_SPI_BABY_YODA_OCSP_ENABLED: "true"
- KC_SPI_TRUSTSTORE_FILE_FILE: unset
- KC_SPI_TRUSTSTORE_FILE_PASSWORD unset
Expected behavior:
- Keycloak will be unable to find my issuer certificate.
- OCSP checking will be attempted and ultimately fail because my issuer certificate is not present.
- I will be unable to register.
Actual behavior:
- PASS Keycloak was unable to find my issuer certificate.
- FAIL OCSP checking did not occur.
- FAIL I was still able to register.
Logs
2024-04-12 14:19:39,354 WARN [org.keycloak.services] (executor-thread-4) KC-SERVICES0091: Request is missing scope 'openid' so it's not treated as OIDC, but just pure OAuth2 request. 2024-04-12 14:19:39,367 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-4) ZacsOCSPProvider Mode Set: true 2024-04-12 14:19:39,375 WARN [dod.p1.keycloak.registration.X509Tools] (executor-thread-4) P1_X509_TOOLS_GET_X509_IDENTITY_FROM_CHAIN_07aa2456-eed9-4667-993a-148659f900c1 No trusted CA in certificate found: CN=DOD ID CA-64, OU=PKI, OU=DoD, O=U.S. Government, C=US 2024-04-12 14:19:39,376 INFO [dod.p1.keycloak.registration.X509Tools] (executor-thread-4) ZacsOCSPProvider Mode Set: true 2024-04-12 14:19:39,376 WARN [dod.p1.keycloak.registration.X509Tools] (executor-thread-4) P1_X509_TOOLS_GET_X509_IDENTITY_FROM_CHAIN_07aa2456-eed9-4667-993a-148659f900c1 No trusted CA in certificate found: CN=DOD ID CA-64, OU=PKI, OU=DoD, O=U.S. Government, C=USPASS Test OCSP checking enabled, and trust store variables are set.
Environment variables:
- KC_SPI_BABY_YODA_OCSP_ENABLED: "true"
- KC_SPI_TRUSTSTORE_FILE_FILE: "/opt/keycloak/conf/truststore.jks"
- KC_SPI_TRUSTSTORE_FILE_PASSWORD: "password"
Expected behavior:
- Keycloak will be able to find my issuer certificate.
- OCSP checking will occur and succeed.
- I will be able to register, because OCSP checking was able to complete successfully.
Actual behavior:
- PASS Keycloak was able to find my issuer certificate
- PASS OCSP checking occurred and succeeded.
- PASS I was able to register.
Logs are available upon request.
Edited by Jonathan Braswell
mentioned in issue big-bang/product/plugins/keycloak-p1-auth-plugin#49 (closed)
removed iteration Big Bang Iterations Apr 2, 2024 - Apr 15, 2024
changed iteration to Big Bang Iterations Apr 16, 2024 - Apr 29, 2024
unassigned @ryan.j.garcia
added statusready-to-work label and removed statusdoing label
mentioned in merge request big-bang/customers/template!81 (merged)
assigned to @cwilliams68067
unassigned @cwilliams68067
Not sure if you have access, but you can test the new update here... https://sso.dso.mil/
The CAC Auth issue seems to have been solved by Zac Williamson. Some had issues with their CAC on 3.3.0 but it is working on CNAPs 3.3.1-3-beta image -- closing this issue.
Edited by Wyatt Frymentioned in merge request big-bang/product/plugins/keycloak-p1-auth-plugin!53 (closed)
Re-opening this issue, since the official 3.3.1 plugin has not been fully tested and rolled out.
I hit this testing SSO on Linux yesterday. Hacking the plugin, I saw the full chain wasn't being sent. @jrb pointed me to this existing issue -- glad it was a known issue.
@luis.lahoz I'll test the changes on your
Keycloak P1 Auth Plugin Keycloak P1 Auth Plugin/fix-ocsp-checkbranch and review the code too.I can verify on Linux. Looks like @jrb can verify on MAC.
- Linux / Firefox --> Intermediate passed through if loaded into Firefox
- Linux / Chrome --> Intermediate NOT passed through even if loaded
- Windows / ? --> Passed Through
SOLUTION
I found out Firefox was NOT passing the Issuer, because the issuer wasn't trusted. When I loaded in the DODIDCA_63.cer (the Authority for my cert) into Firefox, the intermediate issuer was passed through, and I hit the registration page.
Chrome on Linux still doesn't pass the intermediate cert.
@kevin.wilder @jrb can you test the existing 3.3.0 and verify the CA is loaded/recognized as an authority in your browser -- if you're using Firefox.
Edited by Michael Martin
mentioned in merge request !146 (merged)
mentioned in issue #119 (closed)
-
Just synced up with @michaelmartin and @zacw. We determined the fix in
registry.dso.mil/big-bang/product/packages/keycloak/cnap-keycloak/p1-keycloak-plugin:3.3.1-3-betais working as intended.- The auth plugin is correctly performing an OCSP check when the issuer cert is found in the trust store.
- When the issuer cert is not found in the trust store, it's correctly creating the user without the
activecacattribute.
What do we need to do to push this across the finish line?
mentioned in issue #176 (closed)
marked this issue as blocking #176 (closed)
mentioned in merge request !211 (merged)
mentioned in merge request big-bang/customers/template!82 (merged)
-
@luis.lahoz is there something the service mesh team can do to help this one along?
@luis.lahoz I don't have access to the code.il2 link you provided above. Can you confirm the new tag version? I think we may need to create an issue for IB to publish the corresponding image, which I will do once you confirm the version.
-
Thanks. The latest image I see in IB is 3.3.0, and I see an issue was created to get it there. I am going to create one for 3.3.3.
-
I created dsop/big-bang/p1-keycloak-plugin#36 (closed) to get this into IB.
added statusdoing label and removed statusready-to-work label
added statusblocked label and removed statusdoing label
-
Hi Fellas. You need to do more than just open an Iron Bank issue. Iron Bank does not own the container hardening project, the Big Bang Team owns it. The detailed documentation was removed from the maintenance doc sometime in the past year, not sure why. I went back 1 year to an old release tag and found the steps. See step 19 here:
https://repo1.dso.mil/big-bang/product/packages/keycloak/-/blob/18.4.3-bb.0/docs/DEVELOPMENT_MAINTENANCE.md19. After all testing locally and k8s testing with a BigBang deployment has been completed publish an official plugin image in [IronBank](https://repo1.dso.mil/dsop/big-bang/p1-keycloak-plugin). The order that things should happen with BigBang MRs, BigBang release, and publishing plugin image in IronBank is still unclear. Brief instructions for IronBank pipeline maintenance: 1. The PartyBus IL2 MDO pipeline publishes the p1-keycloak-plugin-X.X.X.jar artifact back to the [P1 Keycloak Package Registry](https://repo1.dso.mil/big-bang/apps/product-tools/keycloak-p1-auth-plugin/-/packages). If PartyBus IL2 MDO pipeline is failing for reasons outside of our control, worst case, we can [manualy publish](https://docs.gitlab.com/ee/user/packages/generic_packages/) to the plugin package registry. The BigBang MR will need the `tests/test-values.yaml` updated to use the new plugin init-container tag. The test values can use the image that was created in Big Bang Keycloak plugin container registry](https://repo1.dso.mil/big-bang/apps/product-tools/keycloak-p1-auth-plugin/container_registry/). There is no hard requirement to use the IronBank plugin image for the test values. 2. At the [IronBank repo](https://repo1.dso.mil/dsop/big-bang/p1-keycloak-plugin) create a new issue with template "application update" 3. Create a branch and MR from the issue. 4. update hardening_manifest.yaml - the tag version - the label org.opencontainers.image.version - resources.url - resources.validation.value (use sha256sum to get the hash value of the jar file) 5. commit and push code changes 6. Verify that pipline passes 7. Complete checkbox items in the issue. You will need to request [VAT](https://vat.dso.mil/) "Vendor Contributor" access if there are any new findings that need justification. 8. Mark the MR as ready and apply label "Hardening:Review" to the MR and the issue. 9. Monitor the issue to make sure it keeps moving with the Container Hardening Team(CHT).The sha256 hash can be found on this page
https://repo1.dso.mil/big-bang/product/plugins/keycloak-p1-auth-plugin/-/packages/1747
Here is an old closed MR example
dsop/big-bang/p1-keycloak-plugin!22 (diffs)You got this!
Edited by kevin.wilder -
Appreciate the info @kevin.wilder! Looking into this.
removed statusblocked label
added statusdoing label
assigned to @sarnowski-unicorn
-
Blocked waiting on 3.3.3 image being merged to master: dsop/big-bang/p1-keycloak-plugin!37 (merged)
added statusblocked label and removed statusdoing label
added statusdoing label and removed statusblocked label
mentioned in merge request big-bang/bigbang!4521 (merged)
added statusreview label and removed statusdoing label
closed with merge request big-bang/bigbang!4521 (merged)
mentioned in commit big-bang/bigbang@6600552b
mentioned in issue #201 (closed)
mentioned in issue #207 (closed)
mentioned in issue #217 (closed)
