On Mon, Dec 16, 2019 at 9:09 PM Rajith Roshan <[email protected]> wrote:
> > > On Mon, Dec 16, 2019 at 7:57 PM Harsha Kumara <[email protected]> wrote: > >> >> >> On Mon, Dec 16, 2019 at 7:01 PM Rajith Roshan <[email protected]> wrote: >> >>> Hi all, >>> Microgateway 3.0.x versions support for opaque oauth2 token are tightly >>> bound with APIM key manager component. Right now it validates token using >>> the key validation service of APIM, which does the token validation, scope >>> validation, subscription validation (and back end jwt generation if >>> enabled). >>> >>> We will need to provide a way to plug microgateway with an oauth2 server >>> with standard introspect endpoint for token validation. Following >>> limitations would incur due to the usage of standard introspection. >>> >>> 1. Subscription validation can not be enforced. >>> 2. Rate limiting using application level throttling >>> 3. Rate limiting using subscription level throttling >>> 4. Completeness of analytics dashboard data >>> >>> These are the same limitations, we have when we use a self contains jwt >>> token from a third party key manager(STS). >>> >>> The key manager configuration of the microgateway is below[1]. We can >>> add an additional parameter[2] to specify to use an external key manager >>> instead of the WSO2 key manager. >>> >> Can we check the authentication section of RFC for the introspection >> endpoint and allow flexibility to configure the possible authentication >> mechanism. Basic authentication is basic. But some might use special bearer >> token or the clientId. Can we check[1] and provide the flexibility to use >> standard authentication for introspection. >> > The idea here is to support the standard introspection for the token > validation in the microgateway. When request comes to the microgateway with > bearer header it will validate the token using the standard introspect > endpoint. And also it will support wso2 key manager(APIM) token validation > as well if external key managers are not used > Yes that's correct. The introspection API is protected with different authentication mechanisms by different providers. Just wanted to check whether there are any standard types such as protected with client Id and etc and check on the feasibility of giving those options. > >> [1] >> >>> >>> Please share your thoughts regarding this. >>> >>> [1] - [keyManager] >>> serverUrl="https://localhost:9443"; >>> username="admin" // to connect with key validation admin service >>> password="admin" >>> tokenContext="oauth2" >>> timestampSkew=5000 >>> >>> [2] - [keyManager] >>> serverUrl="https://localhost:9443"; >>> username="admin" // to connect with key validation admin service >>> password="admin" >>> tokenContext="oauth2" >>> timestampSkew=5000 >>> external = true >>> >>> -- >>> *Rajith Roshan* | Associate Technical Lead | WSO2 Inc. >>> (m) +94-717-064-214 | (e) [email protected] <[email protected]> >>> blog: http://www.rajithr.com >>> >>> <https://wso2.com/signature> >>> >> >> >> -- >> >> *Harsha Kumara* >> >> Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: [email protected] >> Blog: harshcreationz.blogspot.com >> >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > *Rajith Roshan* | Associate Technical Lead | WSO2 Inc. > (m) +94-717-064-214 | (e) [email protected] <[email protected]> > blog: http://www.rajithr.com > > <https://wso2.com/signature> > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: [email protected] Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
