[PROPOSAL] Separate login service for API calls

[grv]

Hi

I am using userLogin service to authenticate users before generating auth
tokens for REST API and GraphQL calls. However, I figured that a session is
also getting created and returned in response which is defeating the
purpose of having an API in place. Even though that session is not getting
used anywhere when subsequent calls are made using the token, I still think
it is an extra session lying around in tomcat's session cache.

I propose to implement a new basic userLogin service (basicAuthUserLogin)
that would just do username/password matching and be done with it without
ever calling request.getSession(). This will ensure that APIs are stateless
and no session is generated.

Anything else you think should be part of the new service instead of just
username/password validation?

Best,
Girish
HotWax Systems

[Gavin Mabie-2]

Sessions are extremely useful and even indispensable for an ERP system
where statefullnes are critical for audit trail purposes. Stateless
requests don't care about transactions beyond the actual request/response.
Besides, sessions are only problematic when a new session gets created for
each REST API request. You can prevent this by setting the cookie SameSite
property to "None".  That way sessions and REST request can happily live
together.

On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
[hidden email]> wrote:

> Hi
>
> I am using userLogin service to authenticate users before generating auth
> tokens for REST API and GraphQL calls. However, I figured that a session is
> also getting created and returned in response which is defeating the
> purpose of having an API in place. Even though that session is not getting
> used anywhere when subsequent calls are made using the token, I still think
> it is an extra session lying around in tomcat's session cache.
>
> I propose to implement a new basic userLogin service (basicAuthUserLogin)
> that would just do username/password matching and be done with it without
> ever calling request.getSession(). This will ensure that APIs are stateless
> and no session is generated.
>
> Anything else you think should be part of the new service instead of just
> username/password validation?
>
> Best,
> Girish
> HotWax Systems
>

[Jacques Le Roux]

Thanks Gavin,

I'd just note that in this case your are not protected from CSRF. Fortunately the REST effort is only in trunk. And, as explained in
security.properties, in trunk we can use org.apache.ofbiz.security.CsrfDefenseStrategy in such case.

Jacques

Le 26/09/2020 à 07:38, Gavin Mabie a écrit :

> Sessions are extremely useful and even indispensable for an ERP system
> where statefullnes are critical for audit trail purposes. Stateless
> requests don't care about transactions beyond the actual request/response.
> Besides, sessions are only problematic when a new session gets created for
> each REST API request. You can prevent this by setting the cookie SameSite
> property to "None".  That way sessions and REST request can happily live
> together.
>
> On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> [hidden email]> wrote:
>
>> Hi
>>
>> I am using userLogin service to authenticate users before generating auth
>> tokens for REST API and GraphQL calls. However, I figured that a session is
>> also getting created and returned in response which is defeating the
>> purpose of having an API in place. Even though that session is not getting
>> used anywhere when subsequent calls are made using the token, I still think
>> it is an extra session lying around in tomcat's session cache.
>>
>> I propose to implement a new basic userLogin service (basicAuthUserLogin)
>> that would just do username/password matching and be done with it without
>> ever calling request.getSession(). This will ensure that APIs are stateless
>> and no session is generated.
>>
>> Anything else you think should be part of the new service instead of just
>> username/password validation?
>>
>> Best,
>> Girish
>> HotWax Systems
>>

[grv]

Hello
I am not sure if we can talk about sessions when we're talking about REST.
The REST implementation is mapping Resources with OFBiz services and the
services are executing in a context using "userLogin" and that is all the
REST implementation is doing. Extracting userLogin from token and supplying
to the OFBiz service.

The session you get from running userLogin service is not getting used for
subsequent API calls made using JWT token because usual OFBiz flow
(ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
as far as REST implementation is concerned, it is better to create a
separate service that does just authentication and doesn't create sessions.

Also, a properly designed REST endpoint without cookies means no CSRF.

Best,
Girish
HotWax System








On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
[hidden email]> wrote:

> Thanks Gavin,
>
> I'd just note that in this case your are not protected from CSRF.
> Fortunately the REST effort is only in trunk. And, as explained in
> security.properties, in trunk we can use
> org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
>
> Jacques
>
> Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > Sessions are extremely useful and even indispensable for an ERP system
> > where statefullnes are critical for audit trail purposes. Stateless
> > requests don't care about transactions beyond the actual
> request/response.
> > Besides, sessions are only problematic when a new session gets created
> for
> > each REST API request. You can prevent this by setting the cookie
> SameSite
> > property to "None".  That way sessions and REST request can happily live
> > together.
> >
> > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > [hidden email]> wrote:
> >
> >> Hi
> >>
> >> I am using userLogin service to authenticate users before generating
> auth
> >> tokens for REST API and GraphQL calls. However, I figured that a
> session is
> >> also getting created and returned in response which is defeating the
> >> purpose of having an API in place. Even though that session is not
> getting
> >> used anywhere when subsequent calls are made using the token, I still
> think
> >> it is an extra session lying around in tomcat's session cache.
> >>
> >> I propose to implement a new basic userLogin service
> (basicAuthUserLogin)
> >> that would just do username/password matching and be done with it
> without
> >> ever calling request.getSession(). This will ensure that APIs are
> stateless
> >> and no session is generated.
> >>
> >> Anything else you think should be part of the new service instead of
> just
> >> username/password validation?
> >>
> >> Best,
> >> Girish
> >> HotWax Systems
> >>
>

[Deepak Dixit-4]

Hi Girish,

I think it's a good idea to use a separate login method for REST to
avoid sessions.

We have *userLogin* service that do the login related work, so we can have
separate wrapper method for REST like LoginWorker.login()


Kind Regards,
Deepak Dixit


On Sat, Sep 26, 2020 at 2:54 PM Girish Vasmatkar <
[hidden email]> wrote:

> Hello
> I am not sure if we can talk about sessions when we're talking about REST.
> The REST implementation is mapping Resources with OFBiz services and the
> services are executing in a context using "userLogin" and that is all the
> REST implementation is doing. Extracting userLogin from token and supplying
> to the OFBiz service.
>
> The session you get from running userLogin service is not getting used for
> subsequent API calls made using JWT token because usual OFBiz flow
> (ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
> as far as REST implementation is concerned, it is better to create a
> separate service that does just authentication and doesn't create sessions.
>
> Also, a properly designed REST endpoint without cookies means no CSRF.
>
> Best,
> Girish
> HotWax System
>
>
>
>
>
>
>
>
> On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
> [hidden email]> wrote:
>
> > Thanks Gavin,
> >
> > I'd just note that in this case your are not protected from CSRF.
> > Fortunately the REST effort is only in trunk. And, as explained in
> > security.properties, in trunk we can use
> > org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
> >
> > Jacques
> >
> > Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > > Sessions are extremely useful and even indispensable for an ERP system
> > > where statefullnes are critical for audit trail purposes. Stateless
> > > requests don't care about transactions beyond the actual
> > request/response.
> > > Besides, sessions are only problematic when a new session gets created
> > for
> > > each REST API request. You can prevent this by setting the cookie
> > SameSite
> > > property to "None".  That way sessions and REST request can happily
> live
> > > together.
> > >
> > > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > > [hidden email]> wrote:
> > >
> > >> Hi
> > >>
> > >> I am using userLogin service to authenticate users before generating
> > auth
> > >> tokens for REST API and GraphQL calls. However, I figured that a
> > session is
> > >> also getting created and returned in response which is defeating the
> > >> purpose of having an API in place. Even though that session is not
> > getting
> > >> used anywhere when subsequent calls are made using the token, I still
> > think
> > >> it is an extra session lying around in tomcat's session cache.
> > >>
> > >> I propose to implement a new basic userLogin service
> > (basicAuthUserLogin)
> > >> that would just do username/password matching and be done with it
> > without
> > >> ever calling request.getSession(). This will ensure that APIs are
> > stateless
> > >> and no session is generated.
> > >>
> > >> Anything else you think should be part of the new service instead of
> > just
> > >> username/password validation?
> > >>
> > >> Best,
> > >> Girish
> > >> HotWax Systems
> > >>
> >
>

[Gavin Mabie-2]

You're right Jacques.  SameState=None exposes CSRF. Thanks for pointing
that out.

On Sat, Sep 26, 2020 at 10:34 AM Jacques Le Roux <
[hidden email]> wrote:

> Thanks Gavin,
>
> I'd just note that in this case your are not protected from CSRF.
> Fortunately the REST effort is only in trunk. And, as explained in
> security.properties, in trunk we can use
> org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
>
> Jacques
>
> Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > Sessions are extremely useful and even indispensable for an ERP system
> > where statefullnes are critical for audit trail purposes. Stateless
> > requests don't care about transactions beyond the actual
> request/response.
> > Besides, sessions are only problematic when a new session gets created
> for
> > each REST API request. You can prevent this by setting the cookie
> SameSite
> > property to "None".  That way sessions and REST request can happily live
> > together.
> >
> > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > [hidden email]> wrote:
> >
> >> Hi
> >>
> >> I am using userLogin service to authenticate users before generating
> auth
> >> tokens for REST API and GraphQL calls. However, I figured that a
> session is
> >> also getting created and returned in response which is defeating the
> >> purpose of having an API in place. Even though that session is not
> getting
> >> used anywhere when subsequent calls are made using the token, I still
> think
> >> it is an extra session lying around in tomcat's session cache.
> >>
> >> I propose to implement a new basic userLogin service
> (basicAuthUserLogin)
> >> that would just do username/password matching and be done with it
> without
> >> ever calling request.getSession(). This will ensure that APIs are
> stateless
> >> and no session is generated.
> >>
> >> Anything else you think should be part of the new service instead of
> just
> >> username/password validation?
> >>
> >> Best,
> >> Girish
> >> HotWax Systems
> >>
>

[Jacques Le Roux]

+1

Jacques

Le 26/09/2020 à 13:56, Deepak Dixit a écrit :

> Hi Girish,
>
> I think it's a good idea to use a separate login method for REST to
> avoid sessions.
>
> We have *userLogin* service that do the login related work, so we can have
> separate wrapper method for REST like LoginWorker.login()
>
>
> Kind Regards,
> Deepak Dixit
>
>
> On Sat, Sep 26, 2020 at 2:54 PM Girish Vasmatkar <
> [hidden email]> wrote:
>
>> Hello
>> I am not sure if we can talk about sessions when we're talking about REST.
>> The REST implementation is mapping Resources with OFBiz services and the
>> services are executing in a context using "userLogin" and that is all the
>> REST implementation is doing. Extracting userLogin from token and supplying
>> to the OFBiz service.
>>
>> The session you get from running userLogin service is not getting used for
>> subsequent API calls made using JWT token because usual OFBiz flow
>> (ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
>> as far as REST implementation is concerned, it is better to create a
>> separate service that does just authentication and doesn't create sessions.
>>
>> Also, a properly designed REST endpoint without cookies means no CSRF.
>>
>> Best,
>> Girish
>> HotWax System
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> Thanks Gavin,
>>>
>>> I'd just note that in this case your are not protected from CSRF.
>>> Fortunately the REST effort is only in trunk. And, as explained in
>>> security.properties, in trunk we can use
>>> org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
>>>
>>> Jacques
>>>
>>> Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
>>>> Sessions are extremely useful and even indispensable for an ERP system
>>>> where statefullnes are critical for audit trail purposes. Stateless
>>>> requests don't care about transactions beyond the actual
>>> request/response.
>>>> Besides, sessions are only problematic when a new session gets created
>>> for
>>>> each REST API request. You can prevent this by setting the cookie
>>> SameSite
>>>> property to "None".  That way sessions and REST request can happily
>> live
>>>> together.
>>>>
>>>> On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
>>>> [hidden email]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I am using userLogin service to authenticate users before generating
>>> auth
>>>>> tokens for REST API and GraphQL calls. However, I figured that a
>>> session is
>>>>> also getting created and returned in response which is defeating the
>>>>> purpose of having an API in place. Even though that session is not
>>> getting
>>>>> used anywhere when subsequent calls are made using the token, I still
>>> think
>>>>> it is an extra session lying around in tomcat's session cache.
>>>>>
>>>>> I propose to implement a new basic userLogin service
>>> (basicAuthUserLogin)
>>>>> that would just do username/password matching and be done with it
>>> without
>>>>> ever calling request.getSession(). This will ensure that APIs are
>>> stateless
>>>>> and no session is generated.
>>>>>
>>>>> Anything else you think should be part of the new service instead of
>>> just
>>>>> username/password validation?
>>>>>
>>>>> Best,
>>>>> Girish
>>>>> HotWax Systems
>>>>>

[Jacopo Cappellato-3]

+1

Jacopo

On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
[hidden email]> wrote:

> Hi
>
> I am using userLogin service to authenticate users before generating auth
> tokens for REST API and GraphQL calls. However, I figured that a session is
> also getting created and returned in response which is defeating the
> purpose of having an API in place. Even though that session is not getting
> used anywhere when subsequent calls are made using the token, I still think
> it is an extra session lying around in tomcat's session cache.
>
> I propose to implement a new basic userLogin service (basicAuthUserLogin)
> that would just do username/password matching and be done with it without
> ever calling request.getSession(). This will ensure that APIs are stateless
> and no session is generated.
>
> Anything else you think should be part of the new service instead of just
> username/password validation?
>
> Best,
> Girish
> HotWax Systems
>

[Michael Brohl-3]

+1

With an addition: we should do the implementation in a way that the
user/password matching is implemented only once and used in both login
methods (not just copy & paste into another method).

It might take some refactoring to pull these part out of the login event.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 29.09.20 um 09:43 schrieb Jacopo Cappellato:

> +1
>
> Jacopo
>
> On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> [hidden email]> wrote:
>
>> Hi
>>
>> I am using userLogin service to authenticate users before generating auth
>> tokens for REST API and GraphQL calls. However, I figured that a session is
>> also getting created and returned in response which is defeating the
>> purpose of having an API in place. Even though that session is not getting
>> used anywhere when subsequent calls are made using the token, I still think
>> it is an extra session lying around in tomcat's session cache.
>>
>> I propose to implement a new basic userLogin service (basicAuthUserLogin)
>> that would just do username/password matching and be done with it without
>> ever calling request.getSession(). This will ensure that APIs are stateless
>> and no session is generated.
>>
>> Anything else you think should be part of the new service instead of just
>> username/password validation?
>>
>> Best,
>> Girish
>> HotWax Systems
>>

[Mridul Pathak-5]

+1

Thanks.
Mridul Pathak

On Tue, Sep 29, 2020 at 1:29 PM Michael Brohl <[hidden email]>
wrote:

> +1
>
> With an addition: we should do the implementation in a way that the
> user/password matching is implemented only once and used in both login
> methods (not just copy & paste into another method).
>
> It might take some refactoring to pull these part out of the login event.
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 29.09.20 um 09:43 schrieb Jacopo Cappellato:
> > +1
> >
> > Jacopo
> >
> > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > [hidden email]> wrote:
> >
> >> Hi
> >>
> >> I am using userLogin service to authenticate users before generating
> auth
> >> tokens for REST API and GraphQL calls. However, I figured that a
> session is
> >> also getting created and returned in response which is defeating the
> >> purpose of having an API in place. Even though that session is not
> getting
> >> used anywhere when subsequent calls are made using the token, I still
> think
> >> it is an extra session lying around in tomcat's session cache.
> >>
> >> I propose to implement a new basic userLogin service
> (basicAuthUserLogin)
> >> that would just do username/password matching and be done with it
> without
> >> ever calling request.getSession(). This will ensure that APIs are
> stateless
> >> and no session is generated.
> >>
> >> Anything else you think should be part of the new service instead of
> just
> >> username/password validation?
> >>
> >> Best,
> >> Girish
> >> HotWax Systems
> >>
>
>

[grv]

I've created https://issues.apache.org/jira/browse/OFBIZ-12033 for the
same. Thank you, all.

Best,
Girish
HotWax Systems

On Tue, Sep 29, 2020 at 1:39 PM Mridul Pathak <[hidden email]>
wrote:

> +1
>
> Thanks.
> Mridul Pathak
>
> On Tue, Sep 29, 2020 at 1:29 PM Michael Brohl <[hidden email]>
> wrote:
>
> > +1
> >
> > With an addition: we should do the implementation in a way that the
> > user/password matching is implemented only once and used in both login
> > methods (not just copy & paste into another method).
> >
> > It might take some refactoring to pull these part out of the login event.
> >
> > Best regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 29.09.20 um 09:43 schrieb Jacopo Cappellato:
> > > +1
> > >
> > > Jacopo
> > >
> > > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > > [hidden email]> wrote:
> > >
> > >> Hi
> > >>
> > >> I am using userLogin service to authenticate users before generating
> > auth
> > >> tokens for REST API and GraphQL calls. However, I figured that a
> > session is
> > >> also getting created and returned in response which is defeating the
> > >> purpose of having an API in place. Even though that session is not
> > getting
> > >> used anywhere when subsequent calls are made using the token, I still
> > think
> > >> it is an extra session lying around in tomcat's session cache.
> > >>
> > >> I propose to implement a new basic userLogin service
> > (basicAuthUserLogin)
> > >> that would just do username/password matching and be done with it
> > without
> > >> ever calling request.getSession(). This will ensure that APIs are
> > stateless
> > >> and no session is generated.
> > >>
> > >> Anything else you think should be part of the new service instead of
> > just
> > >> username/password validation?
> > >>
> > >> Best,
> > >> Girish
> > >> HotWax Systems
> > >>
> >
> >
>