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