On Mon, Sep 30, 2019 at 11:23 AM Hasintha Indrajee
wrote:
>
>
> On Mon, Sep 30, 2019 at 11:17 AM Farasath Ahamed
> wrote:
>
>>
>>
>> On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee
>> wrote:
>>
>>> The original problem is we can't execute client authenticators per
>>> application. As per our
On Mon, Sep 30, 2019 at 11:58 AM Farasath Ahamed wrote:
>
>
> On Mon, Sep 30, 2019 at 11:23 AM Hasintha Indrajee
> wrote:
>
>>
>>
>> On Mon, Sep 30, 2019 at 11:17 AM Farasath Ahamed
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee
>>> wrote:
>>>
The original prob
On Mon, Sep 30, 2019 at 11:23 AM Hasintha Indrajee
wrote:
>
>
> On Mon, Sep 30, 2019 at 11:17 AM Farasath Ahamed
> wrote:
>
>>
>>
>> On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee
>> wrote:
>>
>>> The original problem is we can't execute client authenticators per
>>> application. As per our
On Mon, Sep 30, 2019 at 11:21 AM Ayesha Dissanayaka wrote:
>
>
> On Sun, Sep 29, 2019 at 10:48 AM Harsha Kumara wrote:
>
>>
>>
>> On Fri, Sep 27, 2019 at 7:30 PM Harsha Kumara wrote:
>>
>>>
>>>
>>> On Fri, Sep 27, 2019 at 7:06 PM Piraveena Paralogarajah <
>>> pirave...@wso2.com> wrote:
>>>
On Mon, Sep 30, 2019 at 11:17 AM Farasath Ahamed wrote:
>
>
> On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee
> wrote:
>
>> The original problem is we can't execute client authenticators per
>> application. As per our current implementation we never can have a both
>> MTLS and Basic Auth clien
On Sun, Sep 29, 2019 at 10:48 AM Harsha Kumara wrote:
>
>
> On Fri, Sep 27, 2019 at 7:30 PM Harsha Kumara wrote:
>
>>
>>
>> On Fri, Sep 27, 2019 at 7:06 PM Piraveena Paralogarajah <
>> pirave...@wso2.com> wrote:
>>
>>> Hi Harsha,
>>>
>>> As @Sathya Bandara pointed in the previous mail,
>>>
>>>
On Fri, Sep 27, 2019 at 5:47 PM Hasintha Indrajee wrote:
> The original problem is we can't execute client authenticators per
> application. As per our current implementation we never can have a both
> MTLS and Basic Auth client authentication supported in the server while
> different clients usi
On Fri, Sep 27, 2019 at 7:30 PM Harsha Kumara wrote:
>
>
> On Fri, Sep 27, 2019 at 7:06 PM Piraveena Paralogarajah <
> pirave...@wso2.com> wrote:
>
>> Hi Harsha,
>>
>> As @Sathya Bandara pointed in the previous mail,
>>
>> In the oauth spec [1], it mandates that client should not use more than
>
On Fri, Sep 27, 2019 at 7:06 PM Piraveena Paralogarajah
wrote:
> Hi Harsha,
>
> As @Sathya Bandara pointed in the previous mail,
>
> In the oauth spec [1], it mandates that client should not use more than
>> one authentication mechanism per request. Hence, we have that validation
>> here.
>> [1]
Hi Harsha,
As @Sathya Bandara pointed in the previous mail,
In the oauth spec [1], it mandates that client should not use more than one
> authentication mechanism per request. Hence, we have that validation here.
> [1] https://tools.ietf.org/html/rfc6749#section-2.3
A client should not use mor
+1 to have it under the application level.
This issue even occur when i configure IS as a OIDC provider in our API
Manager. Rather than asking clients to turn if off through the
configuration, I'm favour of having that disable by default. If person
configure IS as KM, then this become a mandatory
The original problem is we can't execute client authenticators per
application. As per our current implementation we never can have a both
MTLS and Basic Auth client authentication supported in the server while
different clients using Basic auth + MTLS and BasicAuth or MTLS alone.
Hence I think, t
Hi All,
When I configured the IS as KM, same issue occured during the token
generation as our client initialize using the required keystores. Client
will set the javax.servlet.request.X509Certificate by default. Our products
support http verify clent as option which means client can authenticate
w
Thank you for the information. Since I'm using the alpha4 update, it should
have that fix. I'll check further
On Sat, Sep 21, 2019 at 12:20 AM Sathya Bandara wrote:
> That PR was not merged. Instead the missing registry configs were re-added
> [1]
>
> [1] https://github.com/wso2/product-is/pull/
Hi Harsha,
We observed this error in IS 5.9.0-m3 pack and we fixed it in 5.9.0-m6. In
5.7.0 and Before IS-5.7, we didn't ship mutualtls authenticator by default.
In 5.9.0-m3 pack, since we ship this mutualtls authenticator, that
authenticator gets enabled. So we suspected, it may be the cause and
That PR was not merged. Instead the missing registry configs were re-added
[1]
[1] https://github.com/wso2/product-is/pull/6076
On Fri, Sep 20, 2019 at 8:35 PM Harsha Kumara wrote:
> Since this either should handle at client side and mandate not to send the
> certificate or we have to disable t
Since this either should handle at client side and mandate not to send the
certificate or we have to disable the handler. Looks like we have disabled
the handler by default in
https://github.com/wso2/carbon-identity-framework/pull/2336/files
But I don't see it in the wso2is-5.9.0-alpha4-SNAPSHOT.
Thanks a lot @Sathya Bandara That should be the issue. I
will check and update the thread.
Thanks,
Harsha
On Fri, Sep 20, 2019 at 7:14 PM Sathya Bandara wrote:
> We came across a similar issue where the OIDC federated authenticator sets
> the certificate by default to the request [1]. This has
We came across a similar issue where the OIDC federated authenticator sets
the certificate by default to the request [1]. This has occurred due to a
change to registry.xml with new config model. When the changes were
reverted it worked as expected [2]. Maybe the same issue exists with APIM?
[1] "E
Yes that's correct. I'm using the openid authenticator, so it sets the
certificate by default to the header, hence multiple authenticators getting
triggered..But mutual SSL is handled at the transport layer and even with
mutual authentication, client id and secret will be present in the request.
I
If client secret is used for client authentication with POST request to the
token endpoint, then its not required to send the certificate.
On Fri, Sep 20, 2019 at 6:35 PM Harsha Kumara wrote:
> So if so our OpenIDConnectAuthenticator shouldn't set certificate in the
> request during the authoriz
So if so our OpenIDConnectAuthenticator shouldn't set certificate in the
request during the authorization code exchange?
On Fri, Sep 20, 2019 at 6:30 PM Sathya Bandara wrote:
> Hi Harsha,
>
> In the oauth spec [1], it mandates that client should not use more than
> one authentication mechanism p
Hi Harsha,
In the oauth spec [1], it mandates that client should not use more than one
authentication mechanism per request. Hence, we have that validation here.
[1] https://tools.ietf.org/html/rfc6749#section-2.3
Thanks,
On Fri, Sep 20, 2019 at 6:25 PM Harsha Kumara wrote:
> As we can config
As we can configure multiple authenticators, and add them based on
canAuthenticate method response, why we need to return above error if
multiple authenticators engaged?
On Fri, Sep 20, 2019 at 6:22 PM Harsha Kumara wrote:
> It seems the logic of checking authenticator list greater than 1 should
It seems the logic of checking authenticator list greater than 1 should be
correct?
On Fri, Sep 20, 2019 at 5:30 PM Harsha Kumara wrote:
> Hi,
>
> With the API Manager 3.0.0 release, we are going to add OIDC authenticator
> to the API Manager as we already had that capability in directly through
Hi,
With the API Manager 3.0.0 release, we are going to add OIDC authenticator
to the API Manager as we already had that capability in directly through
the site.json configuration.
However to try the scenario, I have followed the document[1].
Setup would be APIM 3.0.0 and IS-5.9.0-Alpha4-SNAPSHO
26 matches
Mail list logo
