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]
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]
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,
>
> 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
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
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
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
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
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
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
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
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].
12 matches
Mail list logo
