Was checking on both the mails. :) On Fri, Mar 8, 2019 at 3:49 AM Johann Nallathamby <joh...@wso2.com> wrote:
> @Harsha Kumara <hars...@wso2.com> did they give you too much wine in the > plane 😂? > > On Fri, Mar 8, 2019 at 2:18 PM Harsha Kumara <hars...@wso2.com> wrote: > >> Please ignore my previous reply. >> >> On Fri, Mar 8, 2019 at 3:45 AM Nuwan Dias <nuw...@wso2.com> 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 <joh...@wso2.com> >>> wrote: >>> >>>> Hi Nuwan, >>>> >>>> On Thu, Mar 7, 2019 at 2:09 PM Nuwan Dias <nuw...@wso2.com> 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 <joh...@wso2.com> >>>>> 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) joh...@wso2.com >>>>>> [image: Signature.jpg] >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>>>> [image: Signature.jpg] >>>>> >>>> >>>> >>>> -- >>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>>> | WSO2 Inc. >>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>>> [image: Signature.jpg] >>>> >>> >>> >>> -- >>> *Nuwan Dias* | Director | WSO2 Inc. >>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>> [image: Signature.jpg] >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> >> *Harsha Kumara* >> >> Associate Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: hars...@wso2.coim >> 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) joh...@wso2.com > [image: Signature.jpg] > -- *Harsha Kumara* Associate Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: hars...@wso2.coim Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
