API-Proxy for Single Page Application

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

API-Proxy for Single Page Application

Thilina Madumal
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

roshan wijesena-2
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi Roshan,


On Fri, Nov 17, 2017 at 11:00 AM, roshan wijesena <[hidden email]> wrote:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

Actually this proxy has two parts, LoginProxy and APIProxy.
LoginProxy part do the authentication and autherization of the user on behalf of SPA.
APIProxy mediates the calls to third-party APIs as requested by the SPA by decrypting the access_token.

The ultimate goal is, when developing a SPA where there is no attached server-side, the devloper just needs to calll the necessary APIs of the proxy.
Then the proxy will do the rest.
 

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Ruwan Abeykoon
Hi Thilina,
Can you try implementing this with Ballerina. This should be a simple case for Ballerina.

Cheers,
Ruwan 

On Fri, Nov 17, 2017 at 11:16 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Fri, Nov 17, 2017 at 11:00 AM, roshan wijesena <[hidden email]> wrote:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

Actually this proxy has two parts, LoginProxy and APIProxy.
LoginProxy part do the authentication and autherization of the user on behalf of SPA.
APIProxy mediates the calls to third-party APIs as requested by the SPA by decrypting the access_token.

The ultimate goal is, when developing a SPA where there is no attached server-side, the devloper just needs to calll the necessary APIs of the proxy.
Then the proxy will do the rest.
 

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi Ruwan,


On Fri, Nov 17, 2017 at 11:20 AM, Ruwan Abeykoon <[hidden email]> wrote:
Hi Thilina,
Can you try implementing this with Ballerina. This should be a simple case for Ballerina.

Yep, I'm looking into it. 
 

Cheers,
Ruwan 

On Fri, Nov 17, 2017 at 11:16 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Fri, Nov 17, 2017 at 11:00 AM, roshan wijesena <[hidden email]> wrote:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

Actually this proxy has two parts, LoginProxy and APIProxy.
LoginProxy part do the authentication and autherization of the user on behalf of SPA.
APIProxy mediates the calls to third-party APIs as requested by the SPA by decrypting the access_token.

The ultimate goal is, when developing a SPA where there is no attached server-side, the devloper just needs to calll the necessary APIs of the proxy.
Then the proxy will do the rest.
 

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


Thanks,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi all,

While researching I found the yahoo provides an API proxy service and it adopts SQL like language. Please see [1].

In our implementation, we also can adopt the same. For an example from the SPA it just need to send a query parameter like [2]

If so a request from SPA to our APIProxy will look like [3]

WDYT?

Best,
Thilina

[2] select name,age,city from https://some.third.party.api.com

On Fri, Nov 17, 2017 at 11:23 AM, Thilina Madumal <[hidden email]> wrote:
Hi Ruwan,


On Fri, Nov 17, 2017 at 11:20 AM, Ruwan Abeykoon <[hidden email]> wrote:
Hi Thilina,
Can you try implementing this with Ballerina. This should be a simple case for Ballerina.

Yep, I'm looking into it. 
 

Cheers,
Ruwan 

On Fri, Nov 17, 2017 at 11:16 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Fri, Nov 17, 2017 at 11:00 AM, roshan wijesena <[hidden email]> wrote:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

Actually this proxy has two parts, LoginProxy and APIProxy.
LoginProxy part do the authentication and autherization of the user on behalf of SPA.
APIProxy mediates the calls to third-party APIs as requested by the SPA by decrypting the access_token.

The ultimate goal is, when developing a SPA where there is no attached server-side, the devloper just needs to calll the necessary APIs of the proxy.
Then the proxy will do the rest.
 

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


Thanks,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Actually in our case the requests to third-party APIs the we get would look like the following,

https://wso2.is:9443/oauth_proxy/api_proxy?code="appIdCode"&query="get name:name,age:18,city:colombo from https://some.third.party.api.com"

https://wso2.is:9443/oauth_proxy/api_proxy?code="appIdCode"&query="post name:name,age:18,city:colombo from https://some.third.party.api.com"



On Fri, Nov 17, 2017 at 3:41 PM, Thilina Madumal <[hidden email]> wrote:
Hi all,

While researching I found the yahoo provides an API proxy service and it adopts SQL like language. Please see [1].

In our implementation, we also can adopt the same. For an example from the SPA it just need to send a query parameter like [2]

If so a request from SPA to our APIProxy will look like [3]

WDYT?

Best,
Thilina

[2] select name,age,city from https://some.third.party.api.com

On Fri, Nov 17, 2017 at 11:23 AM, Thilina Madumal <[hidden email]> wrote:
Hi Ruwan,


On Fri, Nov 17, 2017 at 11:20 AM, Ruwan Abeykoon <[hidden email]> wrote:
Hi Thilina,
Can you try implementing this with Ballerina. This should be a simple case for Ballerina.

Yep, I'm looking into it. 
 

Cheers,
Ruwan 

On Fri, Nov 17, 2017 at 11:16 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Fri, Nov 17, 2017 at 11:00 AM, roshan wijesena <[hidden email]> wrote:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

Actually this proxy has two parts, LoginProxy and APIProxy.
LoginProxy part do the authentication and autherization of the user on behalf of SPA.
APIProxy mediates the calls to third-party APIs as requested by the SPA by decrypting the access_token.

The ultimate goal is, when developing a SPA where there is no attached server-side, the devloper just needs to calll the necessary APIs of the proxy.
Then the proxy will do the rest.
 

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev





--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


Thanks,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Cyril Rognon-2
In reply to this post by roshan wijesena-2
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
In reply to this post by Cyril Rognon-2
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
+Dev list

On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

roshan wijesena-2
In reply to this post by Thilina Madumal
Hi Thilina,

My suggestion is, use something similar to that we have done in the APIM SPAs, or can ballerina doing something with this I am not sure?

Regards
Roshan


On Mon, Nov 20, 2017 at 4:31 PM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167





_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Prabath Siriwardena
In reply to this post by Thilina Madumal
Let me clarify what is solved by the encryption here..

Here the proxy uses the code grant type - and it gets access token + refresh token. Proxy can either store that at server side and replicate it across all the nodes - or store them in an encrypted cookie, and make things stateless..

Encryption is used here to make the application stateless - and the end user will not get access to the access token or the refresh token.

Then again, if someone finds the value stored in the session storage and then talk to the proxy API passing that along with all the encrypted cookies through its own app (say cURL).. it will not work... 

To make the above blocked - you need to have TLS channel binding between the browser and the proxy - and you need not to worry about APIs (whether they support channel binding or not)...

The other benefit proxy gives is support for CORS - you need not to worry whether the external APIs support CORS or not...

Thanks & regards,
-Prabath


On Sun, Nov 19, 2017 at 11:44 PM, Thilina Madumal <[hidden email]> wrote:
+Dev list

On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:+1%20650-625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

roshan wijesena-2
Thanks Prabath. 

It is clear now.

Regards
Roshan


On Mon, Nov 20, 2017 at 6:11 PM Prabath Siriwardena <[hidden email]> wrote:
Let me clarify what is solved by the encryption here..

Here the proxy uses the code grant type - and it gets access token + refresh token. Proxy can either store that at server side and replicate it across all the nodes - or store them in an encrypted cookie, and make things stateless..

Encryption is used here to make the application stateless - and the end user will not get access to the access token or the refresh token.

Then again, if someone finds the value stored in the session storage and then talk to the proxy API passing that along with all the encrypted cookies through its own app (say cURL).. it will not work... 

To make the above blocked - you need to have TLS channel binding between the browser and the proxy - and you need not to worry about APIs (whether they support channel binding or not)...

The other benefit proxy gives is support for CORS - you need not to worry whether the external APIs support CORS or not...

Thanks & regards,
-Prabath


On Sun, Nov 19, 2017 at 11:44 PM, Thilina Madumal <[hidden email]> wrote:
+Dev list

On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:+1%20650-625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi all,

Since we are clear with the concept behind the Proxy let's get back to the discussion of APIProxy implementation.

While researching I found that Yahoo provides an API proxy service and it adopts SQL like language. Please see [1].

In our implementation, we also can adopt the same. For an example from the SPA it just need to send a query parameter like [2]

If so a request from SPA to our APIProxy will look like [3]

WDYT?

[2] get name:name,age:18,city:colombo from https://some.third.party.api.com
[3] https://wso2.is:9443/oauth_proxy/api_proxy?code="appIdCode"&query="get name:name,age:18,city:colombo from https://some.third.party.api.com"

Thanks,
Thilina

On Mon, Nov 20, 2017 at 1:29 PM, roshan wijesena <[hidden email]> wrote:
Thanks Prabath. 

It is clear now.

Regards
Roshan


On Mon, Nov 20, 2017 at 6:11 PM Prabath Siriwardena <[hidden email]> wrote:
Let me clarify what is solved by the encryption here..

Here the proxy uses the code grant type - and it gets access token + refresh token. Proxy can either store that at server side and replicate it across all the nodes - or store them in an encrypted cookie, and make things stateless..

Encryption is used here to make the application stateless - and the end user will not get access to the access token or the refresh token.

Then again, if someone finds the value stored in the session storage and then talk to the proxy API passing that along with all the encrypted cookies through its own app (say cURL).. it will not work... 

To make the above blocked - you need to have TLS channel binding between the browser and the proxy - and you need not to worry about APIs (whether they support channel binding or not)...

The other benefit proxy gives is support for CORS - you need not to worry whether the external APIs support CORS or not...

Thanks & regards,
-Prabath


On Sun, Nov 19, 2017 at 11:44 PM, Thilina Madumal <[hidden email]> wrote:
+Dev list

On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:+1%20650-625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi all,

The following is the finalized approach for API-Proxy.

API-Proxy will act as a gateway which will pass the requests coming from the SPA-client to the corresponding backend API. 
Before passage acces_token will be included in the request header as follows,
"Authorization: Bearer <access_token>"

If I'm to explain this by using an example, it would look like the following.

request from SPA-client to the oauth2-proxy:  
<a href="https://hostA.com/oauth2-proxy/api/{app-session-code}/bar?name=lionels">https://hostA.com/oauth2-proxy/api/{app-session-code}/bar?name=lionels

request to the backend-api from the oauth2-proxy: 
-H "Authorization: Bearer <access_token>" https://hostB.com/bar?name=lionels

Here the host-mapping (hostA => hostB) is a configuration of the proxy.

Appreciate suggestions and amendments.

Best,
Thilina.


On Tue, Nov 21, 2017 at 12:48 PM, Thilina Madumal <[hidden email]> wrote:
Hi all,

Since we are clear with the concept behind the Proxy let's get back to the discussion of APIProxy implementation.

While researching I found that Yahoo provides an API proxy service and it adopts SQL like language. Please see [1].

In our implementation, we also can adopt the same. For an example from the SPA it just need to send a query parameter like [2]

If so a request from SPA to our APIProxy will look like [3]

WDYT?

[2] get name:name,age:18,city:colombo from https://some.third.party.api.com
[3] https://wso2.is:9443/oauth_proxy/api_proxy?code="appIdCode"&query="get name:name,age:18,city:colombo from https://some.third.party.api.com"

Thanks,
Thilina

On Mon, Nov 20, 2017 at 1:29 PM, roshan wijesena <[hidden email]> wrote:
Thanks Prabath. 

It is clear now.

Regards
Roshan


On Mon, Nov 20, 2017 at 6:11 PM Prabath Siriwardena <[hidden email]> wrote:
Let me clarify what is solved by the encryption here..

Here the proxy uses the code grant type - and it gets access token + refresh token. Proxy can either store that at server side and replicate it across all the nodes - or store them in an encrypted cookie, and make things stateless..

Encryption is used here to make the application stateless - and the end user will not get access to the access token or the refresh token.

Then again, if someone finds the value stored in the session storage and then talk to the proxy API passing that along with all the encrypted cookies through its own app (say cURL).. it will not work... 

To make the above blocked - you need to have TLS channel binding between the browser and the proxy - and you need not to worry about APIs (whether they support channel binding or not)...

The other benefit proxy gives is support for CORS - you need not to worry whether the external APIs support CORS or not...

Thanks & regards,
-Prabath


On Sun, Nov 19, 2017 at 11:44 PM, Thilina Madumal <[hidden email]> wrote:
+Dev list

On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[hidden email]> wrote:
Hi Roshan,


On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[hidden email]> wrote:
Hi Thilina,

How do you create this encrypted token? I agree with  NuwanD,  if you store that encrypted token in the browser, and if some one got that token he can

For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser.
 
access your protected backed via proxy call. The point is encrypted token seems not fixing the problem, which you trying to achieve.

So what do you suggest? 
You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client?
If so, what if this cookie is stolen? It is the same case right?
 

Regards
Roshan

On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

I still don't understand how encrypting this information makes the proxy stateless. What state would the proxy have to bear if this information was in plain text? Also why would you need to store the id_token on client side?

If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token.

In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy.

However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. 
 

Yes, encrypting the token and other info would prevent an attacker calling the APIs directly. But an attacker wouldn't be worried about calling the APIs directly. He would just call through the proxy, just like the SPA itself does.

If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we?

However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. 
 

Thanks,
NuwanD. 

On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[hidden email]> wrote:
Hi Nuwan,


On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[hidden email]> wrote:
Hi Thilina,

What do you gain by encrypting the token that is to be stored on the client side? Since the client does not seem to be doing any decryption before using the

FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether.
Token encrypted and stored in the client side to make the proxy stateless.
The Cookie that posesses these data is secured and HttpOnly.
 
token, theft of an encrypted token could be just as bad as the one in plain text isn't it?

All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs.
This way whoever steal the encrypted token, would not be able to call the third-party API directly.

On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy.

 

Thanks,
NuwanD.

On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

IS DCR is just fine and flexible. I was just referring to the SPA use case without server side proxy. 

If I understand correctly apim server is providing this proxy endpoint to handle token storage or decrypt. 

So far it seems there is no answer to replace the api-proxy scenario.

Maybe the dcr could "generate" some server side support endpoint :) ?

Thanks
Cyril


Le 18 nov. 2017 20:54, "roshan wijesena" <[hidden email]> a écrit :
Hi Cyril

Yes, I agree. AFAIK it uses a identity server DCR implementation to create a service provider and get a token on the fly.

Do you see any problems in that approach?

Regards 
Roshan



On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[hidden email]> wrote:
Hi Roshan,

I have looked at the APIM 3.0.0-M7 security ilmplementation for store and publisher SPAs and it seems that it is using password grant_type and using "server-side" endpoints provided by apim server /login/token/publisher or /login/token/store. 
Do you agree or did I miss something ?

Thanks
Cyril


2017-11-17 6:30 GMT+01:00 roshan wijesena <[hidden email]>:
Can you please explain more about this API-proxy ? is it only for decrypt the token?

APIM 3.0.X has SPA's for it's publisher and store apps, have a look at security implementation of it. AFAIK, there is a no API proxy in that implementation. 

On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[hidden email]> wrote:
Hi Devs,

The idea of an API-Proxy for Single Page Applications is quite helpful in mitigating inherent security risks of keeping the access_token in the browser side as plain text.

Here the idea is to keep the access_token encrypted and set in a cookie. API-Proxy will mediate all the calls for the third-party APIs by decrypting the access_token value and calling the requested third-party APIs with the decrypted access_token.

This is a significantly valuable use-case for the SPAs where there is no attached server-side other than the container which is used to facilitate the initial page download.

I'm in the requirement gathering phase. Would appreciate your suggestions on,
  • what are the nice to have capabilities in API-Proxy
  • what are the complexities that will arise while implementing this
  • how to achieve the third-party API call mediation
  • Is this a valid use-case
  • or is this a redundant effort
  • are there any alternatives
  • and etc.
This is an open invitation to shoot whatever pops into your mind in this regards:)

Thanks in advance.

Cheers,
Thilina
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Best, 

Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

Anyhow, if I'm missing anything here please correct me. 

In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1].
Also please refer the slides from 18 to 24 in the presentation [2].

Thanks and Best Regards,
Thilina

--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






Best,
Thilina.
--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+<a href="tel:077%20455%203167" value="+94774553167" target="_blank">94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:+1%20650-625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167






--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Youcef HILEM
In reply to this post by Thilina Madumal
Hi Thilina,

Could you please explain why APIM Gateway is not suitable?
How to integrate this feature in WSO2 APIM?
In our distributed architecture, we already have enough components and
adding another seems inappropriate.

Thanks
Youcef HILEM



--
Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Thilina Madumal
Hi Youcef,

This is not a replacement for APIM Gateway. APIM Gateway and this are two different things.
This is an implementation of the security pattern no. 17 described in blog 1.


Regards,
Thilina.

On Tue, Dec 12, 2017 at 12:48 AM, Youcef HILEM <[hidden email]> wrote:
Hi Thilina,

Could you please explain why APIM Gateway is not suitable?
How to integrate this feature in WSO2 APIM?
In our distributed architecture, we already have enough components and
adding another seems inappropriate.

Thanks
Youcef HILEM



--
Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: API-Proxy for Single Page Application

Cyril Rognon-2
Hi all,

Indeed as Thilinda is saying it is completely distinct from APIM gateway and it covers login/logout as well as api call.

It could be integrated into Identity Server : when you declare some SP then it could parameter and deploy the server-side proxy

deploy site(s) and HA will have to be dealt with.

Since you mention login over Oauth I assulme you are considering OpenIDConnect usage (from the proxy)?

Thanks
Cyril

2017-12-13 8:50 GMT+01:00 Thilina Madumal <[hidden email]>:
Hi Youcef,

This is not a replacement for APIM Gateway. APIM Gateway and this are two different things.
This is an implementation of the security pattern no. 17 described in blog 1.


Regards,
Thilina.

On Tue, Dec 12, 2017 at 12:48 AM, Youcef HILEM <[hidden email]> wrote:
Hi Thilina,

Could you please explain why APIM Gateway is not suitable?
How to integrate this feature in WSO2 APIM?
In our distributed architecture, we already have enough components and
adding another seems inappropriate.

Thanks
Youcef HILEM



--
Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Development-f3.html
_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



--
Thilina Madumal
Software Engineer | WSO2
Mobile: <a href="tel:+94%2077%20767%201807" value="+94777671807" style="color:rgb(17,85,204)" target="_blank">+94 774553167




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev



_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
12