Hi All,
Due to an urgent maintenance, we will be shutting down nexus master. During
this period all users will be unable to access nexus (
https://maven.wso2.org/nexus/).
*Date :20th September 2019 *
*Time: 11.00 AM IST to 2:00 PM IST*.
*Affected Parties: All External and Internal Users*
Thanks
Hi All,
The maintenance task is successfully completed.
Thanks & Regards,
On Fri, Sep 20, 2019 at 12:39 PM Isuru Rupasinghe wrote:
> Hi All,
>
> Due to an urgent maintenance, we will be shutting down nexus master.
> During this period all users will be unable to access nexus (
> https://maven.
Hi All,
The IDN_ARTIFACT_STORE is a new table and was used to store the user store
configurations in the database. Since the feature for storing user store
configurations in the database will not be sent in IS590 we have decided to
remove the IDN_ARTIFACT_STORE table creation from the SQL scripts.
:All
When calling the JWKS endpoint (https://localhost:9443/t/abc.com/oauth2/jwks)
of a tenant, right after restart without loading the tenant, there is an
error[1][2].
We have observed that the reason for $subject is that the keystore for the
relevant tenant is not loaded(from registry) when mak
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
Hi Isuranga,
I think we have to initialize the registry as follows before using it.
IdentityTenantUtil.initializeRegistry(tenantId, tenantDomain);
Cheers,
Isura.
On Fri, Sep 20, 2019 at 3:41 PM Isuranga Perera wrote:
> :All
>
> When calling the JWKS endpoint (
> https://localhost:9443/t/abc.c
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
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
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
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
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
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
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
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
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.
*The WSO2 API Manager team is pleased to announce the release of version
3.0.0-Alpha of API Manager Tooling.*
Major improvements include supporting token generation for APIs for testing
purposes. Also, it includes support for Kubernetes APIM operator to deploy
and manage APIs in the Kubernetes clu
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
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
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 Thanuja,
Did we consider sending the access token itself as a secure, http-only
cookie to the browser instead of binding it to a separate cookie? This will
also simplify the development on the client side, in case someone wants to
build their own SPA.
Regards,
Johann.
On Mon, Sep 2, 2019 at 1
20 matches
Mail list logo
