[jira] [Comment Edited] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[
https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592527#comment-16592527
]
Jacques Le Roux edited comment on OFBIZ-10307 at 8/25/18 9:10 AM:
--
Hi Jacopo,
You wrote:
bq. As regards this task, it is really difficult to make some sense out of the
many comments (17 only by Jacques) posted in this ticket.
Something I'll do, before - as I said already - maybe creating a graph in
AsciiDoc, is to concisely document the way it's done and how it's supposed to
work.
About
bq. As regards the mechanism to store the token secret key, a plain text file
may be enough initially because the file can be secured by properly assigning
grants using the operating system (e.g. similarly to what is done in every
production setup for the entityengine.xml);
I agree, and
bq. in a second phase we could consider to leverage the Java Key Store that is
also used by the "catalina" component to store certificates.
There are several *safe ways* to store a secret key, I already commented about
that in OFBIZ-9833^[#0]^. The Java Key Store is indeed a one of them. Like most
others, it also has it limits that our users should be aware of ^[#1]^ ^[#2]^.
Anyway, my point is we should rather only suggest our users to use one of the
safe ways to store a secret key. So they can then pick the one which fits them
most. We know security is continously evolving. Better to not get stuck which
something which will maybe not be secure anymore in few years, and let users
decide for themselves consciously.
So we could simply keep the properties, as is now, OOTB and suggest other
possibilities, like:
*
https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key
*
https://stackoverflow.com/questions/37972285/how-to-safely-store-process-secret-key-for-jwt
** https://en.wikipedia.org/wiki/Hardware_security_module
*
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key
* https://dzone.com/articles/secret-rotation-for-jwt-tokens-1
I also found this article interesting:
https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
+Refs:+
[0] {anchor:0} https://s.apache.org/kaph
[1] {anchor:1}
https://cryptosense.com/blog/mighty-aphrodite-dark-secrets-of-the-java-keystore/
[2] {anchor:2}
https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/
was (Author: jacques.le.roux):
Hi Jacopo,
You wrote:
bq. As regards this task, it is really difficult to make some sense out of the
many comments (17 only by Jacques) posted in this ticket.
Something I'll do, before - as I said already - maybe creating a graph in
AsciiDoc, is to concisely document the way it's done and how it's supposed to
work.
About
bq. As regards the mechanism to store the token secret key, a plain text file
may be enough initially because the file can be secured by properly assigning
grants using the operating system (e.g. similarly to what is done in every
production setup for the entityengine.xml);
I agree, and
bq. in a second phase we could consider to leverage the Java Key Store that is
also used by the "catalina" component to store certificates.
There are several *safe ways* to store a secret key, I already commented about
that in OFBIZ-9833^[#0]^. The Java Key Store is indeed a one of them. Like most
others, it also has it limits that our users should be aware of ^[#1]^ ^[#2]^.
Anyway, my point is we should rather only suggest our users to use one of the
safe ways to store a secret key. So they can then pick the one which fits them
most. We know security is continously evolving. Better to not get stuck which
something which will maybe not be secure anymore in few years, and let users
decide for themselves consciously.
So we could simply keep the properties, as is now, OOTB and suggest other
possibilities, like:
*
https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key
*
https://stackoverflow.com/questions/37972285/how-to-safely-store-process-secret-key-for-jwt
** https://en.wikipedia.org/wiki/Hardware_security_module
*
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key
* https://dzone.com/articles/secret-rotation-for-jwt-tokens-1
I also found this article interesting:
https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
+Refs:+
[0] {anchor:0} https://s.apache.org/kaph
[1] {anchor:1}
https://cryptosense.com/blog/mighty-aphrodite-dark-secrets-of-the-java-keystore/
[3] {anchor:2}
https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/
> Navigate from a domain to another with automated signed in authentication
> -
>
> Key: OFBIZ-10307
>
[jira] [Comment Edited] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[
https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592527#comment-16592527
]
Jacques Le Roux edited comment on OFBIZ-10307 at 8/25/18 9:10 AM:
--
Hi Jacopo,
You wrote:
bq. As regards this task, it is really difficult to make some sense out of the
many comments (17 only by Jacques) posted in this ticket.
Something I'll do, before - as I said already - maybe creating a graph in
AsciiDoc, is to concisely document the way it's done and how it's supposed to
work.
About
bq. As regards the mechanism to store the token secret key, a plain text file
may be enough initially because the file can be secured by properly assigning
grants using the operating system (e.g. similarly to what is done in every
production setup for the entityengine.xml);
I agree, and
bq. in a second phase we could consider to leverage the Java Key Store that is
also used by the "catalina" component to store certificates.
There are several *safe ways* to store a secret key, I already commented about
that in OFBIZ-9833^[#0]^. The Java Key Store is indeed a one of them. Like most
others, it also has it limits that our users should be aware of ^[#1]^ ^[#2]^.
Anyway, my point is we should rather only suggest our users to use one of the
safe ways to store a secret key. So they can then pick the one which fits them
most. We know security is continously evolving. Better to not get stuck which
something which will maybe not be secure anymore in few years, and let users
decide for themselves consciously.
So we could simply keep the properties, as is now, OOTB and suggest other
possibilities, like:
*
https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key
*
https://stackoverflow.com/questions/37972285/how-to-safely-store-process-secret-key-for-jwt
** https://en.wikipedia.org/wiki/Hardware_security_module
*
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key
* https://dzone.com/articles/secret-rotation-for-jwt-tokens-1
I also found this article interesting:
https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
+Refs:+
[0] {anchor:0} https://s.apache.org/kaph
[1] {anchor:1}
https://cryptosense.com/blog/mighty-aphrodite-dark-secrets-of-the-java-keystore/
[3] {anchor:2}
https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/
was (Author: jacques.le.roux):
Hi Jacopo,
You wrote:
bq. As regards this task, it is really difficult to make some sense out of the
many comments (17 only by Jacques) posted in this ticket.
Something I'll do, before - as I said already - maybe creating a graph in
AsciiDoc, is to concisely document the way it's done and how it's supposed to
work.
About
bq. As regards the mechanism to store the token secret key, a plain text file
may be enough initially because the file can be secured by properly assigning
grants using the operating system (e.g. similarly to what is done in every
production setup for the entityengine.xml);
I agree, and
bq. in a second phase we could consider to leverage the Java Key Store that is
also used by the "catalina" component to store certificates.
There are several *safe ways* to store a secret key, I already commented about
that in OFBIZ-9833^[#0]^. The Java Key Store is indeed a one of them. Like most
others, it also has it limits that our users should be aware of ^[#1]^ ^[#2]^.
Anyway, my point is we should rather only suggest our users to use one of the
safe ways to store a secret key. So they can then pick the one which fits them
most. We know security is continously evolving. Better to not get stuck which
something which will maybe not be secure anymore in few years, and let users
decide for themselves consciously.
So we could simply keep the properties, as is now, OOTB and suggest other
possibilities, like:
*
https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key
*
https://stackoverflow.com/questions/37972285/how-to-safely-store-process-secret-key-for-jwt
** https://en.wikipedia.org/wiki/Hardware_security_module
*
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key
* https://dzone.com/articles/secret-rotation-for-jwt-tokens-1
I also found this article interesting:
https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
+Refs:+
{anchor:0} https://s.apache.org/kaph
{anchor:1}
https://cryptosense.com/blog/mighty-aphrodite-dark-secrets-of-the-java-keystore/
{anchor:2}
https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/
> Navigate from a domain to another with automated signed in authentication
> -
>
> Key: OFBIZ-10307
> URL: ht
[jira] [Commented] (OFBIZ-10307) Navigate from a domain to another with automated signed in authentication
[
https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592527#comment-16592527
]
Jacques Le Roux commented on OFBIZ-10307:
-
Hi Jacopo,
You wrote:
bq. As regards this task, it is really difficult to make some sense out of the
many comments (17 only by Jacques) posted in this ticket.
Something I'll do, before - as I said already - maybe creating a graph in
AsciiDoc, is to concisely document the way it's done and how it's supposed to
work.
About
bq. As regards the mechanism to store the token secret key, a plain text file
may be enough initially because the file can be secured by properly assigning
grants using the operating system (e.g. similarly to what is done in every
production setup for the entityengine.xml);
I agree, and
bq. in a second phase we could consider to leverage the Java Key Store that is
also used by the "catalina" component to store certificates.
There are several *safe ways* to store a secret key, I already commented about
that in OFBIZ-9833^[#0]^. The Java Key Store is indeed a one of them. Like most
others, it also has it limits that our users should be aware of ^[#1]^ ^[#2]^.
Anyway, my point is we should rather only suggest our users to use one of the
safe ways to store a secret key. So they can then pick the one which fits them
most. We know security is continously evolving. Better to not get stuck which
something which will maybe not be secure anymore in few years, and let users
decide for themselves consciously.
So we could simply keep the properties, as is now, OOTB and suggest other
possibilities, like:
*
https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key
*
https://stackoverflow.com/questions/37972285/how-to-safely-store-process-secret-key-for-jwt
** https://en.wikipedia.org/wiki/Hardware_security_module
*
https://security.stackexchange.com/questions/87130/json-web-tokens-how-to-securely-store-the-key
* https://dzone.com/articles/secret-rotation-for-jwt-tokens-1
I also found this article interesting:
https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/
+Refs:+
{anchor:0} https://s.apache.org/kaph
{anchor:1}
https://cryptosense.com/blog/mighty-aphrodite-dark-secrets-of-the-java-keystore/
{anchor:2}
https://neilmadden.wordpress.com/2017/11/17/java-keystores-the-gory-details/
> Navigate from a domain to another with automated signed in authentication
> -
>
> Key: OFBIZ-10307
> URL: https://issues.apache.org/jira/browse/OFBIZ-10307
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-10307-test from example.patch, OFBIZ-10307-test
> from example.patch, OFBIZ-10307-test.patch, OFBIZ-10307-test.patch,
> OFBIZ-10307-test.patch, OFBIZ-10307.patch, OFBIZ-10307.patch,
> OFBIZ-10307.patch, OFBIZ-10307.patch, OFBIZ-10307.patch
>
>
> This will use a JWT Token authentication to get from one domain, where you
> are signed in, to another domain where you get signed in automatically.
> Something like ExternalLoginKey or Tomcat SSO, but not on the same domain.
> This will build upon the initial work done at OFBIZ-9833 which has been
> partially reverted in trunk with r1827439 (see OFBIZ-10304) and r1827441. I
> explained why and what I did at [https://s.apache.org/a5Km]
> I turned to Ajax for the "Authorization" header sending. I initially thought
> I'd just pass an "Authorization" header and use it in the
> externalServerLoginCheck preprocessor, et voilà.
> But I stumbled upon something I did not know well : CORS! And in particular
> the upstream control (Pre-verified requests):
>
> [https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example]
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS]
> [https://www.w3.org/TR/cors/]
> To be able to pass an "Authorization" header, the server must respond
> positively in the Preflight HTTP response (OPTIONS). To do this, either you
> use a Tomcat filter (or your own filter, there are examples on the Net) or
> use HTTPD (or Nginx) configuration on the target server.
> I tried Tomcat first, without success. With HTTPD it's easier just 3 lines.
> For my tests, future tests by OFBiz users and as an example, I asked infra to
> put them in our HTTPD trunk demo config:
> Header set Access-Control-Allow-Origin "https://localhost:8443";
> Header set Access-Control-Allow-Headers "Authorization"
> Header set Access-Control-Allow-Credentials "true"
> No code change (either in all web.xml files for Tomcat or Java for own
> filter), and more
