This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
The following commit(s) were added to refs/heads/trunk by this push:
new 3ebe5debb7 Documented: Cross-domains Single Sign On (SSO)
3ebe5debb7 is described below
commit 3ebe5debb7305c02b5ca9fb3556ac47f0ec18cf9
Author: Jacques Le Roux <jacques.le.r...@les7arts.com>
AuthorDate: Fri Feb 2 12:06:25 2024 +0100
Documented: Cross-domains Single Sign On (SSO)
The feature is no longer available OOTB.
There are ways to make it available as explained at bottom of
https://issues.apache.org/jira/browse/OFBIZ-11594.
---
.../asciidoc/_include/wa-cross-domains-SSO.adoc | 51 +++++++++++++---------
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git
a/framework/webapp/src/docs/asciidoc/_include/wa-cross-domains-SSO.adoc
b/framework/webapp/src/docs/asciidoc/_include/wa-cross-domains-SSO.adoc
index 73547aea4a..b5d76ea7f1 100644
--- a/framework/webapp/src/docs/asciidoc/_include/wa-cross-domains-SSO.adoc
+++ b/framework/webapp/src/docs/asciidoc/_include/wa-cross-domains-SSO.adoc
@@ -18,18 +18,28 @@ under the License.
////
= Cross-domains Single Sign On (SSO)
-In some cases you need to split the OFBiz applications on different servers,
and possibly in production on different domains.
+[IMPORTANT]
+====
+As more explained at bottom of
https://issues.apache.org/jira/browse/OFBIZ-11594, the introduction of "the
SameSite attribute set to 'strict' for all cookies"
+with https://issues.apache.org/jira/browse/OFBIZ-11470 prevents the internal
Single Sign On feature.
+
+There are ways to make it available as explained at bottom of
https://issues.apache.org/jira/browse/OFBIZ-11594. It's not implemented OOTB
+
+====
+
+
+In some cases you need to split the OFBiz applications on different servers,
and possibly in production on different domains.
This can happen for different reasons, most often for performance reason.
-As it's annoying to give each time a credential when changing from an OFBiz
application to another on the same server,
-the same applies when changing from an OFBiz application to another on another
domain.
+As it's annoying to give each time a credential when changing from an OFBiz
application to another on the same server,
+the same applies when changing from an OFBiz application to another on another
domain.
-To prevent that on the same server, the ExternalLoginKey mechanism is used.
+To prevent that on the same server, the ExternalLoginKey mechanism is used.
The cross-domains SSO feature allows to navigate from a domain to another with
automated SSO.
-It based on 3 technologies:
+It based on 3 technologies:
-JWT:: https://jwt.io/[JWT Official site] -
+JWT:: https://jwt.io/[JWT Official site] -
https://en.wikipedia.org/wiki/JSON_Web_Token[Wikipedia for JWT]
CORS:: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS[CORS (Mozilla
doc)] - https://en.wikipedia.org/wiki/Cross-origin_resource_sharing[Wikipedia
for CORS]
@@ -39,29 +49,29 @@ Ajax:: Ajax, now well known I guess, in OFBiz we use jQuery
for that.
The mechanism is simple.
.On the source side:
-. When an user log in in an application (webApp) a webappName.securedLoginId
cookie is created.
-This cookie will be used by the mechanism to know the current logged in user.
-_Note that all webappName.securedLoginId cookies are deleted when the user
session is closed or time out.
-Hence (apart also using an intrinsically secured cookie) the mechanim is
secured, even on shared machines.
-Of course if people are sharing a machine during their sessions, things could
get complicated.
+. When an user log in in an application (webApp) a webappName.securedLoginId
cookie is created.
+This cookie will be used by the mechanism to know the current logged in user.
+_Note that all webappName.securedLoginId cookies are deleted when the user
session is closed or time out.
+Hence (apart also using an intrinsically secured cookie) the mechanim is
secured, even on shared machines.
+Of course if people are sharing a machine during their sessions, things could
get complicated.
This unlikely later case is not taken in account._
-. The user is given a JavaScript link which passes the URL to reach and the
calling webapp name to
+. The user is given a JavaScript link which passes the URL to reach and the
calling webapp name to
the sendJWT() Ajax function.
-. The sendJWT() Ajax function calls the loadJWT() Ajax function which in turn
calls
+. The sendJWT() Ajax function calls the loadJWT() Ajax function which in turn
calls
the CommonEvents::loadJWT method through the common controller.
-. The CommonEvents::loadJWT method uses the calling webapp name to retrieve
the userLoginId from the secured
+. The CommonEvents::loadJWT method uses the calling webapp name to retrieve
the userLoginId from the secured
webappName.securedLoginId cookie, creates a JWT containing the userLoginId,
and returns it to the loadJWT() Ajax function.
-. Then the sendJWT() Ajax function sends an Authorization header containing
the JWT to the URL to reach.
+. Then the sendJWT() Ajax function sends an Authorization header containing
the JWT to the URL to reach.
At this stage, if all things are correct, the flow leaves the source side.
.On the server side:
-. A CORS policy is needed. _Without it, the Authorization token containing the
JWT will be rejected.
-It's a simple policy but you need to strictly define the authorized domains.
Never use the lazy "*" for domains
-(ie all domains), else the
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example[preflight
request] will not work._
+. A CORS policy is needed. _Without it, the Authorization token containing the
JWT will be rejected.
+It's a simple policy but you need to strictly define the authorized domains.
Never use the lazy "*" for domains
+(ie all domains), else the
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Preflight_example[preflight
request] will not work._
Here is an example for Apache HTTPD (domain value is "https://localhost:8443";
for official OFBiz demo):
[source,]
@@ -71,11 +81,12 @@ Header set Access-Control-Allow-Headers "Authorization"
Header set Access-Control-Allow-Credentials "true"
----
-. The checkJWTLogin preprocessor, similar to the checkExternalLoginKey,
intercepts the JWT, checks it and
+. The checkJWTLogin preprocessor, similar to the checkExternalLoginKey,
intercepts the JWT, checks it and
if all is OK signs the user on. That's it !
-In the example component, the FormWidgetExamples screen contains 2 new fields
in the LinksExampleForm which
+In the example component, the FormWidgetExamples screen contains 2 new fields
in the LinksExampleForm which
demonstrate the use from a local instance to the trunk demo instance.
If you are interested in more details you may refer to
https://issues.apache.org/jira/browse/OFBIZ-10307
+
