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. 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 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
