[ https://issues.apache.org/jira/browse/OFBIZ-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16593433#comment-16593433 ]
Jacques Le Roux commented on OFBIZ-10307: ----------------------------------------- I also forgot to put above https://github.com/auth0/java-jwt#using-a-keyprovider. I already mentioned it in OFBIZ-9833 at "20/Feb/18 18:02". But that would mean to not use a secret key (HMAC algorithm) as OFBIZ-9833 currently does. And I'm not sure it's better, did not check, just another option... > 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, 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]]. > # 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 (v7.6.3#76005)