@Harsha Kumara <[email protected]> did they give you too much wine in the plane 😂?
On Fri, Mar 8, 2019 at 2:18 PM Harsha Kumara <[email protected]> wrote: > Please ignore my previous reply. > > On Fri, Mar 8, 2019 at 3:45 AM Nuwan Dias <[email protected]> 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 <[email protected]> >> wrote: >> >>> Hi Nuwan, >>> >>> On Thu, Mar 7, 2019 at 2:09 PM 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. >>>> >>> >>> 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 <[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] >>>> >>> >>> >>> -- >>> *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
