[APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

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

[APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Johann Nallathamby
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Vanjikumaran Sivajothy
If just the token authentication handlers in the gateway and filters in micro gateway are the way to go. However, if the expectation is integrated seamless flow with developer market place experience. There is an improvement in the store to obtain the tokens and generate directly from the 3rd party IDP.

On Wed, Mar 6, 2019 at 11:24 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
1G

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Nuwan Dias
In reply to this post by Johann Nallathamby
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Harsha Kumara-2
If they do not want to use our KM, they can simply write a handler and achieve the requirement. 

On Thu, Mar 7, 2019 at 3:40 AM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Johann Nallathamby
In reply to this post by Nuwan Dias
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Johann Nallathamby
In reply to this post by Harsha Kumara-2
+1 Harsha. I am just trying to see if gateway extension are an option at all or are there any limitations we need to be aware of. So now I understand from Nuwan's reply, that gateway extensions are a possibility as long as we understand its limitations and willing to forgo.

Regards,
Johann.

On Fri, Mar 8, 2019 at 1:54 PM Harsha Kumara <[hidden email]> wrote:
If they do not want to use our KM, they can simply write a handler and achieve the requirement. 

On Thu, Mar 7, 2019 at 3:40 AM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Harsha Kumara-2
In reply to this post by Johann Nallathamby


On Fri, Mar 8, 2019 at 3:26 AM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
Yes 
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Nuwan Dias
In reply to this post by Johann Nallathamby
I don't think we need to complicate this anymore. We all know the downsides of having too many options to do the same thing in slightly different ways.

The reason you're seeing this as "Gateway" AND "Key Manager" is because you are thinking in terms of profiles. But if you look at it from a single product point of view what we simply have is API Manager integration with third part IDP. When someone implements the interfaces they are simply implementing API Manager interfaces not Gateway interfaces nor Key Manager interfaces. So even if someone wants to do a subscription validation at the point of validating the token they simply have to implement the relevant interface method and deploy on the gateway itself. There's no need to deploy additional nodes or anything like that just because this code is executed on the Key Manager profile. The only downside of this approach is that you would need to run the gateway in the default profile. Which I think is a good trade off rather than complicating the product than it already is.

Thanks,
NuwanD.

On Fri, Mar 8, 2019 at 1:56 PM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Harsha Kumara-2
In reply to this post by Harsha Kumara-2
[hidden email] can you share current implementation details? Is you basic authentication handler, I assume you calling token endpoint with hard coded consumer key and password. We should be able to support Johann's suggestion with Option 1.

On Fri, Mar 8, 2019 at 3:30 AM Harsha Kumara <[hidden email]> wrote:


On Fri, Mar 8, 2019 at 3:26 AM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
Yes 
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Harsha Kumara-2
In reply to this post by Nuwan Dias
Please ignore my previous reply.

On Fri, Mar 8, 2019 at 3:45 AM Nuwan Dias <[hidden email]> wrote:
I don't think we need to complicate this anymore. We all know the downsides of having too many options to do the same thing in slightly different ways.

The reason you're seeing this as "Gateway" AND "Key Manager" is because you are thinking in terms of profiles. But if you look at it from a single product point of view what we simply have is API Manager integration with third part IDP. When someone implements the interfaces they are simply implementing API Manager interfaces not Gateway interfaces nor Key Manager interfaces. So even if someone wants to do a subscription validation at the point of validating the token they simply have to implement the relevant interface method and deploy on the gateway itself. There's no need to deploy additional nodes or anything like that just because this code is executed on the Key Manager profile. The only downside of this approach is that you would need to run the gateway in the default profile. Which I think is a good trade off rather than complicating the product than it already is.

Thanks,
NuwanD.

On Fri, Mar 8, 2019 at 1:56 PM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Johann Nallathamby
[hidden email] did they give you too much wine in the plane 😂?

On Fri, Mar 8, 2019 at 2:18 PM Harsha Kumara <[hidden email]> wrote:
Please ignore my previous reply.

On Fri, Mar 8, 2019 at 3:45 AM Nuwan Dias <[hidden email]> wrote:
I don't think we need to complicate this anymore. We all know the downsides of having too many options to do the same thing in slightly different ways.

The reason you're seeing this as "Gateway" AND "Key Manager" is because you are thinking in terms of profiles. But if you look at it from a single product point of view what we simply have is API Manager integration with third part IDP. When someone implements the interfaces they are simply implementing API Manager interfaces not Gateway interfaces nor Key Manager interfaces. So even if someone wants to do a subscription validation at the point of validating the token they simply have to implement the relevant interface method and deploy on the gateway itself. There's no need to deploy additional nodes or anything like that just because this code is executed on the Key Manager profile. The only downside of this approach is that you would need to run the gateway in the default profile. Which I think is a good trade off rather than complicating the product than it already is.

Thanks,
NuwanD.

On Fri, Mar 8, 2019 at 1:56 PM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] Supporting 3rd Party Key Manager Integrations at API Gateway

Harsha Kumara-2
Was checking on both the mails. :) 

On Fri, Mar 8, 2019 at 3:49 AM Johann Nallathamby <[hidden email]> wrote:
[hidden email] did they give you too much wine in the plane 😂?

On Fri, Mar 8, 2019 at 2:18 PM Harsha Kumara <[hidden email]> wrote:
Please ignore my previous reply.

On Fri, Mar 8, 2019 at 3:45 AM Nuwan Dias <[hidden email]> wrote:
I don't think we need to complicate this anymore. We all know the downsides of having too many options to do the same thing in slightly different ways.

The reason you're seeing this as "Gateway" AND "Key Manager" is because you are thinking in terms of profiles. But if you look at it from a single product point of view what we simply have is API Manager integration with third part IDP. When someone implements the interfaces they are simply implementing API Manager interfaces not Gateway interfaces nor Key Manager interfaces. So even if someone wants to do a subscription validation at the point of validating the token they simply have to implement the relevant interface method and deploy on the gateway itself. There's no need to deploy additional nodes or anything like that just because this code is executed on the Key Manager profile. The only downside of this approach is that you would need to run the gateway in the default profile. Which I think is a good trade off rather than complicating the product than it already is.

Thanks,
NuwanD.

On Fri, Mar 8, 2019 at 1:56 PM Johann Nallathamby <[hidden email]> wrote:
Hi Nuwan,

On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <[hidden email]> wrote:
There are several reasons.

1) It is not just the gateway but also the store that needs to communicate with the IDP. So the integration point cannot be the gateway alone.

Correct. So when we do integrations in the current model we have, do we not need to integrate the API store with the 3rd party key manager? Are you saying the API store works as it is with our key manager, and the key manager extension takes care of all integrations with the 3rd party? As a percentage how many percent of times we needed to customize the API store for 3rd party integrations? Can you give some examples of when we needed to customize the API store?

One use case I came across was to integrate multiple key managers to the API store. In that case I believe we need to customize the store. Or may be still there is some way you can hide the number of 3rd party key managers, from the WSO2 key manager interface?
 
2) Most customers sill want to validate the subscription in addition to validating the token. The IDP will validate the token but APIM will have to validate the subscription. The gateway cannot validate the subscription directly since it requires access to the DB on which this data is stored. 

Ok. This is a good point. So I understand to cater this we need to go through our key manager.
Just a thought. Can we give 2 options here:
1. For customers who want to validate subscription they can proxy only the validation call through our key manager.
2. For customers who don't want to validate subscriptions they can directly call the 3rd party key manager. This percentage could be quite low as I understand.
May be there is no code changes required here. But it could be our guideline. What do you think?

I haven't done a key manager extension myself. But as far as the runtime validation extension goes, what I understand is that it should be simple as one API call. The gateway calls the WSO2 key manager's validation API, which internally calls the 3rd party key manager's introspection API, gets the response, validates it, validates the subscription in the database, and returns validation response to gateway. Correct?
I will check on the 3rd party key manager extension sample and get back if I find anything more complicated than this.

 
3) Scopes are also not always supported by all IDPs and even when they do only very few IDPs can map a resource against a scope. While standard IDPs support introspection of tokens there is no such standard for validating whether a given token bears the required scope to access a resource. Therefore we again need to perform this validation on APIM. And in order to do that you again have to get access to the storage where this information is stored. The gateway in most cases doesn't have access to the storage layer of APIM.

Ok. So this also should be covered by the validation call to the key manager in option 1 above. We can also add scope validation to our guideline of when to propose key manager extension.

Thanks & Regards,
Johann.
 

On Thu, Mar 7, 2019 at 12:54 AM Johann Nallathamby <[hidden email]> wrote:
APIM Team,

I would like to understand what was the original reason we went with a 3rd party key manager extension in our key manager component, rather than giving the extensibility to integrate a 3rd party key manager at the gateway itself.

What are the problems in supporting 3rd party Key Manager integrations directly from the API Gateway; avoiding the WSO2 Key Manager at all. We can provide a well designed OAuth2 security handler on the gateway, with template methods to extend and integrate 3rd party KMs?

Pros:
1. Taking advantage of standards such as OAuth2/OpenID Connect which are supported by many vendors already, will reduce developer effort to understand protocols, will reduce development time and increase reusability. I feel like we are just complicating the process by going through a constricted API layer.
2. Higher level SPIs like handlers in the gateway are much easier to understand and more people have worked with those SPIs already for other purposes.
3. It gives you more flexibility to integrate with key manager, because there is more contextual information available in gateway.
E.g. recently in a customer engagement I came across the requirement to integrate with multiple 3rd party key managers, based on hostname of the API request, using one gateway handler extension.
4. It is seen as a security vulnerability to share the access tokens and refresh tokens via a 3rd part component in between client and actual token provider.
5. We don't need to have our key manager in the deployment if we can directly integrate with the 3rd party key manager, which saves running cost for the customer.

Cons:
1. The contract of the handler may not be as clear as the key manager extension, because it is a more generic extension than the key manager extension; the key manager extension could be more tighter. But this can be improved by design patterns. 

I believe the pros out weigh the cons. If you think the key manager extension point is also important, then we can have two levels of extension points, and choose depending on what we think is the best for the requirement.

What is your opinion on this?

Thanks & Regards,
Johann.

--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Nuwan Dias | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) [hidden email]
Signature.jpg
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business


--
Johann Dilantha Nallathamby | Associate Director/Solutions Architect | WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [hidden email]
Signature.jpg


--
Harsha Kumara

Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture