Great. IMO having those throttling would suffice in most cases, as is the
case with MutualSSL based authentication [1]. But I learned from another
thread [2] when both MTS and OAuth are enabled it only authenticates based
on MTS, thereby losing OAuth bound throttling capabilities. Is that the
case
On Fri, May 31, 2019 at 7:58 AM Johann Nallathamby wrote:
> *Problem*
>
> When we federate to other OpenID Connect Providers, we can send scope
> values. However, currently the scope values are fixed per OP we define in
> IS. This works fine if the service provider is not a OpenID Connect RP or
*Problem*
When we federate to other OpenID Connect Providers, we can send scope
values. However, currently the scope values are fixed per OP we define in
IS. This works fine if the service provider is not a OpenID Connect RP or
an RP not requesting scopes. If we are to support different scope
On Thu, May 30, 2019 at 10:37 AM Nuwan Bandara wrote:
>
>
> On Thu, May 30, 2019 at 11:22 AM Lahiru Sandaruwan
> wrote:
>
>>
>>
>> On Wed, May 29, 2019 at 4:33 AM Lahiru Madushanka
>> wrote:
>>
>>> Hi all,
>>>
>>> Please find the description of the proposed model below.
>>>
>>> I am proposing
On Thu, May 30, 2019 at 11:22 AM Lahiru Sandaruwan wrote:
>
>
> On Wed, May 29, 2019 at 4:33 AM Lahiru Madushanka
> wrote:
>
>> Hi all,
>>
>> Please find the description of the proposed model below.
>>
>> I am proposing to handle the single CAPP and multiple CAPPs scenarios
>> differently.
>>
On Wed, May 29, 2019 at 4:33 AM Lahiru Madushanka
wrote:
> Hi all,
>
> Please find the description of the proposed model below.
>
> I am proposing to handle the single CAPP and multiple CAPPs scenarios
> differently.
>
>- Single CAPP
>
> In this case we can add the spotify doker plugin to
If its throttling we are going after, there's nothing additional that needs
to be done. If someone wants to ensure their API doesn't get hit more than
say 100req/minute, they can still do that by attaching the relevant
throttling policy to the API/resource.
If its some other use case of
On Thu, May 30, 2019 at 3:29 PM Johann Nallathamby wrote:
> In fact there is a much more easier option as well.
>
> Just make the client_id and client_secret fields in the API Store optional
> input text boxes so that App developers have the option of providing their
> own client_id and
In fact there is a much more easier option as well.
Just make the client_id and client_secret fields in the API Store optional
input text boxes so that App developers have the option of providing their
own client_id and client_secret. I think this was also a requirement for
many of our customers
Basic authentication for the APIs is a frequently requested functionality
in the API-M. And as Johann and Chanaka have mentioned throttling and
analytics shouldn't be overlooked when basic authentication is used.
When basic auth is used with OAuth2 there's no issue with this. My view on
this is
10 matches
Mail list logo
