Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi all,

As per an offline discussion with Rajith, we decided to add STS
configurations (user, APIs ..) configurations to the existing micro-gw.conf
as below.

##
# Basic auth users
[b7a.users]
[b7a.users.generalUser1]
password="5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"

###
# API Key STS token configs
[apikey.issuer.tokenConfig]
keyStorePath="${ballerina.home}/bre/security/ballerinaKeystore.p12"
keyStorePassword="ballerina"
keyStoreAlias="ballerina"
issuer="https://localhost:9443/oauth2/token;
audience="http://org.wso2.apimgt/gateway;
validityPeriod=600

###
# API Key STS Allowed APIs
[apikey.issuer.apis]
[apikey.issuer.apis.1]
name="Swagger Petstore New"
basepath="pizzashack"
versions="1.0.0, v1, v2"
[apikey.issuer.apis.2]
name="MyAPI"
basepath="myapi"
versions="*"

Please let me know any suggestions or concerns. Thanks.

On Fri, Jan 3, 2020 at 5:45 PM Amali Matharaarachchi 
wrote:

> Hi all,
>
> A new config file will be added for the STS configurations. This
> api-key-issuer.conf file will be similar to the following.
>
> [tokenconfig]
> validityPeriod=600
>
> [users]
> [users.generalUser1]
> password="5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"
> [users.user2]
> password="5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"
>
> [apis]
> [apis.PizzaShackAPI]
> basepath="pizzashack"
> versions=["v1", "v2"]
> [apis.PetStore]
> basepath="petstore"
> versions=["1.0.0"]
>
>
> The above users will be used to authenticate the API key issuing request
> with basic authorization. API Keys with subscribed API list will be issued
> for the above APIs.
> Please let me know any suggestions or concerns regarding the above
> configuration.
>
> Thanks,
> Amali
>
> On Mon, Dec 16, 2019 at 3:36 PM Amali Matharaarachchi 
> wrote:
>
>> Nuwan, Rajith and I had an internal discussion on API Key issuing feature.
>> Please find the summary below.
>>
>> 1. Add new config value to enable subscription validation for API Key. It
>> would be disabled by default.
>> 2. No need to differentiate API Key even if it is provided as a bearer
>> token. Hence, remove API Key additional claim "apiKey”.
>> 3. Enable apikey as a security schema in api definition. If only apikey
>> is defined as a security schema in api, it can be invoked with API
>> key header.
>> 4. Provide a lightweight STS for api key generation.
>>
>>- Provide new endpoint for API key issuer.
>>https://localhost:9095/apikey
>>- Provide a new config file to configure users and apis for STS.
>>
>> 5. User authentication is not needed for api invocation with the API key.
>>
>> We appreciate your thoughts on this.
>> Thanks.
>>
>> On Mon, Dec 16, 2019 at 10:16 AM Amali Matharaarachchi 
>> wrote:
>>
>>> API Key will come in apiKey header or query parameters.  Hence I don't
 see a problem of differentiating them.
>>>
>>> If someone tries to use the API Key as a bearer token, we need to
>>> identify this as a misusage.
>>>
>>> On Fri, Dec 13, 2019 at 10:13 PM Harsha Kumara  wrote:
>>>


 On Fri, Dec 13, 2019 at 11:34 AM Amali Matharaarachchi 
 wrote:

> Hi all,
>
> I have several concerns regarding the current approach. I highly
> appreciate your suggestions. @Rajith Roshan  Please
> add if I have missed out anything.
>
> 1. How to differentiate the API Key and JWT token.
> API Key issued from the Microgateway has additional claim "apikey:
> true". This claim will be used to recognize if it is an API Key when an 
> API
> Key is given as bearer authorization.
> However, an API Key and a JWT token released from API Manager cannot
> be differentiated in Microgateway.
>
 API Key will come in apiKey header or query parameters.  Hence I don't
 see a problem of differentiating them.

>
> 2. Add an adequate level of security to API Key issued from
> Microgateway.
> We validate the user given in the subject claim of the API Key. The
> invocation request will be authorized if only the subjected user is
> configured in the gateway which received the API invocation request.
>
 Since configuring users isn't scalable solution, did we look for any
 alternatives?

>
> 3. Add a list of APIs to the API Key to indicate which APIs can be
> accessed from the issued API Key.
> This is not addressed by the current implementation. Beforehand there
> is a couple of concerns we need to address for cases such as load-balanced
> micro gateways.
>
> 4. Issues on API Key with Load balancing.
> When a API Key is requested with basic auth, some gateway which can
> authorize the request would answer the call and issue an API Key. We do 
> not
> control which gateway will answer this request. This is a blocker to

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi all,

A new config file will be added for the STS configurations. This
api-key-issuer.conf file will be similar to the following.

[tokenconfig]
validityPeriod=600

[users]
[users.generalUser1]
password="5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"
[users.user2]
password="5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8"

[apis]
[apis.PizzaShackAPI]
basepath="pizzashack"
versions=["v1", "v2"]
[apis.PetStore]
basepath="petstore"
versions=["1.0.0"]


The above users will be used to authenticate the API key issuing request
with basic authorization. API Keys with subscribed API list will be issued
for the above APIs.
Please let me know any suggestions or concerns regarding the above
configuration.

Thanks,
Amali

On Mon, Dec 16, 2019 at 3:36 PM Amali Matharaarachchi 
wrote:

> Nuwan, Rajith and I had an internal discussion on API Key issuing feature.
> Please find the summary below.
>
> 1. Add new config value to enable subscription validation for API Key. It
> would be disabled by default.
> 2. No need to differentiate API Key even if it is provided as a bearer
> token. Hence, remove API Key additional claim "apiKey”.
> 3. Enable apikey as a security schema in api definition. If only apikey is
> defined as a security schema in api, it can be invoked with API key header.
> 4. Provide a lightweight STS for api key generation.
>
>- Provide new endpoint for API key issuer.
>https://localhost:9095/apikey
>- Provide a new config file to configure users and apis for STS.
>
> 5. User authentication is not needed for api invocation with the API key.
>
> We appreciate your thoughts on this.
> Thanks.
>
> On Mon, Dec 16, 2019 at 10:16 AM Amali Matharaarachchi 
> wrote:
>
>> API Key will come in apiKey header or query parameters.  Hence I don't
>>> see a problem of differentiating them.
>>
>> If someone tries to use the API Key as a bearer token, we need to
>> identify this as a misusage.
>>
>> On Fri, Dec 13, 2019 at 10:13 PM Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Fri, Dec 13, 2019 at 11:34 AM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi all,

 I have several concerns regarding the current approach. I highly
 appreciate your suggestions. @Rajith Roshan  Please
 add if I have missed out anything.

 1. How to differentiate the API Key and JWT token.
 API Key issued from the Microgateway has additional claim "apikey:
 true". This claim will be used to recognize if it is an API Key when an API
 Key is given as bearer authorization.
 However, an API Key and a JWT token released from API Manager cannot be
 differentiated in Microgateway.

>>> API Key will come in apiKey header or query parameters.  Hence I don't
>>> see a problem of differentiating them.
>>>

 2. Add an adequate level of security to API Key issued from
 Microgateway.
 We validate the user given in the subject claim of the API Key. The
 invocation request will be authorized if only the subjected user is
 configured in the gateway which received the API invocation request.

>>> Since configuring users isn't scalable solution, did we look for any
>>> alternatives?
>>>

 3. Add a list of APIs to the API Key to indicate which APIs can be
 accessed from the issued API Key.
 This is not addressed by the current implementation. Beforehand there
 is a couple of concerns we need to address for cases such as load-balanced
 micro gateways.

 4. Issues on API Key with Load balancing.
 When a API Key is requested with basic auth, some gateway which can
 authorize the request would answer the call and issue an API Key. We do not
 control which gateway will answer this request. This is a blocker to
 achieve the 3rd option.
 Also, we do not control which gateway will handle the API invocation
 request. The gateway which answers the API invocation call can authorize
 the request only after validating the user with its own user
 configurations. Hence ideally, the user configurations should be identical
 in gateways.

 Kindly let me know your thoughts. Thank you.

 On Mon, Dec 9, 2019 at 5:06 PM Amali Matharaarachchi 
 wrote:

> Hi,
> If someone used this API Key in authorization bearer header, it will
> work just like another JWT token. To avoid this, we need to differentiate
> API Key and other JWTs. Even if we provide a separate header for the API
> Key, the above issue will not be solved.
>
> On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:
>
>> Ok, this should be because we are using a different header than the
>> authentication header for API Key in synapse gateway. I assume what we 
>> are
>> trying here is to use both types of tokens in the authentication header?
>>
>> On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana <
>> prami...@wso2.com> wrote:
>>
>>> It didn't look like synapse gateway did a differentiation between

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Nuwan, Rajith and I had an internal discussion on API Key issuing feature.
Please find the summary below.

1. Add new config value to enable subscription validation for API Key. It
would be disabled by default.
2. No need to differentiate API Key even if it is provided as a bearer
token. Hence, remove API Key additional claim "apiKey”.
3. Enable apikey as a security schema in api definition. If only apikey is
defined as a security schema in api, it can be invoked with API key header.
4. Provide a lightweight STS for api key generation.

   - Provide new endpoint for API key issuer. https://localhost:9095/apikey
   - Provide a new config file to configure users and apis for STS.

5. User authentication is not needed for api invocation with the API key.

We appreciate your thoughts on this.
Thanks.

On Mon, Dec 16, 2019 at 10:16 AM Amali Matharaarachchi 
wrote:

> API Key will come in apiKey header or query parameters.  Hence I don't see
>> a problem of differentiating them.
>
> If someone tries to use the API Key as a bearer token, we need to identify
> this as a misusage.
>
> On Fri, Dec 13, 2019 at 10:13 PM Harsha Kumara  wrote:
>
>>
>>
>> On Fri, Dec 13, 2019 at 11:34 AM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have several concerns regarding the current approach. I highly
>>> appreciate your suggestions. @Rajith Roshan  Please
>>> add if I have missed out anything.
>>>
>>> 1. How to differentiate the API Key and JWT token.
>>> API Key issued from the Microgateway has additional claim "apikey:
>>> true". This claim will be used to recognize if it is an API Key when an API
>>> Key is given as bearer authorization.
>>> However, an API Key and a JWT token released from API Manager cannot be
>>> differentiated in Microgateway.
>>>
>> API Key will come in apiKey header or query parameters.  Hence I don't
>> see a problem of differentiating them.
>>
>>>
>>> 2. Add an adequate level of security to API Key issued from Microgateway.
>>> We validate the user given in the subject claim of the API Key. The
>>> invocation request will be authorized if only the subjected user is
>>> configured in the gateway which received the API invocation request.
>>>
>> Since configuring users isn't scalable solution, did we look for any
>> alternatives?
>>
>>>
>>> 3. Add a list of APIs to the API Key to indicate which APIs can be
>>> accessed from the issued API Key.
>>> This is not addressed by the current implementation. Beforehand there is
>>> a couple of concerns we need to address for cases such as load-balanced
>>> micro gateways.
>>>
>>> 4. Issues on API Key with Load balancing.
>>> When a API Key is requested with basic auth, some gateway which can
>>> authorize the request would answer the call and issue an API Key. We do not
>>> control which gateway will answer this request. This is a blocker to
>>> achieve the 3rd option.
>>> Also, we do not control which gateway will handle the API invocation
>>> request. The gateway which answers the API invocation call can authorize
>>> the request only after validating the user with its own user
>>> configurations. Hence ideally, the user configurations should be identical
>>> in gateways.
>>>
>>> Kindly let me know your thoughts. Thank you.
>>>
>>> On Mon, Dec 9, 2019 at 5:06 PM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi,
 If someone used this API Key in authorization bearer header, it will
 work just like another JWT token. To avoid this, we need to differentiate
 API Key and other JWTs. Even if we provide a separate header for the API
 Key, the above issue will not be solved.

 On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:

> Ok, this should be because we are using a different header than the
> authentication header for API Key in synapse gateway. I assume what we are
> trying here is to use both types of tokens in the authentication header?
>
> On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
> wrote:
>
>> It didn't look like synapse gateway did a differentiation between
>> these two cases. +Rajith Roshan   tested it. API
>> Key didn't work in Auth header simply because there was a missing 
>> attribute
>> in the JWT. It doesn't result in "Invalid JWT token" or similar error as
>> expected.
>>
>> On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem 
>> wrote:
>>
>>> We should be identifying both separately already in the synapse
>>> gateway. Have you checked how it has been done and stick to the same if
>>> possible for consistency?
>>>
>>> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi <
>>> ama...@wso2.com> wrote:
>>>
 Hi all,

 We need to differentiate the API Key from a normal JWT token. The
 API Key is a simple JWT but when an API Key is provided we need to
 authenticate the user as well.
 For this purpose, we added the additional claim "apiKey" to the
 issuing JWT. 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

>
> API Key will come in apiKey header or query parameters.  Hence I don't see
> a problem of differentiating them.

If someone tries to use the API Key as a bearer token, we need to identify
this as a misusage.

On Fri, Dec 13, 2019 at 10:13 PM Harsha Kumara  wrote:

>
>
> On Fri, Dec 13, 2019 at 11:34 AM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>>
>> I have several concerns regarding the current approach. I highly
>> appreciate your suggestions. @Rajith Roshan  Please
>> add if I have missed out anything.
>>
>> 1. How to differentiate the API Key and JWT token.
>> API Key issued from the Microgateway has additional claim "apikey: true".
>> This claim will be used to recognize if it is an API Key when an API Key is
>> given as bearer authorization.
>> However, an API Key and a JWT token released from API Manager cannot be
>> differentiated in Microgateway.
>>
> API Key will come in apiKey header or query parameters.  Hence I don't see
> a problem of differentiating them.
>
>>
>> 2. Add an adequate level of security to API Key issued from Microgateway.
>> We validate the user given in the subject claim of the API Key. The
>> invocation request will be authorized if only the subjected user is
>> configured in the gateway which received the API invocation request.
>>
> Since configuring users isn't scalable solution, did we look for any
> alternatives?
>
>>
>> 3. Add a list of APIs to the API Key to indicate which APIs can be
>> accessed from the issued API Key.
>> This is not addressed by the current implementation. Beforehand there is
>> a couple of concerns we need to address for cases such as load-balanced
>> micro gateways.
>>
>> 4. Issues on API Key with Load balancing.
>> When a API Key is requested with basic auth, some gateway which can
>> authorize the request would answer the call and issue an API Key. We do not
>> control which gateway will answer this request. This is a blocker to
>> achieve the 3rd option.
>> Also, we do not control which gateway will handle the API invocation
>> request. The gateway which answers the API invocation call can authorize
>> the request only after validating the user with its own user
>> configurations. Hence ideally, the user configurations should be identical
>> in gateways.
>>
>> Kindly let me know your thoughts. Thank you.
>>
>> On Mon, Dec 9, 2019 at 5:06 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi,
>>> If someone used this API Key in authorization bearer header, it will
>>> work just like another JWT token. To avoid this, we need to differentiate
>>> API Key and other JWTs. Even if we provide a separate header for the API
>>> Key, the above issue will not be solved.
>>>
>>> On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:
>>>
 Ok, this should be because we are using a different header than the
 authentication header for API Key in synapse gateway. I assume what we are
 trying here is to use both types of tokens in the authentication header?

 On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
 wrote:

> It didn't look like synapse gateway did a differentiation between
> these two cases. +Rajith Roshan   tested it. API
> Key didn't work in Auth header simply because there was a missing 
> attribute
> in the JWT. It doesn't result in "Invalid JWT token" or similar error as
> expected.
>
> On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:
>
>> We should be identifying both separately already in the synapse
>> gateway. Have you checked how it has been done and stick to the same if
>> possible for consistency?
>>
>> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> We need to differentiate the API Key from a normal JWT token. The
>>> API Key is a simple JWT but when an API Key is provided we need to
>>> authenticate the user as well.
>>> For this purpose, we added the additional claim "apiKey" to the
>>> issuing JWT. If it is present in the token, it will be recognized as an
>>> API Key.
>>> I highly appreciate if you have any suggestions regarding this.
>>>
>>> Thanks.
>>>
>>> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi <
>>> ama...@wso2.com> wrote:
>>>
 Hi Harsha,

 Will the token endpoint is default one and provide an option to
> point to the key manager in a standard deployment?


 Configurations similar to the following are added to micro-gw.conf
 file to enable the self JWT issuer and to provide related 
 configurations
 [1].

 [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
 [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"



> What's the endpoint that we going to provide and 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Harsha Kumara]

On Fri, Dec 13, 2019 at 11:34 AM Amali Matharaarachchi 
wrote:

> Hi all,
>
> I have several concerns regarding the current approach. I highly
> appreciate your suggestions. @Rajith Roshan  Please add
> if I have missed out anything.
>
> 1. How to differentiate the API Key and JWT token.
> API Key issued from the Microgateway has additional claim "apikey: true".
> This claim will be used to recognize if it is an API Key when an API Key is
> given as bearer authorization.
> However, an API Key and a JWT token released from API Manager cannot be
> differentiated in Microgateway.
>
API Key will come in apiKey header or query parameters.  Hence I don't see
a problem of differentiating them.

>
> 2. Add an adequate level of security to API Key issued from Microgateway.
> We validate the user given in the subject claim of the API Key. The
> invocation request will be authorized if only the subjected user is
> configured in the gateway which received the API invocation request.
>
Since configuring users isn't scalable solution, did we look for any
alternatives?

>
> 3. Add a list of APIs to the API Key to indicate which APIs can be
> accessed from the issued API Key.
> This is not addressed by the current implementation. Beforehand there is a
> couple of concerns we need to address for cases such as load-balanced micro
> gateways.
>
> 4. Issues on API Key with Load balancing.
> When a API Key is requested with basic auth, some gateway which can
> authorize the request would answer the call and issue an API Key. We do not
> control which gateway will answer this request. This is a blocker to
> achieve the 3rd option.
> Also, we do not control which gateway will handle the API invocation
> request. The gateway which answers the API invocation call can authorize
> the request only after validating the user with its own user
> configurations. Hence ideally, the user configurations should be identical
> in gateways.
>
> Kindly let me know your thoughts. Thank you.
>
> On Mon, Dec 9, 2019 at 5:06 PM Amali Matharaarachchi 
> wrote:
>
>> Hi,
>> If someone used this API Key in authorization bearer header, it will work
>> just like another JWT token. To avoid this, we need to differentiate API
>> Key and other JWTs. Even if we provide a separate header for the API Key,
>> the above issue will not be solved.
>>
>> On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:
>>
>>> Ok, this should be because we are using a different header than the
>>> authentication header for API Key in synapse gateway. I assume what we are
>>> trying here is to use both types of tokens in the authentication header?
>>>
>>> On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
>>> wrote:
>>>
 It didn't look like synapse gateway did a differentiation between these
 two cases. +Rajith Roshan   tested it. API Key
 didn't work in Auth header simply because there was a missing attribute in
 the JWT. It doesn't result in "Invalid JWT token" or similar error as
 expected.

 On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:

> We should be identifying both separately already in the synapse
> gateway. Have you checked how it has been done and stick to the same if
> possible for consistency?
>
> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>>
>> We need to differentiate the API Key from a normal JWT token. The API
>> Key is a simple JWT but when an API Key is provided we need to 
>> authenticate
>> the user as well.
>> For this purpose, we added the additional claim "apiKey" to the
>> issuing JWT. If it is present in the token, it will be recognized as an
>> API Key.
>> I highly appreciate if you have any suggestions regarding this.
>>
>> Thanks.
>>
>> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi Harsha,
>>>
>>> Will the token endpoint is default one and provide an option to
 point to the key manager in a standard deployment?
>>>
>>>
>>> Configurations similar to the following are added to micro-gw.conf
>>> file to enable the self JWT issuer and to provide related configurations
>>> [1].
>>>
>>> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
>>> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>>>
>>>
>>>
 What's the endpoint that we going to provide and how the request
 would look like to get a key?
>>>
>>>
>>> The token endpoint would issue the self JWT token when JWT issuer is
>>> enabled in the config [2].
>>>
>>> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
>>> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>>>
>>> [1]
>>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi all,

I have several concerns regarding the current approach. I highly appreciate
your suggestions. @Rajith Roshan  Please add if I have
missed out anything.

1. How to differentiate the API Key and JWT token.
API Key issued from the Microgateway has additional claim "apikey: true".
This claim will be used to recognize if it is an API Key when an API Key is
given as bearer authorization.
However, an API Key and a JWT token released from API Manager cannot be
differentiated in Microgateway.

2. Add an adequate level of security to API Key issued from Microgateway.
We validate the user given in the subject claim of the API Key. The
invocation request will be authorized if only the subjected user is
configured in the gateway which received the API invocation request.

3. Add a list of APIs to the API Key to indicate which APIs can be accessed
from the issued API Key.
This is not addressed by the current implementation. Beforehand there is a
couple of concerns we need to address for cases such as load-balanced micro
gateways.

4. Issues on API Key with Load balancing.
When a API Key is requested with basic auth, some gateway which can
authorize the request would answer the call and issue an API Key. We do not
control which gateway will answer this request. This is a blocker to
achieve the 3rd option.
Also, we do not control which gateway will handle the API invocation
request. The gateway which answers the API invocation call can authorize
the request only after validating the user with its own user
configurations. Hence ideally, the user configurations should be identical
in gateways.

Kindly let me know your thoughts. Thank you.

On Mon, Dec 9, 2019 at 5:06 PM Amali Matharaarachchi 
wrote:

> Hi,
> If someone used this API Key in authorization bearer header, it will work
> just like another JWT token. To avoid this, we need to differentiate API
> Key and other JWTs. Even if we provide a separate header for the API Key,
> the above issue will not be solved.
>
> On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:
>
>> Ok, this should be because we are using a different header than the
>> authentication header for API Key in synapse gateway. I assume what we are
>> trying here is to use both types of tokens in the authentication header?
>>
>> On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
>> wrote:
>>
>>> It didn't look like synapse gateway did a differentiation between these
>>> two cases. +Rajith Roshan   tested it. API Key didn't
>>> work in Auth header simply because there was a missing attribute in the
>>> JWT. It doesn't result in "Invalid JWT token" or similar error as expected.
>>>
>>> On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:
>>>
 We should be identifying both separately already in the synapse
 gateway. Have you checked how it has been done and stick to the same if
 possible for consistency?

 On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
 wrote:

> Hi all,
>
> We need to differentiate the API Key from a normal JWT token. The API
> Key is a simple JWT but when an API Key is provided we need to 
> authenticate
> the user as well.
> For this purpose, we added the additional claim "apiKey" to the
> issuing JWT. If it is present in the token, it will be recognized as an
> API Key.
> I highly appreciate if you have any suggestions regarding this.
>
> Thanks.
>
> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
> wrote:
>
>> Hi Harsha,
>>
>> Will the token endpoint is default one and provide an option to point
>>> to the key manager in a standard deployment?
>>
>>
>> Configurations similar to the following are added to micro-gw.conf
>> file to enable the self JWT issuer and to provide related configurations
>> [1].
>>
>> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
>> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>>
>>
>>
>>> What's the endpoint that we going to provide and how the request
>>> would look like to get a key?
>>
>>
>> The token endpoint would issue the self JWT token when JWT issuer is
>> enabled in the config [2].
>>
>> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
>> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>>
>> [1]
>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
>> [2]
>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055
>>
>> On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>> There is a Slack Discussion[1] in #microgateway channel as well.
>>>
>>> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
>>> 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi,
If someone used this API Key in authorization bearer header, it will work
just like another JWT token. To avoid this, we need to differentiate API
Key and other JWTs. Even if we provide a separate header for the API Key,
the above issue will not be solved.

On Mon, Dec 9, 2019 at 4:59 PM Fazlan Nazeem  wrote:

> Ok, this should be because we are using a different header than the
> authentication header for API Key in synapse gateway. I assume what we are
> trying here is to use both types of tokens in the authentication header?
>
> On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
> wrote:
>
>> It didn't look like synapse gateway did a differentiation between these
>> two cases. +Rajith Roshan   tested it. API Key didn't
>> work in Auth header simply because there was a missing attribute in the
>> JWT. It doesn't result in "Invalid JWT token" or similar error as expected.
>>
>> On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:
>>
>>> We should be identifying both separately already in the synapse gateway.
>>> Have you checked how it has been done and stick to the same if possible for
>>> consistency?
>>>
>>> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi all,

 We need to differentiate the API Key from a normal JWT token. The API
 Key is a simple JWT but when an API Key is provided we need to authenticate
 the user as well.
 For this purpose, we added the additional claim "apiKey" to the issuing
 JWT. If it is present in the token, it will be recognized as an API Key.
 I highly appreciate if you have any suggestions regarding this.

 Thanks.

 On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
 wrote:

> Hi Harsha,
>
> Will the token endpoint is default one and provide an option to point
>> to the key manager in a standard deployment?
>
>
> Configurations similar to the following are added to micro-gw.conf
> file to enable the self JWT issuer and to provide related configurations
> [1].
>
> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>
>
>
>> What's the endpoint that we going to provide and how the request
>> would look like to get a key?
>
>
> The token endpoint would issue the self JWT token when JWT issuer is
> enabled in the config [2].
>
> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>
> [1]
> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
> [2]
> https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055
>
> On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>> There is a Slack Discussion[1] in #microgateway channel as well.
>>
>> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
>> 
>>
>> On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara 
>> wrote:
>>
>>> Please discuss this in public groups.
>>>
>>> What's the endpoint that we going to provide and how the request
>>> would look like to get a key?
>>>
>>> Will the token endpoint is default one and provide an option to
>>> point to the key manager in a standard deployment?
>>>
>>>
>>> On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi <
>>> ama...@wso2.com> wrote:
>>>
 Hi all,

 We are planning to add a feature for issuing simple JWTs which are
 to be used in Microgateway. Please refer GitHub issue [1] for more
 information.

 This feature addresses the user story "As a developer, I would like
 to invoke my micro gateway API easily without configuring a key 
 manager". A
 self-contained JWT token should be issued as the API key by the
 Microgateway server without communicating with an external Key
 Manager. This API key would later use to authenticate the user when
 invoking an API.

 A token endpoint secured with basic authentication would be
 provided to issue the API Key. When invoked with this API Key, API 
 key's
 sub claim could be used to authenticate the user and validate that the 
 user
 has the privilege.

 JWT token format would be similar to:
 header
 {
   "alg": "RS256",
   "typ": "jwt",
   "kid": "ballerina"
 }
 payload
 {
   "sub": "generalUser1",
   "iss": 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Fazlan Nazeem]

Ok, this should be because we are using a different header than the
authentication header for API Key in synapse gateway. I assume what we are
trying here is to use both types of tokens in the authentication header?

On Mon, Dec 9, 2019 at 4:41 PM Praminda Jayawardana 
wrote:

> It didn't look like synapse gateway did a differentiation between these
> two cases. +Rajith Roshan   tested it. API Key didn't
> work in Auth header simply because there was a missing attribute in the
> JWT. It doesn't result in "Invalid JWT token" or similar error as expected.
>
> On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:
>
>> We should be identifying both separately already in the synapse gateway.
>> Have you checked how it has been done and stick to the same if possible for
>> consistency?
>>
>> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> We need to differentiate the API Key from a normal JWT token. The API
>>> Key is a simple JWT but when an API Key is provided we need to authenticate
>>> the user as well.
>>> For this purpose, we added the additional claim "apiKey" to the issuing
>>> JWT. If it is present in the token, it will be recognized as an API Key.
>>> I highly appreciate if you have any suggestions regarding this.
>>>
>>> Thanks.
>>>
>>> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi Harsha,

 Will the token endpoint is default one and provide an option to point
> to the key manager in a standard deployment?


 Configurations similar to the following are added to micro-gw.conf file
 to enable the self JWT issuer and to provide related configurations [1].

 [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
 [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"



> What's the endpoint that we going to provide and how the request would
> look like to get a key?


 The token endpoint would issue the self JWT token when JWT issuer is
 enabled in the config [2].

 curl -X get "https://localhost:9096/token; -H "Authorization:Basic
 Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k

 [1]
 https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
 [2]
 https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055

 On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
 wrote:

> Hi all,
> There is a Slack Discussion[1] in #microgateway channel as well.
>
> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
> 
>
> On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara  wrote:
>
>> Please discuss this in public groups.
>>
>> What's the endpoint that we going to provide and how the request
>> would look like to get a key?
>>
>> Will the token endpoint is default one and provide an option to point
>> to the key manager in a standard deployment?
>>
>>
>> On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to add a feature for issuing simple JWTs which are
>>> to be used in Microgateway. Please refer GitHub issue [1] for more
>>> information.
>>>
>>> This feature addresses the user story "As a developer, I would like
>>> to invoke my micro gateway API easily without configuring a key 
>>> manager". A
>>> self-contained JWT token should be issued as the API key by the
>>> Microgateway server without communicating with an external Key
>>> Manager. This API key would later use to authenticate the user when
>>> invoking an API.
>>>
>>> A token endpoint secured with basic authentication would be provided
>>> to issue the API Key. When invoked with this API Key, API key's sub 
>>> claim
>>> could be used to authenticate the user and validate that the user has 
>>> the
>>> privilege.
>>>
>>> JWT token format would be similar to:
>>> header
>>> {
>>>   "alg": "RS256",
>>>   "typ": "jwt",
>>>   "kid": "ballerina"
>>> }
>>> payload
>>> {
>>>   "sub": "generalUser1",
>>>   "iss": "https://localhost:9443/oauth2/token;,
>>>   "exp": 1575620540,
>>>   "iat": 1575619940,
>>>   "jti": "bb38e533-e127-4991-95a2-7a383e634eba",
>>>   "aud": "http://org.wso2.apimgt/gateway;,
>>>   "apiKey": true
>>> }
>>>
>>> We highly appreciate your suggestions. Thank you.
>>>
>>> [1] https://github.com/wso2/product-microgateway/issues/897
>>> --
>>> *Amali Lakshika*
>>>
>>>
>>>
>>>
>>> *Software EngineerWSO2 Inc.: 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Praminda Jayawardana]

It didn't look like synapse gateway did a differentiation between these two
cases. +Rajith Roshan   tested it. API Key didn't work in
Auth header simply because there was a missing attribute in the JWT. It
doesn't result in "Invalid JWT token" or similar error as expected.

On Mon, Dec 9, 2019 at 4:34 PM Fazlan Nazeem  wrote:

> We should be identifying both separately already in the synapse gateway.
> Have you checked how it has been done and stick to the same if possible for
> consistency?
>
> On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>>
>> We need to differentiate the API Key from a normal JWT token. The API Key
>> is a simple JWT but when an API Key is provided we need to authenticate the
>> user as well.
>> For this purpose, we added the additional claim "apiKey" to the issuing
>> JWT. If it is present in the token, it will be recognized as an API Key.
>> I highly appreciate if you have any suggestions regarding this.
>>
>> Thanks.
>>
>> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi Harsha,
>>>
>>> Will the token endpoint is default one and provide an option to point to
 the key manager in a standard deployment?
>>>
>>>
>>> Configurations similar to the following are added to micro-gw.conf file
>>> to enable the self JWT issuer and to provide related configurations [1].
>>>
>>> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
>>> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>>>
>>>
>>>
 What's the endpoint that we going to provide and how the request would
 look like to get a key?
>>>
>>>
>>> The token endpoint would issue the self JWT token when JWT issuer is
>>> enabled in the config [2].
>>>
>>> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
>>> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>>>
>>> [1]
>>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
>>> [2]
>>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055
>>>
>>> On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi all,
 There is a Slack Discussion[1] in #microgateway channel as well.

 [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
 

 On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara  wrote:

> Please discuss this in public groups.
>
> What's the endpoint that we going to provide and how the request would
> look like to get a key?
>
> Will the token endpoint is default one and provide an option to point
> to the key manager in a standard deployment?
>
>
> On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>>
>> We are planning to add a feature for issuing simple JWTs which are to
>> be used in Microgateway. Please refer GitHub issue [1] for more
>> information.
>>
>> This feature addresses the user story "As a developer, I would like
>> to invoke my micro gateway API easily without configuring a key 
>> manager". A
>> self-contained JWT token should be issued as the API key by the
>> Microgateway server without communicating with an external Key
>> Manager. This API key would later use to authenticate the user when
>> invoking an API.
>>
>> A token endpoint secured with basic authentication would be provided
>> to issue the API Key. When invoked with this API Key, API key's sub claim
>> could be used to authenticate the user and validate that the user has the
>> privilege.
>>
>> JWT token format would be similar to:
>> header
>> {
>>   "alg": "RS256",
>>   "typ": "jwt",
>>   "kid": "ballerina"
>> }
>> payload
>> {
>>   "sub": "generalUser1",
>>   "iss": "https://localhost:9443/oauth2/token;,
>>   "exp": 1575620540,
>>   "iat": 1575619940,
>>   "jti": "bb38e533-e127-4991-95a2-7a383e634eba",
>>   "aud": "http://org.wso2.apimgt/gateway;,
>>   "apiKey": true
>> }
>>
>> We highly appreciate your suggestions. Thank you.
>>
>> [1] https://github.com/wso2/product-microgateway/issues/897
>> --
>> *Amali Lakshika*
>>
>>
>>
>>
>> *Software EngineerWSO2 Inc.: https://wso2.com
>> lean.enterprise.middle-waremobile: **+94 71 932
>> 1861*
>>
>> *skype: amali.94d*
>>
>> 
>>
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Fazlan Nazeem]

We should be identifying both separately already in the synapse gateway.
Have you checked how it has been done and stick to the same if possible for
consistency?

On Mon, Dec 9, 2019 at 3:56 PM Amali Matharaarachchi 
wrote:

> Hi all,
>
> We need to differentiate the API Key from a normal JWT token. The API Key
> is a simple JWT but when an API Key is provided we need to authenticate the
> user as well.
> For this purpose, we added the additional claim "apiKey" to the issuing
> JWT. If it is present in the token, it will be recognized as an API Key.
> I highly appreciate if you have any suggestions regarding this.
>
> Thanks.
>
> On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
> wrote:
>
>> Hi Harsha,
>>
>> Will the token endpoint is default one and provide an option to point to
>>> the key manager in a standard deployment?
>>
>>
>> Configurations similar to the following are added to micro-gw.conf file
>> to enable the self JWT issuer and to provide related configurations [1].
>>
>> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
>> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>>
>>
>>
>>> What's the endpoint that we going to provide and how the request would
>>> look like to get a key?
>>
>>
>> The token endpoint would issue the self JWT token when JWT issuer is
>> enabled in the config [2].
>>
>> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
>> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>>
>> [1]
>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
>> [2]
>> https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055
>>
>> On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>> There is a Slack Discussion[1] in #microgateway channel as well.
>>>
>>> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
>>> 
>>>
>>> On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara  wrote:
>>>
 Please discuss this in public groups.

 What's the endpoint that we going to provide and how the request would
 look like to get a key?

 Will the token endpoint is default one and provide an option to point
 to the key manager in a standard deployment?


 On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi 
 wrote:

> Hi all,
>
> We are planning to add a feature for issuing simple JWTs which are to
> be used in Microgateway. Please refer GitHub issue [1] for more
> information.
>
> This feature addresses the user story "As a developer, I would like to
> invoke my micro gateway API easily without configuring a key manager". A
> self-contained JWT token should be issued as the API key by the
> Microgateway server without communicating with an external Key
> Manager. This API key would later use to authenticate the user when
> invoking an API.
>
> A token endpoint secured with basic authentication would be provided
> to issue the API Key. When invoked with this API Key, API key's sub claim
> could be used to authenticate the user and validate that the user has the
> privilege.
>
> JWT token format would be similar to:
> header
> {
>   "alg": "RS256",
>   "typ": "jwt",
>   "kid": "ballerina"
> }
> payload
> {
>   "sub": "generalUser1",
>   "iss": "https://localhost:9443/oauth2/token;,
>   "exp": 1575620540,
>   "iat": 1575619940,
>   "jti": "bb38e533-e127-4991-95a2-7a383e634eba",
>   "aud": "http://org.wso2.apimgt/gateway;,
>   "apiKey": true
> }
>
> We highly appreciate your suggestions. Thank you.
>
> [1] https://github.com/wso2/product-microgateway/issues/897
> --
> *Amali Lakshika*
>
>
>
>
> *Software EngineerWSO2 Inc.: https://wso2.com
> lean.enterprise.middle-waremobile: **+94 71 932
> 1861*
>
> *skype: amali.94d*
>
> 
>
>


 --

 *Harsha Kumara*

 Technical Lead, WSO2 Inc.
 Mobile: +94775505618
 Email: hars...@wso2.coim
 Blog: harshcreationz.blogspot.com

 GET INTEGRATION AGILE
 Integration Agility for Digitally Driven Business

>>>
>>>
>>> --
>>> *Amali Lakshika*
>>>
>>>
>>>
>>>
>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>>
>>> *skype: amali.94d*
>>>
>>> 
>>>
>>>
>>
>>
>> --
>> *Amali Lakshika*
>>
>>
>>
>>
>> *Software EngineerWSO2 Inc.: https://wso2.com
>> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>
>> *skype: amali.94d*
>>
>> 

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi all,

We need to differentiate the API Key from a normal JWT token. The API Key
is a simple JWT but when an API Key is provided we need to authenticate the
user as well.
For this purpose, we added the additional claim "apiKey" to the issuing
JWT. If it is present in the token, it will be recognized as an API Key.
I highly appreciate if you have any suggestions regarding this.

Thanks.

On Fri, Dec 6, 2019 at 3:54 PM Amali Matharaarachchi 
wrote:

> Hi Harsha,
>
> Will the token endpoint is default one and provide an option to point to
>> the key manager in a standard deployment?
>
>
> Configurations similar to the following are added to micro-gw.conf file to
> enable the self JWT issuer and to provide related configurations [1].
>
> [jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
> [jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"
>
>
>
>> What's the endpoint that we going to provide and how the request would
>> look like to get a key?
>
>
> The token endpoint would issue the self JWT token when JWT issuer is
> enabled in the config [2].
>
> curl -X get "https://localhost:9096/token; -H "Authorization:Basic
> Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k
>
> [1]
> https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
> [2]
> https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055
>
> On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
> wrote:
>
>> Hi all,
>> There is a Slack Discussion[1] in #microgateway channel as well.
>>
>> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
>> 
>>
>> On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara  wrote:
>>
>>> Please discuss this in public groups.
>>>
>>> What's the endpoint that we going to provide and how the request would
>>> look like to get a key?
>>>
>>> Will the token endpoint is default one and provide an option to point to
>>> the key manager in a standard deployment?
>>>
>>>
>>> On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi 
>>> wrote:
>>>
 Hi all,

 We are planning to add a feature for issuing simple JWTs which are to
 be used in Microgateway. Please refer GitHub issue [1] for more
 information.

 This feature addresses the user story "As a developer, I would like to
 invoke my micro gateway API easily without configuring a key manager". A
 self-contained JWT token should be issued as the API key by the
 Microgateway server without communicating with an external Key
 Manager. This API key would later use to authenticate the user when
 invoking an API.

 A token endpoint secured with basic authentication would be provided to
 issue the API Key. When invoked with this API Key, API key's sub claim
 could be used to authenticate the user and validate that the user has the
 privilege.

 JWT token format would be similar to:
 header
 {
   "alg": "RS256",
   "typ": "jwt",
   "kid": "ballerina"
 }
 payload
 {
   "sub": "generalUser1",
   "iss": "https://localhost:9443/oauth2/token;,
   "exp": 1575620540,
   "iat": 1575619940,
   "jti": "bb38e533-e127-4991-95a2-7a383e634eba",
   "aud": "http://org.wso2.apimgt/gateway;,
   "apiKey": true
 }

 We highly appreciate your suggestions. Thank you.

 [1] https://github.com/wso2/product-microgateway/issues/897
 --
 *Amali Lakshika*




 *Software EngineerWSO2 Inc.: https://wso2.com
 lean.enterprise.middle-waremobile: **+94 71 932 1861*

 *skype: amali.94d*

 


>>>
>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> *Amali Lakshika*
>>
>>
>>
>>
>> *Software EngineerWSO2 Inc.: https://wso2.com
>> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>
>> *skype: amali.94d*
>>
>> 
>>
>>
>
>
> --
> *Amali Lakshika*
>
>
>
>
> *Software EngineerWSO2 Inc.: https://wso2.com
> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>
> *skype: amali.94d*
>
> 
>
>


-- 
*Amali Lakshika*




*Software EngineerWSO2 Inc.: https://wso2.com
lean.enterprise.middle-waremobile: **+94 71 932 1861*

*skype: amali.94d*


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Microgateway] JWT Issuer feature

[Amali Matharaarachchi]

Hi Harsha,

Will the token endpoint is default one and provide an option to point to
> the key manager in a standard deployment?


Configurations similar to the following are added to micro-gw.conf file to
enable the self JWT issuer and to provide related configurations [1].

[jwtTokenConfig]issuer="https://localhost:9443/oauth2/token"audience="http://org.wso2.apimgt/gateway"certificateAlias="wso2apim"validateSubscription=false
[jwtTokenConfig.jwtIssuer]enabled=falsevalidityPeriod=600keyStoreAlias="ballerina"



> What's the endpoint that we going to provide and how the request would
> look like to get a key?


The token endpoint would issue the self JWT token when JWT issuer is
enabled in the config [2].

curl -X get "https://localhost:9096/token; -H "Authorization:Basic
Z2VuZXJhbFVzZXIxOnBhc3N3b3Jk" -k

[1]
https://github.com/wso2/product-microgateway/issues/897#issuecomment-561996404
[2]
https://github.com/wso2/product-microgateway/issues/897#issuecomment-562422055

On Fri, Dec 6, 2019 at 3:03 PM Amali Matharaarachchi 
wrote:

> Hi all,
> There is a Slack Discussion[1] in #microgateway channel as well.
>
> [1] https://wso2-apim.slack.com/archives/CLY1W0NSK/p1575007973020900
> 
>
> On Fri, Dec 6, 2019 at 2:48 PM Harsha Kumara  wrote:
>
>> Please discuss this in public groups.
>>
>> What's the endpoint that we going to provide and how the request would
>> look like to get a key?
>>
>> Will the token endpoint is default one and provide an option to point to
>> the key manager in a standard deployment?
>>
>>
>> On Fri, Dec 6, 2019 at 2:31 PM Amali Matharaarachchi 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to add a feature for issuing simple JWTs which are to be
>>> used in Microgateway. Please refer GitHub issue [1] for more information.
>>>
>>> This feature addresses the user story "As a developer, I would like to
>>> invoke my micro gateway API easily without configuring a key manager". A
>>> self-contained JWT token should be issued as the API key by the
>>> Microgateway server without communicating with an external Key
>>> Manager. This API key would later use to authenticate the user when
>>> invoking an API.
>>>
>>> A token endpoint secured with basic authentication would be provided to
>>> issue the API Key. When invoked with this API Key, API key's sub claim
>>> could be used to authenticate the user and validate that the user has the
>>> privilege.
>>>
>>> JWT token format would be similar to:
>>> header
>>> {
>>>   "alg": "RS256",
>>>   "typ": "jwt",
>>>   "kid": "ballerina"
>>> }
>>> payload
>>> {
>>>   "sub": "generalUser1",
>>>   "iss": "https://localhost:9443/oauth2/token;,
>>>   "exp": 1575620540,
>>>   "iat": 1575619940,
>>>   "jti": "bb38e533-e127-4991-95a2-7a383e634eba",
>>>   "aud": "http://org.wso2.apimgt/gateway;,
>>>   "apiKey": true
>>> }
>>>
>>> We highly appreciate your suggestions. Thank you.
>>>
>>> [1] https://github.com/wso2/product-microgateway/issues/897
>>> --
>>> *Amali Lakshika*
>>>
>>>
>>>
>>>
>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>>
>>> *skype: amali.94d*
>>>
>>> 
>>>
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Amali Lakshika*
>
>
>
>
> *Software EngineerWSO2 Inc.: https://wso2.com
> lean.enterprise.middle-waremobile: **+94 71 932 1861*
>
> *skype: amali.94d*
>
> 
>
>


-- 
*Amali Lakshika*




*Software EngineerWSO2 Inc.: https://wso2.com
lean.enterprise.middle-waremobile: **+94 71 932 1861*

*skype: amali.94d*


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture