Re: [Architecture] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

Hi Farasath, Shouldn't this restriction per SP(client)? > Since jti is an identifier string, what happens if two different SPs send > two different JWTs with the same jti? > As it is the same token end point which will issue the JWT, we did not think to restrict this for per SP. So we have

Re: [Architecture] [APIM][C5] Multi-Environment API Overview Feature

Hi Renuka, What are we planning to display in 'Multi-Environment API Overview'? Could you please elaborate more on this? Are we showing the diff in each environment? Thank you! On Tue, Jan 9, 2018 at 12:58 PM, Renuka Fernando wrote: > Hi All, > > We are planning to implement

Re: [Architecture] [RRT] XML, JSON, Shema validation threat protectors in APIM 2.1.x

Hi Isuru, As we discussed, I cloned the input stream by consuming the passthrough pipe as in below. if (pipe != null) { bufferedInputStream = new BufferedInputStream(pipe.getInputStream()); } ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); byte[]

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

@Bhathiya, Our initial plan was to provide an advanced option for developers to decide the version(Whether in Swagger 2.0 or OpenAPI 3.0) of the generating swagger definition, but later we decided to stick to OpenAPI 3.0 for newly creating APIs to avoid some complexities in supporting both

Re: [Architecture] Scope Registration API for carbon-auth

HI Sanjeewa, All, Please find my comment in line. On Mon, Jan 8, 2018 at 7:43 PM, Sanjeewa Malalgoda wrote: > Hi All, > We are thinking about adding scope registration support to our carbon-auth > implementation. For this we will need to have API to add/update/delete/list >

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

On Tue, Jan 9, 2018 at 8:29 AM, Isura Karunaratne wrote: > > > On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee > wrote: > >> The idea behind this is to decouple the authentication mechanism used by >> OAuth2 clients from the rest of the OAuth2 logic, so that

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

On Mon, Jan 8, 2018 at 11:10 PM, Farasath Ahamed wrote: > On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee > wrote: > >> The idea behind this is to decouple the authentication mechanism used by >> OAuth2 clients from the rest of the OAuth2 logic, so that

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

Hi Thilini, Shall we add this discussion into issue [1] itself. It will be easy to external party to get involve. On Mon, Jan 8, 2018 at 2:28 PM, Thilini Shanika wrote: > Hi All, > > We are planning to provide OpenAPI 3.0 specification support for API > Manager 2.2.0 [1].

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee wrote: > The idea behind this is to decouple the authentication mechanism used by > OAuth2 clients from the rest of the OAuth2 logic, so that different types > of client authenticators can be plugged. For an example according

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

Hi Hasintha, > The interface (API) will consist of three main methods. > > 1) canAuthenticate - Decides whether the particular authenticator can > authenticate the incoming request or not. > > 2) authenticateClient - Authenticates the client request based on > information present. As a result of

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

Hi Thilini, How does the Rest API handle this? for example, create api[1] needs swagger payload. Do you plan to provide both version support or just v3? There are some other Rest apis in the publisher rest api working with the swagger definition[2]. You might have to provide both version support

Re: [Architecture] Base paths to use for the APIs exposed from carbon-auth

Hi On Mon, Jan 8, 2018 at 7:53 PM, Pubudu Gunatilaka wrote: > Hi Malintha, > > Shouldn't we adhere to the existing APIs [1], [2] in Identity Server 5.x > at the moment? Otherwise, users who have written applications based on the > existing APIs won't be able to migrate easily.

Re: [Architecture] [MB4] Authorization Model for Message Broker

Hi, Reattach the missing diagram . [image: Inline image 1] Thanks, Waruna On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera wrote: > Hi, > > Message broker requires authorization model to access control of resources > like Topics/Queues based on user groups . This is to

[Architecture] [MB4] Authorization Model for Message Broker

Hi, Message broker requires authorization model to access control of resources like Topics/Queues based on user groups . This is to provide the initial design for $Subject. Example use case would be as follows. We have three user groups ( roles) A , B and manager and two topics T1 and T2. We

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee wrote: > The idea behind this is to decouple the authentication mechanism used by > OAuth2 clients from the rest of the OAuth2 logic, so that different types > of client authenticators can be plugged. For an example according

Re: [Architecture] OpenAPI 3.0 support for API Manager 2.2.0

Hi Thilini, Another thing we need to think about is whether we should let API developers decide which swagger version they need in their new APIs (if yes, how), or should we always use swagger 3 for new APIs. I prefer the first option unless we have any technical barriers supporting that.

Re: [Architecture] latest security updates for WSO2 IS

Hi Roman, As you have mentioned, in the link [1], it lists WSO2-CARBON-PATCH-4.4.0-1665 patch and shows the applicable Identity Server version as 1.2.0. It is not correct and we will remove this entry from the web page. [1] https://wso2.com/security-patch-releases/identity-server Thanks,

Re: [Architecture] latest security updates for WSO2 IS

Hi Roman, WSO2-CARBON-PATCH-4.4.0-1665 is applicable to following WSO2 products, which is listed in the readme file of the patch. DSS-3.5.1, IS-5.2.0, IS-Analytics-5.2.0, ML-1.2.0, CEP-4.2.0, DAS-3.1.0 So, according to above, it is applicable to Identity Server 5.2.0 version. You have mentioned

Re: [Architecture] [Feature] Storing the application certificate in the database.

Yes. Seems both options are viable and has it own pros and cons. I'm +1 for either option. Just that uploading is little more convenient at the time of adding it. But having text have its own reason to consider it. On Sun, Jan 7, 2018 at 11:22 PM, Rushmin Fernando wrote: > > >

[Architecture] latest security updates for WSO2 IS

Hi. I tried to download security patches for WSO2 IS from https://wso2.com/security-patch-releases/identity-server. This pages shows that the latest security patch is "WSO2-CARBON-PATCH-4.4.0-1665" from Dec. 2017 and that it is for version 1.2.0. But is it really the correct version? Identity

Re: [Architecture] Base paths to use for the APIs exposed from carbon-auth

HI, Shouldn't we adhere to the existing APIs [1], [2] in Identity Server 5.x at > the moment? Otherwise, users who have written applications based on the > existing APIs won't be able to migrate easily. If I am not mistaken, C5 > based Identity Server is based on carbon-auth. Since auth

[Architecture] OpenAPI 3.0 support for API Manager 2.2.0

Hi All, We are planning to provide OpenAPI 3.0 specification support for API Manager 2.2.0 [1]. We did a background research on what's new in OpenAPI and the feasibility of providing OpenAPI 3.0 support over APIM 2.2.0. As per the current architecture of APIM, it is feasible to support OpenAPI

Re: [Architecture] Base paths to use for the APIs exposed from carbon-auth

Hi Malintha, Shouldn't we adhere to the existing APIs [1], [2] in Identity Server 5.x at the moment? Otherwise, users who have written applications based on the existing APIs won't be able to migrate easily. If I am not mistaken, C5 based Identity Server is based on carbon-auth. [1] -

[Architecture] Scope Registration API for carbon-auth

Hi All, We are thinking about adding scope registration support to our carbon-auth implementation. For this we will need to have API to add/update/delete/list scopes. When we analyzed current implementation of API its designed to have API name as unique identifier. Or we can use UUID for that to

Re: [Architecture] Base paths to use for the APIs exposed from carbon-auth

- apim-group, +architecture On Mon, Jan 8, 2018 at 7:21 PM, Malintha Amarasinghe wrote: > Hi All, > > The carbon-auth [1] component we are currently working on exposing a set > of APIs for authentication/authorization purposes. This is to propose a set > of base paths to be

[Architecture] Decoupling Client Authentication from OAuth2 Flow

The idea behind this is to decouple the authentication mechanism used by OAuth2 clients from the rest of the OAuth2 logic, so that different types of client authenticators can be plugged. For an example according to specification [1] client_secret_basic, client_secret_post, client_secret_jwt are

Re: [Architecture] Ho to use WSO2 IS to manage our applications ?

Hi Youcef, App Manager had the following feature. 1) Easy SSO 2) End-user application portal to list SSO apps 3) Publisher portal to manage applications 4) Web access manager App Manager used the Identity Server internals for SSO. #2, #3 and #4 were planned for upcoming Identity Server