10:33 a.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>
1:06 p.m.
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.
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.
On 8 March 2016 at 17:33, Jason Axley <jaxley(a)expedia.com> wrote:
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>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:43 p.m.
+1 on what Stian said.
Plus, I don't see why the same could not be achieved/configured on WildFly
for example. Security is a process, not a product. People willing to secure
their systems, must stick with a set of best practices for Web
Applications, OS and etc.
If we start to think that everything should be secure by default, 100% of
the servers outside, should already come with Firewall enabled, Honeypots
and SELinux policies enabled. But they won't do that. Why? Because it's up
to the sysadmin to have the security awareness, to evaluate the network,
decided whether their users should set strong or weak passwords.
On Tue, Mar 8, 2016 at 4:06 PM Stian Thorgersen <sthorger(a)redhat.com> wrote:
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.
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.
On 8 March 2016 at 17:33, Jason Axley <jaxley(a)expedia.com> wrote:
> 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>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:59 p.m.
If sysadmins should be responsible, then why not put the responsibility squarely in the
lap of the ops/sysadmins then and make the app secure by default so they have to overtly
and knowingly make it insecure rather than happily running an app they won’t know is
insecure unless they happen to stumble upon some dusty corner of the documentation?
This is 2016 – we should not be building apps that are not secure and punting to sysadmins
to fix them – that is a failed model that results in insecure defaults in production
deployments in practice.
Do you agree that if Keycloak was writing the cookies itself then Keycloak should ensure
secure and HttpOnly cookies for the security session?
-Jason
From: Bruno Oliveira <bruno@abstractj.org<mailto:bruno@abstractj.org>>
Date: Tuesday, March 8, 2016 at 11:43 AM
To: "stian@redhat.com<mailto:stian@redhat.com>"
<stian@redhat.com<mailto:stian@redhat.com>>, Jason Axley
<jaxley@expedia.com<mailto:jaxley@expedia.com>>
Cc: "keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>"
<keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>>
Subject: Re: [keycloak-user] JSESSIONID is not set with the Secure nor HttpOnly flag
+1 on what Stian said.
Plus, I don't see why the same could not be achieved/configured on WildFly for
example. Security is a process, not a product. People willing to secure their systems,
must stick with a set of best practices for Web Applications, OS and etc.
If we start to think that everything should be secure by default, 100% of the servers
outside, should already come with Firewall enabled, Honeypots and SELinux policies
enabled. But they won't do that. Why? Because it's up to the sysadmin to have the
security awareness, to evaluate the network, decided whether their users should set strong
or weak passwords.
On Tue, Mar 8, 2016 at 4:06 PM Stian Thorgersen
<sthorger@redhat.com<mailto:sthorger@redhat.com>> wrote:
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.
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.
On 8 March 2016 at 17:33, Jason Axley
<jaxley@expedia.com<mailto:jaxley@expedia.com>> wrote:
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<tel:425-679-4157> (o) | 206-484-2778<tel: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>
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:25 p.m.
On 8 March 2016 at 20:59, Jason Axley <jaxley(a)expedia.com> wrote:
If sysadmins should be responsible, then why not put the
responsibility
squarely in the lap of the ops/sysadmins then and make the app secure by
default so they have to overtly and knowingly make it insecure rather than
happily running an app they won’t know is insecure unless they happen to
stumble upon some dusty corner of the documentation?
This is 2016 – we should not be building apps that are not secure and
punting to sysadmins to fix them – that is a failed model that results in
insecure defaults in production deployments in practice.
To some extent I agree. However, it's not as simple as improve default
settings and you are somehow magically secure. Security settings are also
very environment specific and some can't even be included by default (for
example SSL).
Do you agree that if Keycloak was writing the cookies itself then Keycloak
should ensure secure and HttpOnly cookies for the security session?
Yes, if Keycloak was creating the cookie then we would set http only and
set the secure field based on our ssl-required policy. It's created by the
container so defaults come from there, I don't uderstand http only isn't
set by default though. What container are you using? Maybe you can send a
issue their way?
-Jason
From: Bruno Oliveira <bruno(a)abstractj.org>
Date: Tuesday, March 8, 2016 at 11:43 AM
To: "stian(a)redhat.com" <stian(a)redhat.com>, Jason Axley
<jaxley(a)expedia.com
>
Cc: "keycloak-user(a)lists.jboss.org" <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] JSESSIONID is not set with the Secure nor
HttpOnly flag
+1 on what Stian said.
Plus, I don't see why the same could not be achieved/configured on WildFly
for example. Security is a process, not a product. People willing to secure
their systems, must stick with a set of best practices for Web
Applications, OS and etc.
If we start to think that everything should be secure by default, 100% of
the servers outside, should already come with Firewall enabled, Honeypots
and SELinux policies enabled. But they won't do that. Why? Because it's up
to the sysadmin to have the security awareness, to evaluate the network,
decided whether their users should set strong or weak passwords.
On Tue, Mar 8, 2016 at 4:06 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> 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.
>
> 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.
>
> On 8 March 2016 at 17:33, Jason Axley <jaxley(a)expedia.com> wrote:
>
>> 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>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
3227
days inactive
3228
days old
4 comments
3 participants
participants (3)
-
Bruno Oliveira -
Jason Axley -
Stian Thorgersen