You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Pradeep Fernando <pr...@gmail.com> on 2014/02/02 12:46:58 UTC
Session based authentication/authorization for REST API
Hi,
I Completed the $subject. Now you can get a jsessionId from the /cookie
endpoint and use that in subsequent requests.
I have used that in the web console as well. its working fine should be
able to complete it by tomorrow. This is in addition to SAML SSO
authentication.
IMO, we should use the same mechanism in CLI as well. At the moment CLI is
storing the username/password. It is not a good practice and CLI continue
to work even when we restart the backend.. :)
Sajith please look in to that if you have some time.
flow listed below.
endpoint url,
/stratos/admin/cookie
GET request.
authenticate with basic auth.
you get the JSESSIONID
use that JSESSIONID as a cookie for subsequent requests.
thanks,
--Pradeep
--
Pradeep Fernando.
http://pradeepfernando.blogspot.com/
Re: Session based authentication/authorization for REST API
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
OAuth already has a standard login protocol which creates a token. My issue
is with using HTTP session cookies as they go away in a few mins of idle
time (max). The command line client is calling proper OAuth APIs right? In
that case it should just use the OAuth token right? It certainly should not
be storing user/pass under any condition.
For the app, if the objective is to maintain a browser login then the
proper thing is to mimic what OAuth does. See:
http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website(the
first answer). If the app is turning around and calling an API
underneath the the DB table can store the OAuth token too so it can use
that to make calls on behalf of the user.
Why is basic auth involved at all here?
Sanjiva.
On Sun, Feb 2, 2014 at 8:38 PM, Pradeep Fernando <pr...@gmail.com>wrote:
> Hi,
>
> If we introduce implicit cookie based authentication, then there need not
> be seperate endpoint to retrieve the cookie. Then server should first try
> to authenticate using session and if not try to authenticate using basic
> auth headers if present. In this approach the application writer has to
> decide on the first endpoint call (since he has to send in
> username/password during the first invocation)
>
> Here what we are doing is, defining a explicit endpoint to do the same.
> Even in the oauth, this is the flow i guess. we sent in
> client-id/client-secret and get a arbitrary string and use that for
> subsequent calls..
>
> thanks,
> --Pradeep
>
>
> On Sun, Feb 2, 2014 at 8:07 PM, Pradeep Fernando <pr...@gmail.com>wrote:
>
>> Hi,
>> Let me explain the original problem, so that you can suggest a better
>> approach.
>>
>> - we are using basic auth headers to authenticate/authorize our rest
>> backend. It works fine
>> - We did not maintain sessions up until now. (not request.getSession
>> method call)
>> - We have two clients at the moment. A jaggery app and a command line
>> client.
>> - command-line client stores the username/password during the
>> initialization and add basic auth headers to subsequent calls.
>> - for webapp we introduced web-sso and oauth based solution. its working
>> but there are certain setup steps. not the first experience we want to have.
>> - Hence introduced this authentication endpoint that returns a cookie
>> - I followed the approach similar to AuthenticationAdminEndpoint used in
>> carbon servers. It returns a cookie and we use that to make subsequent WS
>> calls...
>>
>> wdyt ?
>>
>> Thanks,
>> --Pradeep
>>
>>
>>
>> On Sun, Feb 2, 2014 at 7:21 PM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
>>
>>> Hmmmm this doesn't sound like a good idea to me. So you've introduced an
>>> endpoint that the client calls to get the Java session ID associated with a
>>> servlet session?
>>>
>>> Those session IDs are very transient .. they time out. That's not the
>>> cookie used for remember me in GMail for example.
>>>
>>> In any case, you can get this ID from any response .. why do I need to
>>> call a specific URL to get it? This is how clients maintain session - by
>>> returning all the cookies the server sends.
>>>
>>> What am I missing to understand why this makes sense?
>>>
>>> Sanjiva.
>>>
>>>
>>> On Sun, Feb 2, 2014 at 5:16 PM, Pradeep Fernando <pr...@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I Completed the $subject. Now you can get a jsessionId from the /cookie
>>>> endpoint and use that in subsequent requests.
>>>>
>>>> I have used that in the web console as well. its working fine should be
>>>> able to complete it by tomorrow. This is in addition to SAML SSO
>>>> authentication.
>>>>
>>>> IMO, we should use the same mechanism in CLI as well. At the moment CLI
>>>> is storing the username/password. It is not a good practice and CLI
>>>> continue to work even when we restart the backend.. :)
>>>>
>>>> Sajith please look in to that if you have some time.
>>>>
>>>> flow listed below.
>>>>
>>>> endpoint url,
>>>>
>>>> /stratos/admin/cookie
>>>>
>>>> GET request.
>>>>
>>>> authenticate with basic auth.
>>>>
>>>> you get the JSESSIONID
>>>>
>>>> use that JSESSIONID as a cookie for subsequent requests.
>>>>
>>>>
>>>> thanks,
>>>> --Pradeep
>>>>
>>>>
>>>>
>>>> --
>>>> Pradeep Fernando.
>>>> http://pradeepfernando.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>> email: sanjiva@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345)
>>> x5700; cell: +94 77 787 6880 | +1 650 265 8311
>>> blog: http://sanjiva.weerawarana.org/
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>> Pradeep Fernando.
>> http://pradeepfernando.blogspot.com/
>>
>
>
>
> --
> Pradeep Fernando.
> http://pradeepfernando.blogspot.com/
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
email: sanjiva@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345)
x5700; cell: +94 77 787 6880 | +1 650 265 8311
blog: http://sanjiva.weerawarana.org/
Lean . Enterprise . Middleware
Re: Session based authentication/authorization for REST API
Posted by Pradeep Fernando <pr...@gmail.com>.
Hi,
If we introduce implicit cookie based authentication, then there need not
be seperate endpoint to retrieve the cookie. Then server should first try
to authenticate using session and if not try to authenticate using basic
auth headers if present. In this approach the application writer has to
decide on the first endpoint call (since he has to send in
username/password during the first invocation)
Here what we are doing is, defining a explicit endpoint to do the same.
Even in the oauth, this is the flow i guess. we sent in
client-id/client-secret and get a arbitrary string and use that for
subsequent calls..
thanks,
--Pradeep
On Sun, Feb 2, 2014 at 8:07 PM, Pradeep Fernando <pr...@gmail.com>wrote:
> Hi,
> Let me explain the original problem, so that you can suggest a better
> approach.
>
> - we are using basic auth headers to authenticate/authorize our rest
> backend. It works fine
> - We did not maintain sessions up until now. (not request.getSession
> method call)
> - We have two clients at the moment. A jaggery app and a command line
> client.
> - command-line client stores the username/password during the
> initialization and add basic auth headers to subsequent calls.
> - for webapp we introduced web-sso and oauth based solution. its working
> but there are certain setup steps. not the first experience we want to have.
> - Hence introduced this authentication endpoint that returns a cookie
> - I followed the approach similar to AuthenticationAdminEndpoint used in
> carbon servers. It returns a cookie and we use that to make subsequent WS
> calls...
>
> wdyt ?
>
> Thanks,
> --Pradeep
>
>
>
> On Sun, Feb 2, 2014 at 7:21 PM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
>
>> Hmmmm this doesn't sound like a good idea to me. So you've introduced an
>> endpoint that the client calls to get the Java session ID associated with a
>> servlet session?
>>
>> Those session IDs are very transient .. they time out. That's not the
>> cookie used for remember me in GMail for example.
>>
>> In any case, you can get this ID from any response .. why do I need to
>> call a specific URL to get it? This is how clients maintain session - by
>> returning all the cookies the server sends.
>>
>> What am I missing to understand why this makes sense?
>>
>> Sanjiva.
>>
>>
>> On Sun, Feb 2, 2014 at 5:16 PM, Pradeep Fernando <pr...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I Completed the $subject. Now you can get a jsessionId from the /cookie
>>> endpoint and use that in subsequent requests.
>>>
>>> I have used that in the web console as well. its working fine should be
>>> able to complete it by tomorrow. This is in addition to SAML SSO
>>> authentication.
>>>
>>> IMO, we should use the same mechanism in CLI as well. At the moment CLI
>>> is storing the username/password. It is not a good practice and CLI
>>> continue to work even when we restart the backend.. :)
>>>
>>> Sajith please look in to that if you have some time.
>>>
>>> flow listed below.
>>>
>>> endpoint url,
>>>
>>> /stratos/admin/cookie
>>>
>>> GET request.
>>>
>>> authenticate with basic auth.
>>>
>>> you get the JSESSIONID
>>>
>>> use that JSESSIONID as a cookie for subsequent requests.
>>>
>>>
>>> thanks,
>>> --Pradeep
>>>
>>>
>>>
>>> --
>>> Pradeep Fernando.
>>> http://pradeepfernando.blogspot.com/
>>>
>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>> email: sanjiva@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345)
>> x5700; cell: +94 77 787 6880 | +1 650 265 8311
>> blog: http://sanjiva.weerawarana.org/
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> Pradeep Fernando.
> http://pradeepfernando.blogspot.com/
>
--
Pradeep Fernando.
http://pradeepfernando.blogspot.com/
Re: Session based authentication/authorization for REST API
Posted by Pradeep Fernando <pr...@gmail.com>.
Hi,
Let me explain the original problem, so that you can suggest a better
approach.
- we are using basic auth headers to authenticate/authorize our rest
backend. It works fine
- We did not maintain sessions up until now. (not request.getSession
method call)
- We have two clients at the moment. A jaggery app and a command line
client.
- command-line client stores the username/password during the
initialization and add basic auth headers to subsequent calls.
- for webapp we introduced web-sso and oauth based solution. its working
but there are certain setup steps. not the first experience we want to have.
- Hence introduced this authentication endpoint that returns a cookie
- I followed the approach similar to AuthenticationAdminEndpoint used in
carbon servers. It returns a cookie and we use that to make subsequent WS
calls...
wdyt ?
Thanks,
--Pradeep
On Sun, Feb 2, 2014 at 7:21 PM, Sanjiva Weerawarana <sa...@wso2.com>wrote:
> Hmmmm this doesn't sound like a good idea to me. So you've introduced an
> endpoint that the client calls to get the Java session ID associated with a
> servlet session?
>
> Those session IDs are very transient .. they time out. That's not the
> cookie used for remember me in GMail for example.
>
> In any case, you can get this ID from any response .. why do I need to
> call a specific URL to get it? This is how clients maintain session - by
> returning all the cookies the server sends.
>
> What am I missing to understand why this makes sense?
>
> Sanjiva.
>
>
> On Sun, Feb 2, 2014 at 5:16 PM, Pradeep Fernando <pr...@gmail.com>wrote:
>
>> Hi,
>>
>> I Completed the $subject. Now you can get a jsessionId from the /cookie
>> endpoint and use that in subsequent requests.
>>
>> I have used that in the web console as well. its working fine should be
>> able to complete it by tomorrow. This is in addition to SAML SSO
>> authentication.
>>
>> IMO, we should use the same mechanism in CLI as well. At the moment CLI
>> is storing the username/password. It is not a good practice and CLI
>> continue to work even when we restart the backend.. :)
>>
>> Sajith please look in to that if you have some time.
>>
>> flow listed below.
>>
>> endpoint url,
>>
>> /stratos/admin/cookie
>>
>> GET request.
>>
>> authenticate with basic auth.
>>
>> you get the JSESSIONID
>>
>> use that JSESSIONID as a cookie for subsequent requests.
>>
>>
>> thanks,
>> --Pradeep
>>
>>
>>
>> --
>> Pradeep Fernando.
>> http://pradeepfernando.blogspot.com/
>>
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
> email: sanjiva@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345)
> x5700; cell: +94 77 787 6880 | +1 650 265 8311
> blog: http://sanjiva.weerawarana.org/
> Lean . Enterprise . Middleware
>
--
Pradeep Fernando.
http://pradeepfernando.blogspot.com/
Re: Session based authentication/authorization for REST API
Posted by Sanjiva Weerawarana <sa...@wso2.com>.
Hmmmm this doesn't sound like a good idea to me. So you've introduced an
endpoint that the client calls to get the Java session ID associated with a
servlet session?
Those session IDs are very transient .. they time out. That's not the
cookie used for remember me in GMail for example.
In any case, you can get this ID from any response .. why do I need to call
a specific URL to get it? This is how clients maintain session - by
returning all the cookies the server sends.
What am I missing to understand why this makes sense?
Sanjiva.
On Sun, Feb 2, 2014 at 5:16 PM, Pradeep Fernando <pr...@gmail.com>wrote:
> Hi,
>
> I Completed the $subject. Now you can get a jsessionId from the /cookie
> endpoint and use that in subsequent requests.
>
> I have used that in the web console as well. its working fine should be
> able to complete it by tomorrow. This is in addition to SAML SSO
> authentication.
>
> IMO, we should use the same mechanism in CLI as well. At the moment CLI is
> storing the username/password. It is not a good practice and CLI continue
> to work even when we restart the backend.. :)
>
> Sajith please look in to that if you have some time.
>
> flow listed below.
>
> endpoint url,
>
> /stratos/admin/cookie
>
> GET request.
>
> authenticate with basic auth.
>
> you get the JSESSIONID
>
> use that JSESSIONID as a cookie for subsequent requests.
>
>
> thanks,
> --Pradeep
>
>
>
> --
> Pradeep Fernando.
> http://pradeepfernando.blogspot.com/
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
email: sanjiva@wso2.com; office: (+1 650 745 4499 | +94 11 214 5345)
x5700; cell: +94 77 787 6880 | +1 650 265 8311
blog: http://sanjiva.weerawarana.org/
Lean . Enterprise . Middleware