On Fri, Mar 8, 2019 at 3:26 AM 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? > 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 <[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] > _______________________________________________ > 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
