@Chamod Samarajeewa <cha...@wso2.com> 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 <hars...@wso2.com> wrote: > > > On Fri, Mar 8, 2019 at 3:26 AM 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? >> > 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 <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] >> _______________________________________________ >> 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 > -- *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
