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

[Rushmin Fernando]

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 releases. But we
had to revise the plans and this is still under discussion.

I agree that the message on the app manager web site is misleading. Please
accept my apologies.

Could you please let us know the exact features of App Manager you are
looking for?

Best Regards,
Rushmin


On Sun, Jan 7, 2018 at 10:20 PM, Youcef HILEM 
wrote:

> Hi IS team,
>
> WSO2 App Manager was created as a mechanism to offer a standalone solution
> for publishing and managing all aspects of an application and its
> lifecycle.
> We currently have this capability within WSO2 Identity Server (WSO2 IS),
> and
> we encourage you to continue to use WSO2 IS to manage your applications
> [1].
>
> Can you please tel me where is this capability in WSO21 IS ?
>
>
> [1] https://wso2.com/products/app-manager/
>
> Thanks
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc.  - Lean . Enterprise . Middleware

mobile : +94775615183
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Decoupling Client Authentication from OAuth2 Flow

[Hasintha Indrajee]

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 few client authentication mechanisms.

The client authentication will be done through an extension. Hence
different client authentication criteria can be implemented and can be
plugged.

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 authentication client ID will be
available in the context.

3) getClientId - Depending on the authentication mechanism they way client
ID is extracted depends. For an example in JWT client authentication client
sends out the client Id within the JWT as the subject. Hence in a case
authenticaiton fails, we may need to extract client Id for other puposes.
ex - data publishing, if the client is non confidential.

The client authenticator has to be implemented as an OSGI bundle and should
be deployed in dropins upon building. Also relevant authenticator name has
to be configured in identity.xml under client authenticators.









[1] http://openid.net/specs/openid-connect-core-1_0.html#
ClientAuthentication







-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453 <077%20189%202453>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Malintha Amarasinghe]

- 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 used on those APIs.
>
> As a convention we have been using below format when defining base paths
> for the currently available REST APIs in API Manager:
>
> /api/**/**/v**
>
> eg: /api/am/publisher/v1.0
>
> Below are the suggested basepaths:
>
> 1. Client Registration and Management REST API
> /api/auth/dcr/v1.0
>
> 2. OAuth REST API
> /api/auth/oauth/v1.0
>
> 3. SCIM REST API
> /api/auth/scim/v1.0
>
> 4. Scope Registration REST API
> /api/auth/scope-registration/v1.0
>
> 5. Token Introspection REST API
> /api/auth/introspect/v1.0
>
>
> *Note:* I have used "auth" instead of the product name.
>
> Appreciate your thoughts on this.
>
> [1] https://github.com/wso2/carbon-auth
>
> Thanks!
> Malintha
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>



-- 
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/

Mobile : +94 712383306 <+94%2071%20238%203306>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Scope Registration API for carbon-auth

[Sanjeewa Malalgoda]

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 adhere
approach we followed for other APIs. But i dont see issue with having name
as unique identifier if its unique. Myself and Malintha had quick
discussion about scope registration API and came up with following attached
REST API. We have removed name from resource path of existing API.

We need to think about authentication mechanism for this API as API
creators will allow to add scopes per API. Also we need to think how should
we handle adding same scope name by different users for different APIs. If
one user defined read scope then others may not be able to define same
scope.

Since identity server team had experiences with this API they can provide
suggestions for API and implementation. We will expose this as MSF4J based
API from carbon auth run time.

Lets use this thread to discuss all aspects of scope registration and
finalize implementation.

Thanks,
sanjeewa.
-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/



swagger.yaml
Description: application/yaml
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Pubudu Gunatilaka]

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] -
https://docs.wso2.com/display/IS540/apidocs/OAuth2-dynamic-client-registration/#!/operations#OAuthDCR#registerApplication

[2] - https://docs.wso2.com/display/IS540/SCIM+2.0+REST+APIs

Thank you!

On Mon, Jan 8, 2018 at 7:34 PM, Malintha Amarasinghe 
wrote:

> - 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 used on those APIs.
>>
>> As a convention we have been using below format when defining base paths
>> for the currently available REST APIs in API Manager:
>>
>> /api/**/**/v**
>>
>> eg: /api/am/publisher/v1.0
>>
>> Below are the suggested basepaths:
>>
>> 1. Client Registration and Management REST API
>> /api/auth/dcr/v1.0
>>
>> 2. OAuth REST API
>> /api/auth/oauth/v1.0
>>
>> 3. SCIM REST API
>> /api/auth/scim/v1.0
>>
>> 4. Scope Registration REST API
>> /api/auth/scope-registration/v1.0
>>
>> 5. Token Introspection REST API
>> /api/auth/introspect/v1.0
>>
>>
>> *Note:* I have used "auth" instead of the product name.
>>
>> Appreciate your thoughts on this.
>>
>> [1] https://github.com/wso2/carbon-auth
>>
>> Thanks!
>> Malintha
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306 <+94%2071%20238%203306>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Senior Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] OpenAPI 3.0 support for API Manager 2.2.0

[Thilini Shanika]

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 3.0
spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
migrated APIs from previous releases)

Following are the functionalities we are planning to ship with this new
feature.

   1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs (When
   an API is created from the scratch, the underneath API definition will be
   generated in OpenAPI 3.0)
   2. The API definitions of migrated APIs from previous releases are based
   on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be continued for
   migrated APIs
   3. Providing support to import OpenAPI 3.0 spec based API definitions
   while creating an API from an existing source.
   4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version so that
   it will be supporting OpenAPI 3.0 spec while updating API source via
   Swagger Editor in API Publisher.
   5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so that API
   Console in API Store will be supporting OpenAPI 3.0 based API definitions
   6. Providing the functionality of switching the gateway environment
   endpoints for OpenAPI 3.0 specific APIs (If it is a Swagger 2.0 based API
   definition, the relevant gateway endpoint should be specified in host,
   basepath and schema elements of the Swagger definition. But in OpenAPI 3.0,
   the gateway endpoint details should be specified under server element of
   the definition. )


Any suggestions to improve the functionalities and usability aspects of the
feature? Your comments and thoughts on this are highly appreciated.

[1] https://github.com/wso2/carbon-apimgt/issues/4897

Thanks

-- 
Thilini Shanika
Senior Software Engineer
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3

E-mail: tgtshan...@gmail.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Rukshan Premathunga]

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 components are ships initially  with APIM, migration will not be
a big issue right? even for AM 3, it support IS 5.4.0 at the moment. But in
further for IS or any other product need backward compatibility, product IS
can support backward compatible endpoints. So that, it can be deprecated
and new REST API can be introduce as new feature.

Thanks and Regards



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. If I am not mistaken, C5
> based Identity Server is based on carbon-auth.
>
> [1] - https://docs.wso2.com/display/IS540/apidocs/OAuth2-dynamic-
> client-registration/#!/operations#OAuthDCR#registerApplication
> 
> [2] - https://docs.wso2.com/display/IS540/SCIM+2.0+REST+APIs
>
> Thank you!
>
> On Mon, Jan 8, 2018 at 7:34 PM, Malintha Amarasinghe 
> wrote:
>
>> - 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 used on those APIs.
>>>
>>> As a convention we have been using below format when defining base paths
>>> for the currently available REST APIs in API Manager:
>>>
>>> /api/**/**/v**
>>>
>>> eg: /api/am/publisher/v1.0
>>>
>>> Below are the suggested basepaths:
>>>
>>> 1. Client Registration and Management REST API
>>> /api/auth/dcr/v1.0
>>>
>>> 2. OAuth REST API
>>> /api/auth/oauth/v1.0
>>>
>>> 3. SCIM REST API
>>> /api/auth/scim/v1.0
>>>
>>> 4. Scope Registration REST API
>>> /api/auth/scope-registration/v1.0
>>>
>>> 5. Token Introspection REST API
>>> /api/auth/introspect/v1.0
>>>
>>>
>>> *Note:* I have used "auth" instead of the product name.
>>>
>>> Appreciate your thoughts on this.
>>>
>>> [1] https://github.com/wso2/carbon-auth
>>>
>>> Thanks!
>>> Malintha
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
+94711822074
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] latest security updates for WSO2 IS

[Roman CHRENKO]

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 Server version 1.2.0? Isn't it a 
mistake?
Link "Security Advisory Link" redirects to 
https://docs.wso2.com/display/Security/Security+Advisory+WSO2-2017-0326 which 
shows no Identity Server between affected products.

And I have another question to latest security updates for WSO2 IS.
When I try to download any other security patch, for example 
http://product-dist.wso2.com/downloads/carbon/wilkes/patch0991/WSO2-CARBON-PATCH-4.4.0-0991.zip
 from Sept.2017, it asks from me SVN username and password. Does it mean that 
it is avaliable only for users which credentials are associated with an active 
WSO2 subscription?
If not, how can I create SVN account for downloading security patches?

Best regards,
Roman


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Shazni Nazeer]

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:

>
>
> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:
>
>> 1) The SP UI will have a new text area to enter the certificate in PEM
>> format.
>> Is there any specific reason to use text area here? In IDP UI, we
>> have an option to upload the idp cert. IMO it is better to have that 
>> option
>> in SP UI as well for the UI consistance. '
>>
>
>>
>>> It is bit easier for users to paste the content staight away rather than
>> uploading files.
>> +1 for making both UIs consistent.
>
>
>> +! for certificate upload mechanism for consistency. I think uploading
>> will be much easier than pasting the text.
>>
>
>
>
> Thank you for the feedback Shazni. I agree that uploading might be eaiser
> when you have the file in hand. But we have following cons as well given
> that a PEM encoded ceritificate is a text content which is about 10 lines.
>
>
> 1) Uploading a file needs a file name and the filename is an unwated data
> in our case.
>
> 2) If you want to view the uploaded PEM file later, you have to download
> it. (It is cleaner when you see the content in the UI)
>
>
>
>
>>
>>
>> Also if the user can still add the certificate of the SP to the keystore
>> and also from the UI, what would be the behavior when one of the
>> certificate is invalid or expired and the other one is correct? Will there
>> be any precedence, such as if it's in DB it will only check in DB or
>> whether it checks in both DB and keystore?
>>
>> On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:
>>
>>> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
>>> wrote:
>>>
 Hi Godwin,

 IMO certificate is a first class member of a service provider. So
 storing it as a field in SP_APP is cleaner.

 On the other hand, the datatype of a certificate doesn't really go with
 other metadata.

 In the best case, we have to alter the metadata table to hold a VARCHAR
 of like 1000 characters.

 Considering all of these facts, I thought of using the SP_APP table
 instead of SP_METADATA.

 What do you think?

 On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal 
 wrote:

> Hi Rushmin,
>
> Any reason to use SP_APP table to persist the certificate? We have a
> table called SP_METADATA to SP related metadata. I think we can use that
> table without changing any DB Schema. WDYT?
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
> wrote:
>
>>
>>
>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi Rushmin,

 *How is this done now?*
>
> The application certificate should be imported to the keystore file
> and the alias should be mentioned in the service provider so that
> the service provider can validate the signature against the
> certificate identified by that alias.
>

 If we have the current option of  importing the certificate to the
 keystore, in JWT client authentication [1] we have to provide the
 certificate alias as the client id inorder to identify the 
 application. So
 with this implementation we don't need to enforce end users to do the 
 above
 as we can fetch the client_id directly from the db.

 +1 for the approach.

 [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

 Thanks,

 On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando >>> > wrote:

>
> In the identity server, a service provider represents the
> application which uses the Identity Server as an Identity Provider.
>
> In some cases, Identity Server needs to validate the identity of
> the application to make sure the authentication/authorization 
> requests are
> coming from the legitimate application.
>
> *How is this done now?*
>
> The application certificate should be imported to the
> keystore file and the alias should be mentioned in the service 
> provider so
> that the service provider can validate the signature against the
> certificate identified by that alias.
>
> *Why is this needs to be improved?*
>
> 1) keystore file resides in the file system. Therefore in a

Re: [Architecture] latest security updates for WSO2 IS

[Pubudu Gunatilaka]

+ Adding Tharindu and Prakhash

On Mon, Jan 8, 2018 at 9:11 PM, Roman CHRENKO 
wrote:

> 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 Server version 1.2.0? Isn't
> it a mistake?
>
> Link "Security Advisory Link" redirects to https://docs.wso2.com/display/
> Security/Security+Advisory+WSO2-2017-0326 which shows no Identity Server
> between affected products.
>
>
>
> And I have another question to latest security updates for WSO2 IS.
>
> When I try to download any other security patch, for example
> http://product-dist.wso2.com/downloads/carbon/wilkes/
> patch0991/WSO2-CARBON-PATCH-4.4.0-0991.zip from Sept.2017, it asks from
> me SVN username and password. Does it mean that it is avaliable only for
> users which credentials are associated with an active WSO2 subscription?
>
> If not, how can I create SVN account for downloading security patches?
>
>
>
> Best regards,
>
> Roman
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Senior Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] latest security updates for WSO2 IS

[Tharindu Edirisinghe]

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 the version 1.2.0, which should be for Machine Learner
1.2.0 version.

You have mentioned that the security advisory https://docs.wso2.com/display/
Security/Security+Advisory+WSO2-2017-0326 does not list Identity Server.
The reason for that is, we publicly release security advisories and
security patches only for the latest version of WSO2 products. At the time
of this advisory got released, the latest version of WSO2 Identity Server
was 5.4.0 version which was not affected by this vulnerability. Therefore
the above advisory has not listed Identity Server.

The publicly released security patches do not require authentication for
downloading. I double checked the following link you provided and it does
not require authentication, and simply downloads the zip file.

http://product-dist.wso2.com/downloads/carbon/wilkes/
patch0991/WSO2-CARBON-PATCH-4.4.0-0991.zip

If you need further clarifications, feel free to get back.

Thanks,
Tharindu Edirisinghe



On Mon, Jan 8, 2018 at 10:41 AM, Roman CHRENKO 
wrote:

> 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 Server version 1.2.0? Isn't
> it a mistake?
>
> Link "Security Advisory Link" redirects to https://docs.wso2.com/display/
> Security/Security+Advisory+WSO2-2017-0326 which shows no Identity Server
> between affected products.
>
>
>
> And I have another question to latest security updates for WSO2 IS.
>
> When I try to download any other security patch, for example
> http://product-dist.wso2.com/downloads/carbon/wilkes/
> patch0991/WSO2-CARBON-PATCH-4.4.0-0991.zip from Sept.2017, it asks from
> me SVN username and password. Does it mean that it is avaliable only for
> users which credentials are associated with an active WSO2 subscription?
>
> If not, how can I create SVN account for downloading security patches?
>
>
>
> Best regards,
>
> Roman
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Tharindu Edirisinghe
Senior Software Engineer | WSO2 Inc
Platform Security Team
Blog : http://tharindue.blogspot.com
mobile : +94 775181586
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] latest security updates for WSO2 IS

[Tharindu Edirisinghe]

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,
Tharindu Edirisinghe

On Mon, Jan 8, 2018 at 11:32 AM, Tharindu Edirisinghe 
wrote:

> 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 the version 1.2.0, which should be for Machine Learner
> 1.2.0 version.
>
> You have mentioned that the security advisory
> https://docs.wso2.com/display/Security/Security+Advisory+WSO2-2017-0326
> does not list Identity Server. The reason for that is, we publicly release
> security advisories and security patches only for the latest version of
> WSO2 products. At the time of this advisory got released, the latest
> version of WSO2 Identity Server was 5.4.0 version which was not affected by
> this vulnerability. Therefore the above advisory has not listed Identity
> Server.
>
> The publicly released security patches do not require authentication for
> downloading. I double checked the following link you provided and it does
> not require authentication, and simply downloads the zip file.
>
> http://product-dist.wso2.com/downloads/carbon/wilkes/patch09
> 91/WSO2-CARBON-PATCH-4.4.0-0991.zip
>
> If you need further clarifications, feel free to get back.
>
> Thanks,
> Tharindu Edirisinghe
>
> 
>
> On Mon, Jan 8, 2018 at 10:41 AM, Roman CHRENKO 
> wrote:
>
>> 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 Server version 1.2.0?
>> Isn't it a mistake?
>>
>> Link "Security Advisory Link" redirects to https://docs.wso2.com/display/
>> Security/Security+Advisory+WSO2-2017-0326 which shows no Identity Server
>> between affected products.
>>
>>
>>
>> And I have another question to latest security updates for WSO2 IS.
>>
>> When I try to download any other security patch, for example
>> http://product-dist.wso2.com/downloads/carbon/wilkes/patch09
>> 91/WSO2-CARBON-PATCH-4.4.0-0991.zip from Sept.2017, it asks from me SVN
>> username and password. Does it mean that it is avaliable only for users
>> which credentials are associated with an active WSO2 subscription?
>>
>> If not, how can I create SVN account for downloading security patches?
>>
>>
>>
>> Best regards,
>>
>> Roman
>>
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Tharindu Edirisinghe
> Senior Software Engineer | WSO2 Inc
> Platform Security Team
> Blog : http://tharindue.blogspot.com
> mobile : +94 775181586 <+94%2077%20518%201586>
>



-- 

Tharindu Edirisinghe
Senior Software Engineer | WSO2 Inc
Platform Security Team
Blog : http://tharindue.blogspot.com
mobile : +94 775181586
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Bhathiya Jayasekara]

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.

Thanks.
Bhathiya

On Mon, Jan 8, 2018 at 7:58 PM, Thilini Shanika  wrote:

> 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 3.0
> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
> migrated APIs from previous releases)
>
> Following are the functionalities we are planning to ship with this new
> feature.
>
>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs (When
>an API is created from the scratch, the underneath API definition will be
>generated in OpenAPI 3.0)
>2. The API definitions of migrated APIs from previous releases are
>based on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be continued
>for migrated APIs
>3. Providing support to import OpenAPI 3.0 spec based API definitions
>while creating an API from an existing source.
>4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version so
>that it will be supporting OpenAPI 3.0 spec while updating API source via
>Swagger Editor in API Publisher.
>5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so that
>API Console in API Store will be supporting OpenAPI 3.0 based API
>definitions
>6. Providing the functionality of switching the gateway environment
>endpoints for OpenAPI 3.0 specific APIs (If it is a Swagger 2.0 based API
>definition, the relevant gateway endpoint should be specified in host,
>basepath and schema elements of the Swagger definition. But in OpenAPI 3.0,
>the gateway endpoint details should be specified under server element of
>the definition. )
>
>
> Any suggestions to improve the functionalities and usability aspects of
> the feature? Your comments and thoughts on this are highly appreciated.
>
> [1] https://github.com/wso2/carbon-apimgt/issues/4897
>
> Thanks
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>
>


-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Farasath Ahamed]

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 to
> specification [1] client_secret_basic, client_secret_post,
> client_secret_jwt are few client authentication mechanisms.
>
> The client authentication will be done through an extension. Hence
> different client authentication criteria can be implemented and can be
> plugged.
>
> 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 authentication client ID will be
> available in the context.
>
> 3) getClientId - Depending on the authentication mechanism they way client
> ID is extracted depends. For an example in JWT client authentication client
> sends out the client Id within the JWT as the subject. Hence in a case
> authenticaiton fails, we may need to extract client Id for other puposes.
> ex - data publishing, if the client is non confidential.
>
> The client authenticator has to be implemented as an OSGI bundle and
> should be deployed in dropins upon building. Also relevant authenticator
> name has to be configured in identity.xml under client authenticators.
>
> 
>
>  ClientAuthHandler>
>
> 
>

Do we have any plan in future to facilitate defining client authenticators
per OAuth application (service provider)?
Also do we have a way to define an oauth application as non-confidential
using the UI or do we need to write a custom client authentication handler
to do so?

>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
> entAuthentication
> 
>
>
>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <077%20189%202453>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [MB4] Authorization Model for Message Broker

[Waruna Jayaweera]

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 need to restrict users in
group as below.

   1. T1 can be subscribed by only A and publish by only B
   2. T2 can be subscribed by only B and publish by only A
   3. Manager users can subscribe and publish to any topic but only
   subscribe queue.

Following entities can be identified.

*User groups:*  A ,B and manager
*Resources *: T1 and T2
*Resource Groups *: Topic, Queue
*Actions*: subscribe, publish,view  etc.
*Permission*: resource+actions

We can represent the permissions using binary form  mappings with resource
and user group. These permissions can be defined per resource or globally
as well.

*Per Resource*

Resource

User Group

Actions

Permission

publish

subscribe

T1

A

0

1

01

T2

B

1

0

10

*Global Permission*

Resource Type

User Group

Actions

Permission

publish

subscribe

Topic

admin

1

1

11

Queue

admin

1

0

10


Permission will be stored in the database similarly as of  [1].  Following
figure shows the proposed implementation for $subject.



Connection handler can fetch the mb resource permissions mappings from
database and user groups information from underlying user store manager.
Authorized users can add permissions to groups using permission api. Each
resource can have own way of handling permission. As an example in
hierarchical  topic scenario, if given user group has permission to top
level topic, will be granted the permission to lower level topic structure
as well.

This is the initial design for permission model and We will schedule a
design review to further discussion .Your suggestions are highly
appreciated!

[1] [Architecture] [APIM][C5] API Manager entities(APIs/Applications/Docs
etc..) permission model and group sharing.

Thanks,
Waruna

-- 
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198 <+94%2071%20325%205198>
http://waruapz.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Waruna Jayaweera]

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 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 need to restrict users in
> group as below.
>
>1. T1 can be subscribed by only A and publish by only B
>2. T2 can be subscribed by only B and publish by only A
>3. Manager users can subscribe and publish to any topic but only
>subscribe queue.
>
> Following entities can be identified.
>
> *User groups:*  A ,B and manager
> *Resources *: T1 and T2
> *Resource Groups *: Topic, Queue
> *Actions*: subscribe, publish,view  etc.
> *Permission*: resource+actions
>
> We can represent the permissions using binary form  mappings with resource
> and user group. These permissions can be defined per resource or globally
> as well.
>
> *Per Resource*
>
> Resource
>
> User Group
>
> Actions
>
> Permission
>
> publish
>
> subscribe
>
> T1
>
> A
>
> 0
>
> 1
>
> 01
>
> T2
>
> B
>
> 1
>
> 0
>
> 10
>
> *Global Permission*
>
> Resource Type
>
> User Group
>
> Actions
>
> Permission
>
> publish
>
> subscribe
>
> Topic
>
> admin
>
> 1
>
> 1
>
> 11
>
> Queue
>
> admin
>
> 1
>
> 0
>
> 10
>
>
> Permission will be stored in the database similarly as of  [1].  Following
> figure shows the proposed implementation for $subject.
>
>
>
> Connection handler can fetch the mb resource permissions mappings from
> database and user groups information from underlying user store manager.
> Authorized users can add permissions to groups using permission api. Each
> resource can have own way of handling permission. As an example in
> hierarchical  topic scenario, if given user group has permission to top
> level topic, will be granted the permission to lower level topic structure
> as well.
>
> This is the initial design for permission model and We will schedule a
> design review to further discussion .Your suggestions are highly
> appreciated!
>
> [1] [Architecture] [APIM][C5] API Manager entities(APIs/Applications/Docs
> etc..) permission model and group sharing.
>
> Thanks,
> Waruna
>
> --
> Regards,
>
> Waruna Lakshitha Jayaweera
> Senior Software Engineer
> WSO2 Inc; http://wso2.com
> phone: +94713255198 <+94%2071%20325%205198>
> http://waruapz.blogspot.com/
>
>


-- 
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198
http://waruapz.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Rajith Roshan]

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. If I am not mistaken, C5
> based Identity Server is based on carbon-auth.
>
Yes, agree with Pubudu. If customers have written client applications based
on the existing apis, then they will have to release a new version of their
client application when they are migrating to new APIM 3.0

>
> [1] - https://docs.wso2.com/display/IS540/apidocs/OAuth2-dynamic-
> client-registration/#!/operations#OAuthDCR#registerApplication
> 
> [2] - https://docs.wso2.com/display/IS540/SCIM+2.0+REST+APIs
>
> Thank you!
>
> On Mon, Jan 8, 2018 at 7:34 PM, Malintha Amarasinghe 
> wrote:
>
>> - 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 used on those APIs.
>>>
>>> As a convention we have been using below format when defining base paths
>>> for the currently available REST APIs in API Manager:
>>>
>>> /api/**/**/v**
>>>
>>> eg: /api/am/publisher/v1.0
>>>
>>> Below are the suggested basepaths:
>>>
>>> 1. Client Registration and Management REST API
>>> /api/auth/dcr/v1.0
>>>
>>> 2. OAuth REST API
>>> /api/auth/oauth/v1.0
>>>
>>> 3. SCIM REST API
>>> /api/auth/scim/v1.0
>>>
>>> 4. Scope Registration REST API
>>> /api/auth/scope-registration/v1.0
>>>
>>> 5. Token Introspection REST API
>>> /api/auth/introspect/v1.0
>>>
>>>
>>> *Note:* I have used "auth" instead of the product name.
>>>
>>> Appreciate your thoughts on this.
>>>
>>> [1] https://github.com/wso2/carbon-auth
>>>
>>> Thanks!
>>> Malintha
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Chamila Adhikarinayake]

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 with the rest
api (for backward compatibility)

[1]
https://docs.wso2.com/display/AM210/apidocs/publisher/#!/operations#APICollection#apisPost
[2]
https://docs.wso2.com/display/AM210/apidocs/publisher/#!/operations#APIIndividual#apisApiIdSwaggerPut

Chamila.

On Mon, Jan 8, 2018 at 10:59 PM, Bhathiya Jayasekara 
wrote:

> 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.
>
> Thanks.
> Bhathiya
>
> On Mon, Jan 8, 2018 at 7:58 PM, Thilini Shanika  wrote:
>
>> 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 3.0
>> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
>> migrated APIs from previous releases)
>>
>> Following are the functionalities we are planning to ship with this new
>> feature.
>>
>>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs
>>(When an API is created from the scratch, the underneath API definition
>>will be generated in OpenAPI 3.0)
>>2. The API definitions of migrated APIs from previous releases are
>>based on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be 
>> continued
>>for migrated APIs
>>3. Providing support to import OpenAPI 3.0 spec based API definitions
>>while creating an API from an existing source.
>>4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version so
>>that it will be supporting OpenAPI 3.0 spec while updating API source via
>>Swagger Editor in API Publisher.
>>5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so that
>>API Console in API Store will be supporting OpenAPI 3.0 based API
>>definitions
>>6. Providing the functionality of switching the gateway environment
>>endpoints for OpenAPI 3.0 specific APIs (If it is a Swagger 2.0 based API
>>definition, the relevant gateway endpoint should be specified in host,
>>basepath and schema elements of the Swagger definition. But in OpenAPI 
>> 3.0,
>>the gateway endpoint details should be specified under server element of
>>the definition. )
>>
>>
>> Any suggestions to improve the functionalities and usability aspects of
>> the feature? Your comments and thoughts on this are highly appreciated.
>>
>> [1] https://github.com/wso2/carbon-apimgt/issues/4897
>>
>> Thanks
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,
Chamila Adhikarinayake
Senior Software Engineer
WSO2, Inc.
Mobile - +94712346437
Email  - chami...@wso2.com
Blog  -  http://helpfromadhi.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Hasanthi Purnima Dissanayake]

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 authentication client ID will be
> available in the context.
>
> 3) getClientId - Depending on the authentication mechanism they way client
> ID is extracted depends. For an example in JWT client authentication client
> sends out the client Id within the JWT as the subject. Hence in a case
> authenticaiton fails, we may need to extract client Id for other puposes.
> ex - data publishing, if the client is non confidential.
>

What will be the method parameters for the above methods. I suppose we can
and need to pass OAuthTOkenReqMessageContext for all the three methods as a
parameter. So we can process the request and obtain the necessary query
parameters from the request. Obtaining clientID may be different from
mechanism to mechanism, but I think any how the request should contain the
clientID.

Thanks.
Hasanthi

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 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 few client authentication mechanisms.
>>
>> The client authentication will be done through an extension. Hence
>> different client authentication criteria can be implemented and can be
>> plugged.
>>
>> 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 authentication client ID will be
>> available in the context.
>>
>> 3) getClientId - Depending on the authentication mechanism they way
>> client ID is extracted depends. For an example in JWT client authentication
>> client sends out the client Id within the JWT as the subject. Hence in a
>> case authenticaiton fails, we may need to extract client Id for other
>> puposes. ex - data publishing, if the client is non confidential.
>>
>> The client authenticator has to be implemented as an OSGI bundle and
>> should be deployed in dropins upon building. Also relevant authenticator
>> name has to be configured in identity.xml under client authenticators.
>>
>> 
>>
>> 
>> 
>>
>> 
>>
>
> Do we have any plan in future to facilitate defining client authenticators
> per OAuth application (service provider)?
> Also do we have a way to define an oauth application as non-confidential
> using the UI or do we need to write a custom client authentication handler
> to do so?
>
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
>> entAuthentication
>> 
>>
>>
>>
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <077%20189%202453>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Isura Karunaratne]

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 to
> specification [1] client_secret_basic, client_secret_post,
> client_secret_jwt are few client authentication mechanisms.
>
> The client authentication will be done through an extension. Hence
> different client authentication criteria can be implemented and can be
> plugged.
>
> 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 authentication client ID will be
> available in the context.
>
> 3) getClientId - Depending on the authentication mechanism they way client
> ID is extracted depends. For an example in JWT client authentication client
> sends out the client Id within the JWT as the subject. Hence in a case
> authenticaiton fails, we may need to extract client Id for other puposes.
> ex - data publishing, if the client is non confidential.
>
> The client authenticator has to be implemented as an OSGI bundle and
> should be deployed in dropins upon building. Also relevant authenticator
> name has to be configured in identity.xml under client authenticators.
>
> 
>
>  ClientAuthHandler>
>
> 
>

How are we going to support, non-confidentials clients, will that support
through another ClientAuthHandler? Also, Do we support backword compatibity
for exsting ClientAuthHandlers?


Thanks
Isura
>
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
> entAuthentication
> 
>
>
>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <077%20189%202453>
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Lakmal Warusawithana]

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]. 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 3.0
> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
> migrated APIs from previous releases)
>
> Following are the functionalities we are planning to ship with this new
> feature.
>
>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs (When
>an API is created from the scratch, the underneath API definition will be
>generated in OpenAPI 3.0)
>2. The API definitions of migrated APIs from previous releases are
>based on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be continued
>for migrated APIs
>3. Providing support to import OpenAPI 3.0 spec based API definitions
>while creating an API from an existing source.
>4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version so
>that it will be supporting OpenAPI 3.0 spec while updating API source via
>Swagger Editor in API Publisher.
>5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so that
>API Console in API Store will be supporting OpenAPI 3.0 based API
>definitions
>6. Providing the functionality of switching the gateway environment
>endpoints for OpenAPI 3.0 specific APIs (If it is a Swagger 2.0 based API
>definition, the relevant gateway endpoint should be specified in host,
>basepath and schema elements of the Swagger definition. But in OpenAPI 3.0,
>the gateway endpoint details should be specified under server element of
>the definition. )
>
>
> Any suggestions to improve the functionalities and usability aspects of
> the feature? Your comments and thoughts on this are highly appreciated.
>
> [1] https://github.com/wso2/carbon-apimgt/issues/4897
>
> Thanks
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>
>


-- 
Lakmal Warusawithana
Senior Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Hasintha Indrajee]

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 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 few client authentication mechanisms.
>>
>> The client authentication will be done through an extension. Hence
>> different client authentication criteria can be implemented and can be
>> plugged.
>>
>> 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 authentication client ID will be
>> available in the context.
>>
>> 3) getClientId - Depending on the authentication mechanism they way
>> client ID is extracted depends. For an example in JWT client authentication
>> client sends out the client Id within the JWT as the subject. Hence in a
>> case authenticaiton fails, we may need to extract client Id for other
>> puposes. ex - data publishing, if the client is non confidential.
>>
>> The client authenticator has to be implemented as an OSGI bundle and
>> should be deployed in dropins upon building. Also relevant authenticator
>> name has to be configured in identity.xml under client authenticators.
>>
>> 
>>
>> 
>> 
>>
>> 
>>
>
> Do we have any plan in future to facilitate defining client authenticators
> per OAuth application (service provider)?
> Also do we have a way to define an oauth application as non-confidential
> using the UI or do we need to write a custom client authentication handler
> to do so?
>

The scope of this task is to decouple authentication, ie we should be able
to plug different type of client authenticators which is now coupled to
client basic authentication. Also we have identified number of improvements
we can do regarding confidential clients other areas which are relevant.
Since those tasks don't fall under this they will be addressed separately.

>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
>> entAuthentication
>> 
>>
>>
>>
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <077%20189%202453>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Hasintha Indrajee]

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 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 few client authentication mechanisms.
>>
>> The client authentication will be done through an extension. Hence
>> different client authentication criteria can be implemented and can be
>> plugged.
>>
>> 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 authentication client ID will be
>> available in the context.
>>
>> 3) getClientId - Depending on the authentication mechanism they way
>> client ID is extracted depends. For an example in JWT client authentication
>> client sends out the client Id within the JWT as the subject. Hence in a
>> case authenticaiton fails, we may need to extract client Id for other
>> puposes. ex - data publishing, if the client is non confidential.
>>
>> The client authenticator has to be implemented as an OSGI bundle and
>> should be deployed in dropins upon building. Also relevant authenticator
>> name has to be configured in identity.xml under client authenticators.
>>
>> 
>>
>> 
>> 
>>
>> 
>>
>
> How are we going to support, non-confidentials clients, will that support
> through another ClientAuthHandler? Also, Do we support
> backword compatibity for exsting ClientAuthHandlers?
>

Client authenticator will only authenticate if the application is
confidential. If not, still a client authenticator can be introduced to
extract client ID. If no authenticator can handle (either authenticate/
extract client ID) it will try to extract client ID from the body of the
request and allow to go forward if it's non confidential. Otherwise it will
fail.

Most probably there will be a code migration required since there will be
subtle changes in client authenticator interface. Ideally as per the
current way there shouldn't be much custom client auth handlers implemented
since the authentication was tightly coupled to the rest of the flow.

>
>
> Thanks
> Isura
>>
>>
>> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
>> entAuthentication
>> 
>>
>>
>>
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <077%20189%202453>
>>
>>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810 <077%20225%204810>
> Blog : http://isurad.blogspot.com/
>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453 <077%20189%202453>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Karunarathna]

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
> 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 adhere
> approach we followed for other APIs. But i dont see issue with having name
> as unique identifier if its unique. Myself and Malintha had quick
> discussion about scope registration API and came up with following attached
> REST API. We have removed name from resource path of existing API.
>

 An Identity provider can act as the central authorization server for
multiple resource servers. In that case same Scope can imterprit by
different resource servers in different manner.
So scope should be unique with Scope + resource server and each combination
will couple with a binding

>
> We need to think about authentication mechanism for this API as API
> creators will allow to add scopes per API. Also we need to think how should
> we handle adding same scope name by different users for different APIs. If
> one user defined read scope then others may not be able to define same
> scope.
>
In this case I think scope should be unique within the resource server
where it can have a globel validation rule. And it whould be easy to
configure with external authorization servers.

-Ishara

>
> Since identity server team had experiences with this API they can provide
> suggestions for API and implementation. We will expose this as MSF4J based
> API from carbon auth run time.
>
> Lets use this thread to discuss all aspects of scope registration and
> finalize implementation.
>
> Thanks,
> sanjeewa.
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Ishara Karunarathna
Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Thilini Shanika]

@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 versions for
APIs which are created from scratch in API Publisher. We would further
check the feasibility and alternative solutions of supporting both versions
in API Design phase.

@Chamila
Thanks for bringing this up for discussion. Yes, we are planning to support
both swagger versions in REST APIs like API create, API update, API
Definition Update etc.

@Lakmal
I moved the summery of the conversation to [1] and we can continue the rest
of the discussion in the GitHub issue itself.

On Tue, Jan 9, 2018 at 9:37 AM, Lakmal Warusawithana 
wrote:

> 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]. 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 3.0
>> spec, parallel with Swagger 2.0 (Swagger 2.0 support is required for
>> migrated APIs from previous releases)
>>
>> Following are the functionalities we are planning to ship with this new
>> feature.
>>
>>1. Supporting OpenAPI 3.0 spec for newly designing/Creating APIs
>>(When an API is created from the scratch, the underneath API definition
>>will be generated in OpenAPI 3.0)
>>2. The API definitions of migrated APIs from previous releases are
>>based on Swagger 2.0 spec. Thus, Swagger 2.0 spec support will be 
>> continued
>>for migrated APIs
>>3. Providing support to import OpenAPI 3.0 spec based API definitions
>>while creating an API from an existing source.
>>4. Swagger editor in APIM 2.2.0 has been upgraded to 3.x version so
>>that it will be supporting OpenAPI 3.0 spec while updating API source via
>>Swagger Editor in API Publisher.
>>5. Swagger UI in APIM 2.2.0 has been upgraded to 3.x version so that
>>API Console in API Store will be supporting OpenAPI 3.0 based API
>>definitions
>>6. Providing the functionality of switching the gateway environment
>>endpoints for OpenAPI 3.0 specific APIs (If it is a Swagger 2.0 based API
>>definition, the relevant gateway endpoint should be specified in host,
>>basepath and schema elements of the Swagger definition. But in OpenAPI 
>> 3.0,
>>the gateway endpoint details should be specified under server element of
>>the definition. )
>>
>>
>> Any suggestions to improve the functionalities and usability aspects of
>> the feature? Your comments and thoughts on this are highly appreciated.
>>
>> [1] https://github.com/wso2/carbon-apimgt/issues/4897
>>
>> Thanks
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> Lakmal Warusawithana
> Senior Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692 <+94%2071%20428%209692>
> Blogs : https://medium.com/@lakwarus/
> http://lakmalsview.blogspot.com/
>
>
>


-- 
Thilini Shanika
Senior Software Engineer
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3

E-mail: tgtshan...@gmail.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Hasunie Adikari]

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[] buffer = new byte[1024];
int len;
while ((len = bufferedInputStream.read(buffer)) > -1 ) {
byteArrayOutputStream.write(buffer, 0, len);
}
byteArrayOutputStream.flush();


InputStream is1 = new
ByteArrayInputStream(byteArrayOutputStream.toByteArray());
InputStream is2 = new
ByteArrayInputStream(byteArrayOutputStream.toByteArray());

consume the clones for the validation and set another clone as a
buffereInputstream property in the axis2messagecontext.

BufferedInputStream bufferedInputStreamOriginal = new
BufferedInputStream(inputStreamOriginal);
axis2MC.setProperty(PassThroughConstants.BUFFERED_INPUT_STREAM,
bufferedInputStreamOriginal);

I'm still getting the stream closed issue only for correct the messages
which have been passed through multiple validators. If the validators throw
an exception, the request is getting build and generate the custom response
as expected. It seems like we implemented a way that gets the inputstream
from the passthrough pipe for the content unaware flows. Unless it uses to
get the inputstream from the messagecontext. It was proven once I attached
an empty content aware mediator and test the same flow. I was able to
observe the expected behaviour for the same implementation with the content
aware mediator.

Do we have a way to define cloned input stream as an original
inputstream in passthrough pipe?


Regards
Hasunie






On Wed, Jan 3, 2018 at 9:21 AM, Isuru Udana  wrote:

> Hi Dushan,
>
> On Wed, Jan 3, 2018 at 9:06 AM, Dushan Abeyruwan  wrote:
>
>> Hi Hasunie,
>>   Current PTT design would build the message whenever if there is content
>> aware mediator available. However IIRC, I did this *message.builder.the
>> invoked* thing to cope with the WSO2 ELB we had (a few years ago).
>>
> No. I think it was *force.passthrough.builder *property which you
> introduced for ELB requirement.
>
> To be honest, that looks ugly isn it (in terms of overall picture).
>> Basically, what it does; even if there are content-aware mediators, the
>> engine would forcefully ignore that (it was ELB requirement :) ) but for
>> APIM I don't think that would be the same, cos we may have to deal with
>> many use cases sometimes of cause with content aware flows with API
>> compositions etc etc.
>>
>> So, let's think what we can do here; regex and XML threat protectors
>> equally important if security is priority thus,  we would no longer able to
>> achieve the same core basic aspect (content none awareness) because, such
>> protections required you to walk through the nodes and verify some aspects
>> (basically, you need to expand the xml node tree to get result set) in that
>> way, it is required the message to be build. Anyway, what I would think the
>> best approach here is not to change complete synapse content awareness
>> logic rather I would think you may have mediator in place but only if such
>> protection engaged that may build the message to get XML inforset (rather
>> build through root, may be you can mark this meditor as content-aware
>> false, then build if message not already build prior to process)
>>
>> IMO, lets just not complicate the what we try to build around message
>> validation. I mean if we need such protection we may need to sacrify some
>> aspects am I?
>>
>> Cheers,
>> Dushan
>>
>> On Tue, Jan 2, 2018 at 8:08 AM, Vinod Kavinda  wrote:
>>
>>> Hi Hasunie,
>>>
>>> This is expected since the synapse engine now expecting an already built
>>> message. If I understood your requirement correctly, one option is to use a
>>> Builder Mediator before using any content aware mediator. Even though we do
>>> not recommend the Builder mediators now, still we can use it for your
>>> specific use case. Or you have to revert the *message.builder.invoked *
>>> property to *false *again*.*
>>>
>>> Regards,
>>> Vinod
>>>
>>> On Tue, Jan 2, 2018 at 5:22 PM, Hasunie Adikari 
>>> wrote:
>>>
 I'm trying to combine SQL injection(Regex) threat protector with the
 XML threat protector. So I created a sequence[1] with XMLthreatprotector
 mediator and regex mediator consecutively and uploaded it to be able to
 validate the request message through both the xml validator and regex
 validators. If I set the *message.builder.invoked *property to *TRUE *in 
 xml validator
 mediator to avoid sending the content in pass-through pipe(request
 message) as the response, Regex mediators is getting failed. The regex
 mediator was designed a way that the incoming messages are built in synapse
 level and eveluate the message content at the mediator level. It seems
 like we can't continue any mediators which are required to get the message
 content, after we manually set

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

[Pubudu Gunatilaka]

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 a feature that enables the users to get the
> Multi-Environment API Overview of APIs that they are managing across multi
> environments. Please refer the GitHub issue[1]. Appreciate any
> suggestions and comment on the Github issue about your suggestions.
>
> [1] https://github.com/wso2/product-apim/issues/2299
>
> Appreciate any suggestions.
> Thanks
>
> Best regards
> Renuka
> --
> *Renuka Fernando*
> Software Engineering Intern | WSO2 Inc
>
> Email : ren...@wso2.com
> Mobile : +94 76 667 8752 <+94%2076%20667%208752>
> Web : http://wso2.com
> 
>



-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Senior Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Hasanthi Purnima Dissanayake]

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 prevented to use the same JTI
even for the different SPs.

Thanks,
Hasanthi

On Sat, Jan 6, 2018 at 8:48 AM, Farasath Ahamed  wrote:

>
>
> On Friday, January 5, 2018, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Isura/Omindu,
>>
>> Which data are supposed to store in  IDN_JWT_PRIVATE_KEY table? What is
>>> the reason to store those data?
>>>
>>
>> In the patch that we have provided for 5.3.0 , this table contains
>> following fields.
>> JWT_ID (primary key)
>> EXP_TIME
>> TIME_CREATED
>>
>> JWT_ID is an unique identifier for the token. According to the spec this
>> token should not be reused. So JWT_ID is responsible for prevent re-use of
>> this token. Hence we need to store the JWT_ID. Based on the EXP_TIME we
>> have planned to clean the records. The spec is bit flexible on re-using
>> the token.  So once the token is expired we let the same JWT_ID to be
>> re-used.
>>
>
> 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?
>
>
>>
>>
>> jtiREQUIRED. JWT ID. A unique identifier for the token, which can be
>> used to prevent reuse of the token. These tokens MUST only be used once,
>> unless conditions for reuse were negotiated between the parties; any such
>> negotiation is beyond the scope of this specification.
>>
>>
>> If we are storing private keys in the table, make sure the content is
>>> encrypted to avoid security concerns.
>>
>>
>> Actually we don't store private keys here. Anyway the table name is bit
>> misleading. So shall we re-name the table as IDN_OIDC_JTI?
>>
>>
>> Thanks,
>>
>> On Fri, Jan 5, 2018 at 7:49 AM, Isura Karunaratne  wrote:
>>
>>> Hi Hasanthi,
>>>
>>> On Thu, Jan 4, 2018 at 4:32 PM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi All,

 Following tasks are identified for the implementation for the $subject.

 1. Move the logic of validating the token API invocation request to
 validate required parameters for JWT client authentication to
 PrivatekeyJWTClientAuthHandler
 2. Introduce a new interface to read the public certificate.
- Certificate can be read from keystore
- Certificate can be read from db
- Certificate can be read from any other means
 3. Data which will be persisted in IDN_JWT_PRIVATE_KEY can be grown
 rapidly which may cause to some performance issues. So need to implement a
 cleanup script based on the expiration time of the JWT.

>>>
>>> Which data are supposed to store in  IDN_JWT_PRIVATE_KEY table? What is
>>> the reason to store those data?
>>>
>>> Thanks
>>> Isura.
>>>
 4. Honour the UI configuration for confidential applications which is
 discussed in mail [1]

 Apart from above need to consider on following tasks:
 1. Improving the unit tests of the repository
 2. Improve the documentations for the $subject.


 [1] Confidential Aplications in OAuth2 Flow

 Thanks,
 --

 Hasanthi Dissanayake

 Senior Software Engineer | WSO2

 E: hasan...@wso2.com
 M :0718407133| http://wso2.com 

>>>
>>>
>>>
>>> --
>>>
>>> *Isura Dilhara Karunaratne*
>>> Associate Technical Lead | WSO2
>>> Email: is...@wso2.com
>>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>>> Blog : http://isurad.blogspot.com/
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Hasanthi Dissanayake
>>
>> Senior Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
>


-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture