Jacques Le Roux commented on OFBIZ-10307:

Currently the CORS demonstration in example component is useless. I'd like to 
commit [^OFBIZ-10307.patch] . What do you think?

> 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 from example.patch, 
> OFBIZ-10307-test.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, OFBIZ-10307.patch, 
> OFBIZ-10307.patch, OFBIZ-10307.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 safety. It does not give more right to outsiders than what 
> we give with the admin credential.
> In Header set Access-Control-Allow-Origin you can put more domains. I just 
> used [https://localhost:8443|https://localhost:8443/] for the tests.
> It works in Chrome, Firefox and Opera and partially in IE11 (not tested in 
> Edge). I did not test Safari, but I guess like other modern browsers it 
> should work.
>  For those (very few I guess) interested by IE11 (for Edge test yourself and 
> report please), here is the solution
> [https://stackoverflow.com/questions/12643960/internet-explorer-10-is-ignoring-xmlhttprequest-xhr-withcredentials-true]
> [https://web.archive.org/web/20130308142134/http://msdn.microsoft.com/en-us/library/ms537343%28v=vs.85%29.aspx]
> [https://blogs.msdn.microsoft.com/ieinternals/2013/09/17/a-quick-look-at-p3p/]
> TODO (maybe) in the future, use the new Fetch API (not available yet): 
> [https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API]
> ----
> Here is a complement about the way it's architectured:
>  # A change to cookies was introduced with OFBIZ-4959. Actually it was not 
> really a bug rather a clean-up. The autoLogin cookies were only used by the 
> ecommerce component and maybe webpos. But all applications were creating such 
> cookies with a one year duration. They were useless until I needed them for 
> the feature of this Jira issue. But even if they were safe (httponly) then I 
> needed them to be clean, not a one year duration (to be as safe as possible, 
> temporary cookies are better). So after doing it crudely, [inspired by 
> Taher's suggestion|https://s.apache.org/qLGC] I introduced the 
> keep-autologin-cookie <webapp> attribute in ofbiz-component.xml. It's used to 
> remove not kept cookies when login in or out. So those cookies are only kept 
> during a session. Also a cookie is created when an user jumps from one 
> application to another on the source domain. These cookies are used when 
> navigating from a domain to another to guarantee the safety of the user who 
> jumps from the source domain to the target domain. Note that protected 
> cookies (httponly) are one of the safer ways to store information, [js script 
> can't use 
> them|https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage]].
>  *Note: finally I add to use a more secure way and introduced 
> {{webappName.securedLoginId cookies}} to replace autoLogin cookies. They work 
> they same way but prevent a possible vulnerability. This is explained at the 
> bottom of this Jira.*
>  # To jump from a domain to another I use Ajax to send a JWT token in a HTTP 
> header (as recommended by CORS standard). The JWT token contains only the 
> userLoginId information.
>  # For authentication, I use the checkExternalServerLogin pre-processor in 
> the same vein than checkExternalLoginKey. It checks a JWT token is present in 
> the HTTP header of the request and if present uses the userLoginId to sign in 
> the user on the target domain. I must say that the devil is in the technical 
> details (of CORS) and I'll not explain that here.

This message was sent by Atlassian JIRA

Reply via email to