<div dir="ltr">Adding my point of view on this. Our JEE adapters are written to help users integrate with Keycloak to authenticate users, that's the scope of the adapters at the moment. We do not pretend to solve any OWASP top 10 or other general web security recommendations in users applications. In fact unless you enable SSL for your applications token security is completely insecure. I'd love it to be the case that we could extend the adapters to cover general web security to make JEE applications secured in a simple way, but we don't have enough resources for that and we'd rather focus our effort on providing adapters/integration for other programming languages and frameworks.<div><br></div><div>Further, the adapters can be configured to be stateless or use the regular JEE HTTP session. It's the container and the users responsibility to secure the HTTP session. You can make exactly the same argument that your are making towards Keycloak towards the JEE containers as well. They provide the HTTP session in the first place and as long as you don't enable SSL and secure the cookie it's not going to be secure. IMO it's better to try to educate than to try to magically fix it. Educating means that users will understand that they still need to review OWASP top 10 and other web security recommendations even if they are using Keycloak.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 March 2016 at 17:33, Jason Axley <span dir="ltr"><<a href="mailto:jaxley@expedia.com" target="_blank">jaxley@expedia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>However, if applications make use of the Keycloak adapters as authentication/authorization interceptors, those are currently written to
<span style="font-weight:bold">not</span> 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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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
<span style="font-weight:bold">in the code it produces and depends on</span>. Cookie security is a basic building block for a secure web application. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>
<div>
<div style="font-size:14px">
<div>-Jason</div>
</div>
<div style="font-size:14px"><br>
</div>
<div>
<p class="MsoNormal" style="font-size:11pt;margin:0in 0in 0.0001pt;background-color:white">
<b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(23,54,93)">Jason Axley</span></b></p>
<p class="MsoNormal" style="margin:0in 0in 0.0001pt;background-color:white"><span style="font-family:Arial,sans-serif;color:rgb(227,108,10)"><font size="2">Sr. Security Engineer, Expedia Worldwide Engineering Team<u></u><u></u></font></span></p>
<p class="MsoNormal" style="font-size:11pt;margin:0in 0in 0.0001pt"><span style="font-size:8pt;color:rgb(31,73,125)"><a href="tel:425-679-4157" value="+14256794157" target="_blank">425-679-4157</a> (o) | <a href="tel:206-484-2778" value="+12064842778" target="_blank">206-484-2778</a> (m) | 206-55-AXLEY (gv)<u></u><u></u></span></p>
<p class="MsoNormal" style="font-size:11pt;margin:0in 0in 0.0001pt"><span style="font-size:8pt;color:rgb(31,73,125)">333 108th Ave NE, 9S-282, Bellevue, WA 98004</span></p>
<p class="MsoNormal" style="font-size:11pt;margin:0in 0in 0.0001pt"><span style="font-size:8pt;color:rgb(31,73,125)"><a href="https://confluence/display/POS/EWE+Security" target="_blank">EWE Security Wiki</a></span></p>
</div>
</div>
</div>
</div>
<br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>