+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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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) [email protected] >>> [image: Signature.jpg] >>> >> >> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) [email protected] >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > > *Harsha Kumara* > > Associate Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: [email protected] > 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) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
