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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
