OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
Hi,

Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.

I asked for reviews but only Taher answered and he asked to know the goal of this new feature.

It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another 
server (on another domain) without having to sign up between the 2 while keeping things secure.

There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.

The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
authentication) because it's only for OFBiz instances of the same version.

To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.

For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.

It's now a long time (9 months) since I started this work. And my last patch is ready for a month.

I crossed several issues which are now all resolved. So please review and answer to this thread.

Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.

Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.

Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Shi Jinghai-3
Dear Jacques,

On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.

Mr. Dai Haipeng contributed a Redis component in Jira[4].

[1] https://redis.io/
[2] https://db-engines.com/en/ranking
[3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
[4] https://issues.apache.org/jira/browse/OFBIZ-9829

BTW, I'll try to review the patches.

Kind Regards,

Shi Jinghai

-----邮件原件-----
发件人: Jacques Le Roux [mailto:[hidden email]]
发送时间: 2018年8月15日 15:09
收件人: [hidden email]
主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Hi,

Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.

I asked for reviews but only Taher answered and he asked to know the goal of this new feature.

It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another 
server (on another domain) without having to sign up between the 2 while keeping things secure.

There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.

The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
authentication) because it's only for OFBiz instances of the same version.

To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.

For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.

It's now a long time (9 months) since I started this work. And my last patch is ready for a month.

I crossed several issues which are now all resolved. So please review and answer to this thread.

Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.

Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.

Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks

Jacques


Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

> Dear Jacques,
>
> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>
> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>
> [1] https://redis.io/
> [2] https://db-engines.com/en/ranking
> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>
> BTW, I'll try to review the patches.
>
> Kind Regards,
>
> Shi Jinghai
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月15日 15:09
> 收件人: [hidden email]
> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi,
>
> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>
> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>
> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
> server (on another domain) without having to sign up between the 2 while keeping things secure.
>
> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>
> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
> authentication) because it's only for OFBiz instances of the same version.
>
> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>
> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>
> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>
> I crossed several issues which are now all resolved. So please review and answer to this thread.
>
> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>
> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>
> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>
> Jacques
>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
In reply to this post by Jacques Le Roux
Le 15/08/2018 à 09:08, Jacques Le Roux a écrit :

> Hi,
>
> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>
> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>
> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another 
> server (on another domain) without having to sign up between the 2 while keeping things secure.
>
> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>
> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to 
> two-factor authentication) because it's only for OFBiz instances of the same version.
>
> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>
> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>
> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>
> I crossed several issues which are now all resolved. So please review and answer to this thread.
>
> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>
> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>
> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>
> Jacques
>
>
Hi,

Pierre Smits suggested I could do a graph.
Though I'm not too much inclined to that, I'll try to do one using http://asciidoc.org/asciidoc-graphviz-sample.html I'm so curious...

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
Le 16/08/2018 à 12:10, Jacques Le Roux a écrit :

> Le 15/08/2018 à 09:08, Jacques Le Roux a écrit :
>> Hi,
>>
>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>
>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>
>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another 
>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>
>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>
>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to 
>> two-factor authentication) because it's only for OFBiz instances of the same version.
>>
>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>
>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>
>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>
>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>
>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>
>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>
>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>
>> Jacques
>>
>>
> Hi,
>
> Pierre Smits suggested I could do a graph.
> Though I'm not too much inclined to that, I'll try to do one using http://asciidoc.org/asciidoc-graphviz-sample.html I'm so curious...
For myself to remember: https://asciidoctor.org/news/2014/02/18/plain-text-diagrams-in-asciidoctor/
>
> Jacques
>
>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Scott Gray-3
In reply to this post by Jacques Le Roux
Hi Jacques,

Assuming I was looking at the correct patch, it looks like I could use this
feature to login as anyone.  All I need to do is send any userLoginId to
getJwtToken and then I can login as that user with the token that comes
back.  Am I missing something?

Regards
Scott

On 15 August 2018 at 07:08, Jacques Le Roux <[hidden email]>
wrote:

> Hi,
>
> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>
> I asked for reviews but only Taher answered and he asked to know the goal
> of this new feature.
>
> It was actually developed for a client who needed to get from one OFBiz
> instance on a server (on a domain) to another OFBiz instance on another
> server (on another domain) without having to sign up between the 2 while
> keeping things secure.
>
> There could be many reasons why you want to split OFBiz application on
> servers. In their case it was for performance issues.
>
> The technology used is as secure as possible. Like OAuth 2.0 it uses a
> token but it does not need a middle authorization server (think to
> two-factor authentication) because it's only for OFBiz instances of the
> same version.
>
> To commit this work we need 1st to agree an commit the work done by Deepak
> at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>
> For me there is only one question outstanding: how to store the Token
> secret. But this should not prevent us to commit Deepak's work.
>
> It's now a long time (9 months) since I started this work. And my last
> patch is ready for a month.
>
> I crossed several issues which are now all resolved. So please review and
> answer to this thread.
>
> Without negative comments well argumented I'll commit both OFBIZ-9833 and
> OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>
> Also a veto on a commit is always possible... Of course, as ever, a good
> consensus is preferred.
>
> Let me know if you need more information about the goal. For the technical
> details I think I already provided them the in OFBIZ-10307.
>
> Jacques
>
>
Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Shi Jinghai-3
In reply to this post by Jacques Le Roux
Hi Jacques,

OK, I think the redis topic is jumped to next step.

I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?

[1] https://github.com/apereo/cas
[2] https://auth0.com/

Kind Regards,

Shi Jinghai


-----邮件原件-----
发件人: Jacques Le Roux [mailto:[hidden email]]
发送时间: 2018年8月16日 2:08
收件人: [hidden email]
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks

Jacques


Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

> Dear Jacques,
>
> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>
> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>
> [1] https://redis.io/
> [2] https://db-engines.com/en/ranking
> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>
> BTW, I'll try to review the patches.
>
> Kind Regards,
>
> Shi Jinghai
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月15日 15:09
> 收件人: [hidden email]
> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi,
>
> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>
> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>
> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
> server (on another domain) without having to sign up between the 2 while keeping things secure.
>
> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>
> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
> authentication) because it's only for OFBiz instances of the same version.
>
> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>
> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>
> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>
> I crossed several issues which are now all resolved. So please review and answer to this thread.
>
> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>
> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>
> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>
> Jacques
>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
In reply to this post by Scott Gray-3
Hi Scott,

Thanks for your review, much appreciated.

You are right my mechanism was flawed.
It did not occur to me that by using JavaScript I opened the client side.
For instance by using what follows, I can log as a limited admin.

function getJwtToken1(webAppName) {
     var JwtToken = "";
     var userLoginId = "ltdadmin"

     if (userLoginId != null && userLoginId != "") {
         jQuery.ajax({
             url: "getJwtToken",
             type: "POST",
             async: false,
             dataType: "text",
             data: {"userLoginId" : userLoginId},
             success: function(data) {
                 JwtToken = data;
             },
             error: function(textStatus, errorThrown){
                 alert('Failure, errorThrown: ' + errorThrown);
             }
         });
     }
     return JwtToken;
}


function sendJwtToken1(webAppName, targetUrl) {
     var redirectUrl = targetUrl;
     var jwtToken = getJwtToken1(webAppName);
     if (jwtToken != null && jwtToken != "") {
         jQuery.ajax({
             url: targetUrl,
             async: false,
             type: 'POST',
             xhrFields: {withCredentials: true},
             headers: {"Authorization" : jwtToken},
             success: function(){
                 window.location.assign(redirectUrl);
             }
         });
     }
}

sendJwtToken1('catalog', 'https://jleroux.nereide.fr/content/control/main')

I was plain stupid, I don't need to pass by the client side with the getAutoUserLoginId() js function.
I can get the login on the server side inside CommonEvents::getJwtToken. I initially created LoginWorker::getAutoUserLoginId just for that!
The Java code was ready and I lost myself during all these wandering (as Jacopo said like in Jame Joyce's Ulysse).
I must say the code seems "simple" now, but there was a lot of work to get there.

I have attached a new patch, please double check.

Thanks again for your help.

Jacques

Le 16/08/2018 à 22:08, Scott Gray a écrit :

> Hi Jacques,
>
> Assuming I was looking at the correct patch, it looks like I could use this
> feature to login as anyone.  All I need to do is send any userLoginId to
> getJwtToken and then I can login as that user with the token that comes
> back.  Am I missing something?
>
> Regards
> Scott
>
> On 15 August 2018 at 07:08, Jacques Le Roux <[hidden email]>
> wrote:
>
>> Hi,
>>
>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>
>> I asked for reviews but only Taher answered and he asked to know the goal
>> of this new feature.
>>
>> It was actually developed for a client who needed to get from one OFBiz
>> instance on a server (on a domain) to another OFBiz instance on another
>> server (on another domain) without having to sign up between the 2 while
>> keeping things secure.
>>
>> There could be many reasons why you want to split OFBiz application on
>> servers. In their case it was for performance issues.
>>
>> The technology used is as secure as possible. Like OAuth 2.0 it uses a
>> token but it does not need a middle authorization server (think to
>> two-factor authentication) because it's only for OFBiz instances of the
>> same version.
>>
>> To commit this work we need 1st to agree an commit the work done by Deepak
>> at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>
>> For me there is only one question outstanding: how to store the Token
>> secret. But this should not prevent us to commit Deepak's work.
>>
>> It's now a long time (9 months) since I started this work. And my last
>> patch is ready for a month.
>>
>> I crossed several issues which are now all resolved. So please review and
>> answer to this thread.
>>
>> Without negative comments well argumented I'll commit both OFBIZ-9833 and
>> OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>
>> Also a veto on a commit is always possible... Of course, as ever, a good
>> consensus is preferred.
>>
>> Let me know if you need more information about the goal. For the technical
>> details I think I already provided them the in OFBIZ-10307.
>>
>> Jacques
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
In reply to this post by Shi Jinghai-3
Hi Jinghai,

Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"

Thanks for your interest.

Jacques


Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

> Hi Jacques,
>
> OK, I think the redis topic is jumped to next step.
>
> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>
> [1] https://github.com/apereo/cas
> [2] https://auth0.com/
>
> Kind Regards,
>
> Shi Jinghai
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月16日 2:08
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> The problem with the token master secret key is to guarantee its secrecy at max.
>
> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>
> How is Redis more secure than Postgres for storing values?
>
> Thanks
>
> Jacques
>
>
> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>> Dear Jacques,
>>
>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>
>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>
>> [1] https://redis.io/
>> [2] https://db-engines.com/en/ranking
>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>
>> BTW, I'll try to review the patches.
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月15日 15:09
>> 收件人: [hidden email]
>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi,
>>
>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>
>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>
>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>
>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>
>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>> authentication) because it's only for OFBiz instances of the same version.
>>
>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>
>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>
>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>
>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>
>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>
>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>
>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>
>> Jacques
>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
ôOps missed some words...

Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
allow an user to connect to another OFBiz instance (using same version than source) on another server (target) on another domain w/o signing in.

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

taher
Wow, so after having a long, long email (as usual) talking about how
good the work is and you deployed for a client (my god!), now you
reverted because of a fundamental flaw pointed out by Scott.

And now you want to apply lazy consensus despite my objections and the
obvious flaw which you acknowledged. This makes me skeptical of the
entire approach and the quality of the code in question. I would
prefer if you halt all work and study what you're doing instead of
falling into more mistakes.

I'm also distressed with your phrase "Without negative comments well
argumented I'll commit both". In other words if you can't convince me
i'm pushing this code, why, because I want to. That's not how
community works.
On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
<[hidden email]> wrote:
>
> ôOps missed some words...
>
> Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
> > I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
> allow an user to connect to another OFBiz instance (using same version than source) on another server (target) on another domain w/o signing in.
>
> Jacques
>
Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Shi Jinghai-3
In reply to this post by Jacques Le Roux
Thanks Jacques!

If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. I have cas 4.2.x version running in production environment, I'll upgrade it to cas 5.2.x and then release it.



-----邮件原件-----
发件人: Jacques Le Roux [mailto:[hidden email]]
发送时间: 2018年8月19日 18:34
收件人: [hidden email]
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Hi Jinghai,

Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"

Thanks for your interest.

Jacques


Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

> Hi Jacques,
>
> OK, I think the redis topic is jumped to next step.
>
> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>
> [1] https://github.com/apereo/cas
> [2] https://auth0.com/
>
> Kind Regards,
>
> Shi Jinghai
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月16日 2:08
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> The problem with the token master secret key is to guarantee its secrecy at max.
>
> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>
> How is Redis more secure than Postgres for storing values?
>
> Thanks
>
> Jacques
>
>
> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>> Dear Jacques,
>>
>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>
>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>
>> [1] https://redis.io/
>> [2] https://db-engines.com/en/ranking
>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>
>> BTW, I'll try to review the patches.
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月15日 15:09
>> 收件人: [hidden email]
>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi,
>>
>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>
>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>
>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>
>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>
>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>> authentication) because it's only for OFBiz instances of the same version.
>>
>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>
>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>
>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>
>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>
>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>
>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>
>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>
>> Jacques
>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
In reply to this post by taher
Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :
> Wow, so after having a long, long email (as usual) talking about how
> good the work is and you deployed for a client (my god!), now you
> reverted because of a fundamental flaw pointed out by Scott.
I did not revert, it was not committed. I updated my patch and it was really a small change.
Initially I already planned to not use the client side to grab the loginId with OFBIZ-10206. But forgot about it because I stumbled upon many other
issues since.
This work was challenging at many levels, believe me. I'll not drop it without really good arguments!

> And now you want to apply lazy consensus despite my objections and the
> obvious flaw which you acknowledged. This makes me skeptical of the
> entire approach and the quality of the code in question. I would
> prefer if you halt all work and study what you're doing instead of
> falling into more mistakes.
Again, please give me good *technical* arguments. My work works and is safe, prove the contrary.

> I'm also distressed with your phrase "Without negative comments well
> argumented I'll commit both". In other words if you can't convince me
> i'm pushing this code, why, because I want to. That's not how
> community works.
Keep calm, you can still prevent me to commit if  you give me good argument as Scoot did.
And if you can't find them now you will still be able to veto if you find some later.
And again as explained at https://www.apache.org/foundation/voting.html#Veto you need arguments:

    /To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a
    security exposure, negatively affects performance, //etc.//). A veto without a justification is invalid and has no weight./

Remember this is only trunk and will not be released before at least 1 year and most possibly 2, you have plenty of time.

I'm all ears

Jacques

> On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
> <[hidden email]> wrote:
>> ôOps missed some words...
>>
>> Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
>>> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>> allow an user to connect to another OFBiz instance (using same version than source) on another server (target) on another domain w/o signing in.
>>
>> Jacques
>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
In reply to this post by Shi Jinghai-3
Hi Jinghai,

I'm not sure why you want to create a CAS plugin. At least it's unrelated with OFBIZ-1307

Also are you aware of https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?

Does this still work? Do we need a new plugin?

Thanks

Jacques


Le 19/08/2018 à 22:00, Shi Jinghai a écrit :

> Thanks Jacques!
>
> If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. I have cas 4.2.x version running in production environment, I'll upgrade it to cas 5.2.x and then release it.
>
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月19日 18:34
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
> Identify server (as is the SAML protocol).
>
> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>
> Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"
>
> Thanks for your interest.
>
> Jacques
>
>
> Le 17/08/2018 à 09:02, Shi Jinghai a écrit :
>> Hi Jacques,
>>
>> OK, I think the redis topic is jumped to next step.
>>
>> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>>
>> [1] https://github.com/apereo/cas
>> [2] https://auth0.com/
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月16日 2:08
>> 收件人: [hidden email]
>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi Jinghai,
>>
>> The problem with the token master secret key is to guarantee its secrecy at max.
>>
>> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>>
>> How is Redis more secure than Postgres for storing values?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>>> Dear Jacques,
>>>
>>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>>
>>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>>
>>> [1] https://redis.io/
>>> [2] https://db-engines.com/en/ranking
>>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>>
>>> BTW, I'll try to review the patches.
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>> -----邮件原件-----
>>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>>> 发送时间: 2018年8月15日 15:09
>>> 收件人: [hidden email]
>>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>>
>>> Hi,
>>>
>>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>>
>>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>>
>>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>>
>>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>>
>>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>>> authentication) because it's only for OFBiz instances of the same version.
>>>
>>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>>
>>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>>
>>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>>
>>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>>
>>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>>
>>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>>
>>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>>
>>> Jacques
>>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Shi Jinghai-3
In reply to this post by Jacques Le Roux
Hi Jacques,

The LDAP plugin can be split to 2 parts, LDAP and CAS client. The LDAP part can be removed, because Andrian Crum implemented it in framework/security, he insisted it's earlier than mine, I agree now. The CAS client can be merged into passport plugin. Personally I think the CAS protocol is the origin of OAuth2 and many others, and it's stricter than OAuth2 as its service token can be used/validated only once, to prevent naughty children in Yale University reuse the service tokens, well typically access token in OAuth2 has a much longer life time (from hours to month).

The CAS plugin I mentioned is a cas-server, to make OFBiz as a central OAuth2 provider. It's not related to OFBIZ-10307, it's a part of WebPOS2 contribution I promised in last year. Adding method attribute in request map (OFBIZ-10438) is the 1st step, CAS plugin is the 2nd step, OpenAPI (swagger) plugin is the 3rd step, then the WebPOS2 (Angular) plugin, and perhaps a Wechat/Facebook (React) mini app further. Not in a hurry, we can achieve it step by step :)

Briefly, this belongs to mobile support line. I'll try to open a blockchain support line when community has common interests in blockchain area.

Kind Regards,

Shi Jinghai


-----邮件原件-----
发件人: Jacques Le Roux [mailto:[hidden email]]
发送时间: 2018年8月20日 15:59
收件人: [hidden email]
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Hi Jinghai,

I'm not sure why you want to create a CAS plugin. At least it's unrelated with OFBIZ-1307

Also are you aware of https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?

Does this still work? Do we need a new plugin?

Thanks

Jacques


Le 19/08/2018 à 22:00, Shi Jinghai a écrit :

> Thanks Jacques!
>
> If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. I have cas 4.2.x version running in production environment, I'll upgrade it to cas 5.2.x and then release it.
>
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月19日 18:34
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
> Identify server (as is the SAML protocol).
>
> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>
> Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"
>
> Thanks for your interest.
>
> Jacques
>
>
> Le 17/08/2018 à 09:02, Shi Jinghai a écrit :
>> Hi Jacques,
>>
>> OK, I think the redis topic is jumped to next step.
>>
>> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>>
>> [1] https://github.com/apereo/cas
>> [2] https://auth0.com/
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月16日 2:08
>> 收件人: [hidden email]
>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi Jinghai,
>>
>> The problem with the token master secret key is to guarantee its secrecy at max.
>>
>> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>>
>> How is Redis more secure than Postgres for storing values?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>>> Dear Jacques,
>>>
>>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>>
>>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>>
>>> [1] https://redis.io/
>>> [2] https://db-engines.com/en/ranking
>>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>>
>>> BTW, I'll try to review the patches.
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>> -----邮件原件-----
>>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>>> 发送时间: 2018年8月15日 15:09
>>> 收件人: [hidden email]
>>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>>
>>> Hi,
>>>
>>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>>
>>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>>
>>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>>
>>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>>
>>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>>> authentication) because it's only for OFBiz instances of the same version.
>>>
>>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>>
>>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>>
>>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>>
>>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>>
>>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>>
>>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>>
>>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>>
>>> Jacques
>>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
Thanks Jinghai,

This much clarifies things. I'm all for these steps by steps, in Jiras with patches :)

I'm not a big fan of blockchain (yet?) but let's see...

Just as off topic notes to share:

For a client I have implement the SAML2 protocol. I see it similar as SOAP in its nature: not trendy but with a large spectrum, very serious and sure
(read well secured).
 From my experience, using the Shibboleth framework is the best way to integrate SAML IMO. But that's really for big (global) organisations.

    https://stackoverflow.com/questions/29843794/cas-server-with-saml-2#answer-29893206

BTW I read "No standard way to force logout, though (CAS has this feature)." at bottom of

    https://stackoverflow.com/questions/2033026/sso-with-cas-or-oauth#answer-3181557

SAML has also this feature, and there is a joke about it: https://www.theonion.com/after-checking-your-bank-account-remember-to-log-out-1819584860

Just try to implement and then use SLO (Single Log Out) and you will maybe share the idea.

Have fun :)

Jacques


Le 20/08/2018 à 17:54, Shi Jinghai a écrit :

> Hi Jacques,
>
> The LDAP plugin can be split to 2 parts, LDAP and CAS client. The LDAP part can be removed, because Andrian Crum implemented it in framework/security, he insisted it's earlier than mine, I agree now. The CAS client can be merged into passport plugin. Personally I think the CAS protocol is the origin of OAuth2 and many others, and it's stricter than OAuth2 as its service token can be used/validated only once, to prevent naughty children in Yale University reuse the service tokens, well typically access token in OAuth2 has a much longer life time (from hours to month).
>
> The CAS plugin I mentioned is a cas-server, to make OFBiz as a central OAuth2 provider. It's not related to OFBIZ-10307, it's a part of WebPOS2 contribution I promised in last year. Adding method attribute in request map (OFBIZ-10438) is the 1st step, CAS plugin is the 2nd step, OpenAPI (swagger) plugin is the 3rd step, then the WebPOS2 (Angular) plugin, and perhaps a Wechat/Facebook (React) mini app further. Not in a hurry, we can achieve it step by step :)
>
> Briefly, this belongs to mobile support line. I'll try to open a blockchain support line when community has common interests in blockchain area.
>
> Kind Regards,
>
> Shi Jinghai
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月20日 15:59
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> I'm not sure why you want to create a CAS plugin. At least it's unrelated with OFBIZ-1307
>
> Also are you aware of https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML#CASLDAP ?
>
> Does this still work? Do we need a new plugin?
>
> Thanks
>
> Jacques
>
>
> Le 19/08/2018 à 22:00, Shi Jinghai a écrit :
>> Thanks Jacques!
>>
>> If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. I have cas 4.2.x version running in production environment, I'll upgrade it to cas 5.2.x and then release it.
>>
>>
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月19日 18:34
>> 收件人: [hidden email]
>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi Jinghai,
>>
>> Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
>> Identify server (as is the SAML protocol).
>>
>> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>>
>> Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"
>>
>> Thanks for your interest.
>>
>> Jacques
>>
>>
>> Le 17/08/2018 à 09:02, Shi Jinghai a écrit :
>>> Hi Jacques,
>>>
>>> OK, I think the redis topic is jumped to next step.
>>>
>>> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>>>
>>> [1] https://github.com/apereo/cas
>>> [2] https://auth0.com/
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>>
>>> -----邮件原件-----
>>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>>> 发送时间: 2018年8月16日 2:08
>>> 收件人: [hidden email]
>>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>>
>>> Hi Jinghai,
>>>
>>> The problem with the token master secret key is to guarantee its secrecy at max.
>>>
>>> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>>>
>>> How is Redis more secure than Postgres for storing values?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>>>> Dear Jacques,
>>>>
>>>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>>>
>>>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>>>
>>>> [1] https://redis.io/
>>>> [2] https://db-engines.com/en/ranking
>>>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>>>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>>>
>>>> BTW, I'll try to review the patches.
>>>>
>>>> Kind Regards,
>>>>
>>>> Shi Jinghai
>>>>
>>>> -----邮件原件-----
>>>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>>>> 发送时间: 2018年8月15日 15:09
>>>> 收件人: [hidden email]
>>>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>>>
>>>> Hi,
>>>>
>>>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>>>
>>>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>>>
>>>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>>>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>>>
>>>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>>>
>>>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>>>> authentication) because it's only for OFBiz instances of the same version.
>>>>
>>>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>>>
>>>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>>>
>>>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>>>
>>>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>>>
>>>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>>>
>>>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>>>
>>>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>>>
>>>> Jacques
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Michael Brohl-3
In reply to this post by Shi Jinghai-3
Hi Shi,

what do you mean when you say you are going to release the plugin? Where
will this take place?

Regards,

Michael


Am 19.08.18 um 22:00 schrieb Shi Jinghai:

> Thanks Jacques!
>
> If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week. I have cas 4.2.x version running in production environment, I'll upgrade it to cas 5.2.x and then release it.
>
>
>
> -----邮件原件-----
> 发件人: Jacques Le Roux [mailto:[hidden email]]
> 发送时间: 2018年8月19日 18:34
> 收件人: [hidden email]
> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>
> Hi Jinghai,
>
> Actually I did not pick auth0 (not to be confused with https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those need a central
> Identify server (as is the SAML protocol).
>
> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>
> Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed in authentication"
>
> Thanks for your interest.
>
> Jacques
>
>
> Le 17/08/2018 à 09:02, Shi Jinghai a écrit :
>> Hi Jacques,
>>
>> OK, I think the redis topic is jumped to next step.
>>
>> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose auth0[2] rather than CAS. And is the implement OAuth2 alliance?
>>
>> [1] https://github.com/apereo/cas
>> [2] https://auth0.com/
>>
>> Kind Regards,
>>
>> Shi Jinghai
>>
>>
>> -----邮件原件-----
>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>> 发送时间: 2018年8月16日 2:08
>> 收件人: [hidden email]
>> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>
>> Hi Jinghai,
>>
>> The problem with the token master secret key is to guarantee its secrecy at max.
>>
>> We already discussed different solutions at https://s.apache.org/7yyR and https://s.apache.org/IBDM
>>
>> How is Redis more secure than Postgres for storing values?
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 15/08/2018 à 14:37, Shi Jinghai a écrit :
>>> Dear Jacques,
>>>
>>> On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets.
>>>
>>> Mr. Dai Haipeng contributed a Redis component in Jira[4].
>>>
>>> [1] https://redis.io/
>>> [2] https://db-engines.com/en/ranking
>>> [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
>>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829
>>>
>>> BTW, I'll try to review the patches.
>>>
>>> Kind Regards,
>>>
>>> Shi Jinghai
>>>
>>> -----邮件原件-----
>>> 发件人: Jacques Le Roux [mailto:[hidden email]]
>>> 发送时间: 2018年8月15日 15:09
>>> 收件人: [hidden email]
>>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
>>>
>>> Hi,
>>>
>>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.
>>>
>>> I asked for reviews but only Taher answered and he asked to know the goal of this new feature.
>>>
>>> It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another
>>> server (on another domain) without having to sign up between the 2 while keeping things secure.
>>>
>>> There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues.
>>>
>>> The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to  two-factor
>>> authentication) because it's only for OFBiz instances of the same version.
>>>
>>> To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch.
>>>
>>> For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work.
>>>
>>> It's now a long time (9 months) since I started this work. And my last patch is ready for a month.
>>>
>>> I crossed several issues which are now all resolved. So please review and answer to this thread.
>>>
>>> Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC.
>>>
>>> Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred.
>>>
>>> Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307.
>>>
>>> Jacques
>>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Michael Brohl-3
In reply to this post by Jacques Le Roux
Jacques,

just a remark on this:


 > Remember this is only trunk and will not be released before at least
1 year and most possibly 2, you have plenty of time.

Even this is trunk and can be unstable, we should treat trunk with the
same care as we do with release branches. trunk is not meant to put
everything in and see if it works or someone finds a bug. We all know
that this ist the root cause for some problematic code we have to deal with.

And we should not forget that new users also check out trunk to evaluate
OFBiz, so it is important to have it as stable and bug free as possible.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 20.08.18 um 09:28 schrieb Jacques Le Roux:

> Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :
>> Wow, so after having a long, long email (as usual) talking about how
>> good the work is and you deployed for a client (my god!), now you
>> reverted because of a fundamental flaw pointed out by Scott.
> I did not revert, it was not committed. I updated my patch and it was
> really a small change.
> Initially I already planned to not use the client side to grab the
> loginId with OFBIZ-10206. But forgot about it because I stumbled upon
> many other issues since.
> This work was challenging at many levels, believe me. I'll not drop it
> without really good arguments!
>
>> And now you want to apply lazy consensus despite my objections and the
>> obvious flaw which you acknowledged. This makes me skeptical of the
>> entire approach and the quality of the code in question. I would
>> prefer if you halt all work and study what you're doing instead of
>> falling into more mistakes.
> Again, please give me good *technical* arguments. My work works and is
> safe, prove the contrary.
>
>> I'm also distressed with your phrase "Without negative comments well
>> argumented I'll commit both". In other words if you can't convince me
>> i'm pushing this code, why, because I want to. That's not how
>> community works.
> Keep calm, you can still prevent me to commit if  you give me good
> argument as Scoot did.
> And if you can't find them now you will still be able to veto if you
> find some later.
> And again as explained at
> https://www.apache.org/foundation/voting.html#Veto you need arguments:
>
>    /To prevent vetos from being used capriciously, they must be
> accompanied by a technical justification showing why the change is bad
> (opens a
>    security exposure, negatively affects performance, //etc.//). A
> veto without a justification is invalid and has no weight./
>
> Remember this is only trunk and will not be released before at least 1
> year and most possibly 2, you have plenty of time.
>
> I'm all ears
>
> Jacques
>
>> On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
>> <[hidden email]> wrote:
>>> ôOps missed some words...
>>>
>>> Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
>>>> I simply send a JWT token:
>>>> https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>>> allow an user to connect to another OFBiz instance (using same
>>> version than source) on another server (target) on another domain
>>> w/o signing in.
>>>
>>> Jacques
>>>
>
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Jacques Le Roux
Administrator
You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of this work shows. This work is now ready and good, so I'll soon commit it.

Jacques


Le 21/08/2018 à 10:13, Michael Brohl a écrit :

> Jacques,
>
> just a remark on this:
>
>
> > Remember this is only trunk and will not be released before at least 1 year and most possibly 2, you have plenty of time.
>
> Even this is trunk and can be unstable, we should treat trunk with the same care as we do with release branches. trunk is not meant to put
> everything in and see if it works or someone finds a bug. We all know that this ist the root cause for some problematic code we have to deal with.
>
> And we should not forget that new users also check out trunk to evaluate OFBiz, so it is important to have it as stable and bug free as possible.
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
> Am 20.08.18 um 09:28 schrieb Jacques Le Roux:
>> Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :
>>> Wow, so after having a long, long email (as usual) talking about how
>>> good the work is and you deployed for a client (my god!), now you
>>> reverted because of a fundamental flaw pointed out by Scott.
>> I did not revert, it was not committed. I updated my patch and it was really a small change.
>> Initially I already planned to not use the client side to grab the loginId with OFBIZ-10206. But forgot about it because I stumbled upon many other
>> issues since.
>> This work was challenging at many levels, believe me. I'll not drop it without really good arguments!
>>
>>> And now you want to apply lazy consensus despite my objections and the
>>> obvious flaw which you acknowledged. This makes me skeptical of the
>>> entire approach and the quality of the code in question. I would
>>> prefer if you halt all work and study what you're doing instead of
>>> falling into more mistakes.
>> Again, please give me good *technical* arguments. My work works and is safe, prove the contrary.
>>
>>> I'm also distressed with your phrase "Without negative comments well
>>> argumented I'll commit both". In other words if you can't convince me
>>> i'm pushing this code, why, because I want to. That's not how
>>> community works.
>> Keep calm, you can still prevent me to commit if  you give me good argument as Scoot did.
>> And if you can't find them now you will still be able to veto if you find some later.
>> And again as explained at https://www.apache.org/foundation/voting.html#Veto you need arguments:
>>
>>    /To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a
>>    security exposure, negatively affects performance, //etc.//). A veto without a justification is invalid and has no weight./
>>
>> Remember this is only trunk and will not be released before at least 1 year and most possibly 2, you have plenty of time.
>>
>> I'm all ears
>>
>> Jacques
>>
>>> On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
>>> <[hidden email]> wrote:
>>>> ôOps missed some words...
>>>>
>>>> Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
>>>>> I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
>>>> allow an user to connect to another OFBiz instance (using same version than source) on another server (target) on another domain w/o signing in.
>>>>
>>>> Jacques
>>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

Michael Brohl-3
Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:
> You are totaly right on this Michael
>
> I do treat the trunk as much care as possible as the evolution of this
> work shows. This work is now ready and good, so I'll soon commit it.

So you want to ignore raised concerns and commit despite of them?



smime.p7s (5K) Download Attachment
123