Hi Sanjeewa, On Mon, Oct 30, 2017 at 1:51 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > On Sat, Oct 28, 2017 at 11:38 PM, Johann Nallathamby <[email protected]> > wrote: > >> Hi Sanjeewa, >> >> Thanks for the answers. >> >> So based on your answers seems like points 3 and 5 can be improved to >> support federated users better right? Have we considered this in APIM 3.0.0? >> > If we have federated users then anyway we might need to use extension for > do certain things. Yes in APIM 3Xx we will not remove any of the existing > capabilities. And we will specifically check federated user scenario. > It's not only about this JWT use case, but in general I would like to see if we have considered federated users also as first class users who will be consuming APIs through the API Gateway. Looks like we won't have a problem from APIM 3.x.x onwards. Regards, Johann. > Thanks, > sanjeewa. > >> >> Regards, >> Johann. >> >> On Mon, Oct 16, 2017 at 3:07 PM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> >>> >>> On Sun, Oct 15, 2017 at 9:35 PM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> Hi APIM Team, >>>> >>>> The API Security Handler is one of the key extension points and widely >>>> implemented extension points of the API Gateway architecture. I want to >>>> clarify if there are any limitations when implementing this extension >>>> point. >>>> >>>> Expectation is if the API Security Handler has been extended to do >>>> client authentication or user authentication in a customized way, still the >>>> API Throttling and API Analytics need to work as long as the necessary >>>> context information regarding the application and end user are populated by >>>> the authentication handler. >>>> >>>> 1. Will application throttling still work if we haven't used >>>> client_id/client_secret authentication to obtain OAuth2 access token? >>>> For example, Basicauth, JWT, X509 certs, IP whitelisting, etc. I think >>>> it should work as long as we have mapped whatever credential the >>>> application used to an application registered in API Manager. Correct? >>>> >>> Application level throttling will look into only application ID. As long >>> as you can populate authentication context from auth handler it will be >>> sufficient. If you can get API Manager application ID then it will be used >>> in throttling. For usage information consumer key is something we have >>> defined in request stream so we need to have some mapping there. But >>> throttling will work without any issue. >>> >>>> >>>> 2. Will end user analytics still work if we haven't issued the access >>>> token for a particular end user? >>>> For example consider the scenario where, the application gets an access >>>> token using client_credentials grant type, but the API Security Handler >>>> identifies the end user using a custom header in the API call, at the API >>>> Gateway. The gateway can only be reached by the application. >>>> >>> If we set authz user property in message context it will work without >>> issue. That user name we set will directly go to analytics and summarized. >>> It may not effect publisher dashboards as we can populate publisher and >>> application ID properly. >>> >>>> >>>> How does throttling and analytics extend to federated users? >>>> >>>> 3. The JWT based throttling capability we have, seems to be tightly >>>> coupled to the Key Manager's own JWT. It seems we cannot to use an external >>>> JWT and do advanced throttling. Which means this won't work for federated >>>> users. >>>> >>> We are reading claims from X-JWT-Assertion header and if auth handler >>> can set that header it will work. However if JWT format is different than >>> what we expect in throttle handler then we need to reconstruct >>> X-JWT-Assertion header. Even if we have federated users if we populate auth >>> context properly. >>> >>>> >>>> 4. If the access token was issued for a federated user using SAML2 or >>>> OpenID Connect protocol in IS as KM, for users who are not in the IS >>>> userstore, does the end user analytics still work for them? >>>> >>>> 5. Also on a different note, can we now enable JWT generation in the >>>> Key Manager when there is a requirement for local users and federated users >>>> to login? I remember sometime back there was an issue when JWT generation >>>> is enabled and federated users login. I think the issue was because the JWT >>>> generator goes and tries to find a user in the local user store and fails. >>>> >>> If we are using default JWT generator then it will connect current user >>> store manager and try to populate claims. But if we can have custom JWT >>> generator we can control this behavior and populate claims only user >>> present in user store connected. So if its federated user then populate >>> standard claims will be failed and we need to handle it. >>> >>> Thanks, >>> sanjeewa. >>> >>>> >>>> Thanks & Regards, >>>> Johann. >>>> >>>> -- >>>> >>>> *Johann Dilantha Nallathamby* >>>> Senior Lead Solutions Engineer >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <+94%2071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
