5:33 p.m.
Bringing this discussion from an open JIRA to the mailing list to have an open discussion
about the issue. Stian can join in to make sure his viewpoint is represented here. I’ll
try to summarize the discussion.
The Keycloak admin and account client applications do not currently use the Keycloak
adapters for authentication/authorization interception. They currently write their own
set of Keycloak cookies to manage the user’s security session. These applications do not
have any dependency on the J2EE session.
However, if applications make use of the Keycloak adapters as authentication/authorization
interceptors, those are currently written to not write separate Keycloak security session
cookies – they just repurpose the J2EE session (JSESSIONID). However, the adapters don’t
do any security configuration or checking or warning that the underlying J2EE session has
not been configured to be a Secure and HttpOnly cookie, meaning that Keycloak adapters are
all insecure by default. A design decision was made to say that security of that cookie
is out of scope for the adapters. There is a general concern about where the adapters
should draw the line between Keycloak security checking responsibility and the application
it is protecting.
I think there is a line that’s easy to draw – if Keycloak is using something for its needs
that it depends on being secure, then it has a responsibility to ensure that facility is
configured securely. If Keycloak was to write its own session ID cookie and not enforce
Secure and HttpOnly cookies, it would be clear that Keycloak would be negligible in not
securing the application to basic web application standards. I don’t think that a
decision to use the J2EE session absolves Keycloak from its security responsibilities.
There’s a saying that you can outsource the technology but you can’t outsource the risk.
I think especially as a security application, Keycloak has a duty to do the right thing
from a web app security perspective and ensure it is implementing all of the typical OWASP
top 10 and beyond security controls in the code it produces and depends on. Cookie
security is a basic building block for a secure web application.
There was a proposal to try to rely on the Documentation to warn anyone using the adapters
that they are essentially responsible for doing all of the web application security
configuration of the J2EE session, HTTPS, etc. However, time and time again, it has shown
that Documentation just doesn’t make up for the lack of secure defaults when you measure
the rate of compliance in the real world. Security is one of those orthogonal things
where the system can “work” but be completely insecure and operators and developers can be
completely unaware of this until a pen tester or attacker shows them they have not changed
the insecure default settings.
My proposal is that Keycloak application (including adapters) should have a secure design
philosophy of being secure-by-default and require explicit overrides to disable the secure
defaults. This will ensure that the system will be robust unless someone makes conscious
choices to degrade the security.
Thoughts?
-Jason
Jason Axley
Sr. Security Engineer, Expedia Worldwide Engineering Team
425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv)
333 108th Ave NE, 9S-282, Bellevue, WA 98004
EWE Security Wiki<https://confluence/display/POS/EWE+Security>