Re: [Architecture] [APIM] Generating SDKs for APIs in API Manager Store

[Youcef HILEM]

Hi Viduranga,

Thank you very much for your response.
In this case, I have to wait for the issue to be fixed.
In the meantime, I will use maven or graddle for code generation.

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

Re: [Architecture] REST API for resending confirmation code in account recovery and self registration scenarios

[Indunil Upeksha Rathnayake]

Hi,

Thanks all for your valuable feedbacks, it will be helpful to improve this
in future.

In the design discussion (Refer [1]), it's concluded that to implement a
generic OSGI service for resending confirmation code in account recovery
scenarios and self registration and to consider other improvements in next
IS release. The OSGI service has been implemented with [2] and other
improvements will be tracking with [3].

[1] Mail thread : "Invitation: [Discussion] [Design] REST API for resending
confirmation... @ Tue Dec 5, 2017 1pm - 2pm (IST) (IAM team)"
[2] https://github.com/wso2-extensions/identity-governance/pull/197
[3] https://wso2.org/jira/browse/IDENTITY-7062

Thanks and Regards

On Tue, Dec 5, 2017 at 10:56 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> On Tue, Dec 5, 2017 at 9:03 AM, Johann Nallathamby 
> wrote:
>
>> Hi Indunil/Isura,
>>
>> I have a general comment on this. Are we not planning to support this in
>> the UI at least in the public release? Because planning for backend only
>> IMO is not a good idea from previous experience because it will remain at
>> the same state for years. Don't want to go back there. And from a
>> capabilities POV it won't be considered as OOTB capabilities of the
>> product, which makes it hard to sell :).
>>
>
> AFAIU, you have mentioned about providing UI support for resending
> confirmation emails?
> I think we should consider the UI validations in account recovery
> endpoint, when a previously issued confirmation link is used, as I have
> mentioned previously (ex: when someone use a previously issued confirmation
> link for reset password, user should redirect to an error page, without
> redirect to the password reset page). WDYT?
>
>
>>
>> On Tue, Dec 5, 2017 at 8:15 AM, Isura Karunaratne  wrote:
>>
>>> Hi Indunil,
>>>
>>>
>>>
>>> On Mon, Dec 4, 2017 at 8:24 PM, Indunil Upeksha Rathnayake <
>>> indu...@wso2.com> wrote:
>>>
 Hi,

 With IS 5.3.0, we have currently provided a Rest API for resending
 confirmation code (Refer [1]), which supports only for self signup feature.
 So that, we are planning to provide a more generic REST API and a OSGi
 service, for resending confirmation code for any scenario.



 Following are the scenarios, currently where we are sending
 confirmation emails in IS.

- *Password Reset* - password recovery using email-based
notifications
- *Account Confirmation* - email confirmation on user self
registration
- *Ask Password* - ask password from user through confirmation email
- *Admin Forced Password Reset*- admin to trigger a password reset
for a given user account
- *Admin Forced Password Reset With OTP* -  admin send an email to
the user with a one time password that the user can use to login once to
the account after which, the user will be prompted to set a new password
- *Email Confirmation *- account confirmation through email
notification


>>> IMO it is not required to have an option to resend the confirmation
>>> codes for following scenarios.
>>>
>>>
>>>- Password Reset
>>>- Admin Force Password Reset
>>>- Admin Force Password Reset with OTP
>>>
>>> There is no intermediate step between sending confirmation and
>>> validating confirmation in mentioned scenarios. So, instead of resending
>>> the code, users can start a new flow again. (Ex. Try another attempt to
>>> reset password )
>>> BTW, it is good to have a generic API to resend the confirmation codes.
>>>
>>
>> Yes. Please carefully consider the scenarios where "resending" is
>> absolutely necessary. Wherever we can "restart" the process we don't need
>> to "resend".
>>
>
> Yes. Planning to cover only the necessary scenarios from the above list.
>
>
>>
>> We can have two types of emails as far as I understand; emails with
>> confirmation codes for verification and emails with just text for
>> notification. Please consider these two kind of mails also when designing.
>> Are we planning to support "resend" for emails for just notifications? E.g.
>> user account disable?
>>
>
> I think it's not needed to resend emails with just text notifications. Or
> you are considering implementation of a generic API for notification
> sending in recovery scenarios rather than API for notification resending?
>
>
>>
>>>
>>>
>>>
>>>
 In there, the confirmation emails get expired after a configured time
 period in order to make the accounts secure. After the expiration, we may
 need to resend the confirmation emails.

 So with this implementation, when we request for resending confirmation
 code, previously issued code (even though, it's still not expired), should
 get expired and the new confirmation code should considered as active. So
 that in any scenario, if a user is requesting to use an expired
 confirmation code, we need to 

Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant

[Viduranga Gunarathne]

Hi Kishanthan.

The use cases for this are as follows:

i) In a scenario where both the back end and the API-M requests
authorization tokens.

If the back end already expects an authorization token by the name
"Authorization", then there will be a complication when sending two tokens
by the same name; one for the back end and he other for APIM. So the
authorization header name of APIM should be changed.

In this type of a scenario, both the API-M and the back end requires
authorization tokens and the header field would be "Authorization" for
both. This would make a confusion and also since API-M provides a
configuration to stop the authorization header from being sent to the back
end (RemoveOAuthheadersFromOutMessage) then if that config is set to true,
then the value that comes under the header field "Authorization" would not
get transferred to the back end.


ii) Existing client apps that communicate with a back end with
authorization tokens such as "TOKEN", "KEY".

When APIM is introduced to an existing system where client apps used to
communicate with the back end with their own authorization tokens such as
"TOKEN", "KEY" etc. , the client apps will have to be modified to send
"Authorization" instead. This can be avoided with customizing the
authorization header.


iii) In the APIM cloud, each tenant will be able to define their own
authorization header field.

Also this implementation, by default already supports the prevailing
"Authorization" header field. So, if a client doesn't do any
configurations, he/she can use the system without any issue as before. If a
client wants to configure custom header field ti support any scenario, he
will have to make the necessary configurations.

Thanks,
Viduranga.

On Tue, Dec 5, 2017 at 3:48 PM, Kishanthan Thangarajah 
wrote:

> The header name "Authorization" is what commonly used by all the
> clients/proxies. So we defining our own way for the "header name" is what
> my concern is. If we define such customized name, will the external clients
> adhere to that?
>
> The spec says that the common format used is Authorization =
>  [1]
>
> So shouldn't we use a customized way or scheme for the  part
> only, to identify tenant specific tokens (which is the requirement for
> $subject), but not change the header name itself?
>
> Some discussions related to this in SO -
> https://stackoverflow.com/questions/42574022/custom-authorization-header
> https://stackoverflow.com/questions/8463809/customize-
> the-authorization-http-header
>
> Thanks,
> [1] https://tools.ietf.org/html/rfc7235#section-4.2
>
> On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage  wrote:
>
>> "The OAuth 2.0 Authorization Framework: Bearer Token Usage" spec [1]
>> mentions 3 ways the token could be sent to the Resource Server - APIM
>> Gateway in this case:
>>
>>- Authorization Request Header Field
>>- Form-Encoded Body Parameter
>>- URI Query Parameter
>>
>> It doesn't seem to mandate that other header names couldn't be used.
>> Since we anyway use the recommended "Authorization" header by default, I
>> don't see a problem in this.
>>
>> [1] https://tools.ietf.org/html/rfc6750#page-4
>>
>> On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> Is this approach (custom authorization header field) allowed at OAuth2
>>> spec level? I mean, is this something we can customize/define and use it
>>> for our own, and also in accordance with the spec?
>>>
>>> Thanks,
>>>
>>> On Thu, Nov 30, 2017 at 10:57 AM, Viduranga Gunarathne <
>>> vidura...@wso2.com> wrote:
>>>
 Hi,

 @Prasanna,
 No we do not need to restart the server. Since this configuration is
 shipped with the tenant-conf.json, it will be automatically added to each
 of the created tenant configs in the registry, whenever a new tenant is
 created. Even for an existing tenant it can be added manually to the
 respective tenant config from the registry. A tenant only has to change the
 config in the registry to change the header name and save it back to
 registry. So when a new API is published, the custom header name will be
 read from the specific tenant config in the registry and added to the
 synapse config so that it will be deployed in the Gateway.

 @Chamalee,
 Yes, it will allow us to pass a custom header field instead of
 "Authorization" to the back end for authorization. And since this config is
 deployed in the gateway through the synapse config, once a request is
 received it can check for the specific header field for the authorization
 token.

 The use cases for this are as follows:

 i) In a scenario where both the back end and the API-M requests
 authorization tokens.
 If the back end already expects an authorization token by the name
 "Authorization", then there will be a complication when sending two tokens
 by the same name; one for the 

Re: [Architecture] [APIM] [C4] [2.1.0] API Gateways with Dedicated Back Ends

[Nuwan Dias]

Hi Akila,

The subject of the mail is not descriptive enough for the feature we're
trying to develop. What we're actually trying to achieve here is the
ability for an API to be moved across environments without having to change
the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe  wrote:

> Hi all,
>
> Sorry for the mistake. This is not the complete mail. The complete mail
> will be sent.
>
> Thanks,
>
> Akila Aroshana
> Software Engineer (Intern)
> WSO2
>
> Mobile : +94702178247 <+94%2070%20217%208247>
> Email : aki...@wso2.com
> LinkedIn : www.linkedin.com/in/akila-amarasinghe
> Web : http://wso2.com
>
> On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe  wrote:
>
>> Hi all,
>>
>> WSO2 API manager currently provides the facility for the user to input a
>> single endpoint to the API when designing it. So every time the API makes
>> requests, the request is directed to the back end defined by the endpoint
>> URL provided. Even if the API has multiple gateways, all the gateways
>> directs the requests to the same back end of the defined URL as the
>> following figure depicts.
>>
>>
>>
>> Problem :
>>
>> Assume a situation like this,
>>
>> Person A designs an API with the endpoint 
>> and works with it. Person B, which is in another region, <
>> https://backend-region-2:8280> with the same back end database needs
>> that API for some purpose. He deploys the API exported by Person A in the
>> gateway of his region and try to use. But the API will never connect with
>> the back end of his region. But in this situation, the API doesn't get
>> connected with the back end of region-2. As the endpoint which the Person A
>> entered is for region-1 back end only.
>>
>> If an already designed API needs to be connected with a back end(same
>> one) with a different endpoint(region) other than the already defined
>> endpoint in the API, the API won't be able to connect with it. Simply, a
>> designed API cannot be deployed in a region with a different back end
>> *URL *(not a different back end).
>>
>> Solution :
>>
>> The proposed solution is to enter a *dynamic endpoint* at the time the
>> API is designed. This endpoint should only be resolved at the run time so
>> the API so the gateway would point a dedicated back end. This also applies
>> when an API has more than one gateway.
>>
>>
>> ​
>>
>>
>>
>> ​
>>
>>
>>
>


-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C4] [2.1.0] API Gateways with Dedicated Back Ends

[Akila Amarasinghe]

Hi all,

Sorry for the mistake. This is not the complete mail. The complete mail
will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : +94702178247
Email : aki...@wso2.com
LinkedIn : www.linkedin.com/in/akila-amarasinghe
Web : http://wso2.com

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe  wrote:

> Hi all,
>
> WSO2 API manager currently provides the facility for the user to input a
> single endpoint to the API when designing it. So every time the API makes
> requests, the request is directed to the back end defined by the endpoint
> URL provided. Even if the API has multiple gateways, all the gateways
> directs the requests to the same back end of the defined URL as the
> following figure depicts.
>
>
>
> Problem :
>
> Assume a situation like this,
>
> Person A designs an API with the endpoint 
> and works with it. Person B, which is in another region, <
> https://backend-region-2:8280> with the same back end database needs that
> API for some purpose. He deploys the API exported by Person A in the
> gateway of his region and try to use. But the API will never connect with
> the back end of his region. But in this situation, the API doesn't get
> connected with the back end of region-2. As the endpoint which the Person A
> entered is for region-1 back end only.
>
> If an already designed API needs to be connected with a back end(same one)
> with a different endpoint(region) other than the already defined endpoint
> in the API, the API won't be able to connect with it. Simply, a designed
> API cannot be deployed in a region with a different back end *URL *(not a
> different back end).
>
> Solution :
>
> The proposed solution is to enter a *dynamic endpoint* at the time the
> API is designed. This endpoint should only be resolved at the run time so
> the API so the gateway would point a dedicated back end. This also applies
> when an API has more than one gateway.
>
>
> ​
>
>
>
> ​
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] [C4] [2.1.0] API Gateways with Dedicated Back Ends

[Akila Amarasinghe]

Hi all,

WSO2 API manager currently provides the facility for the user to input a
single endpoint to the API when designing it. So every time the API makes
requests, the request is directed to the back end defined by the endpoint
URL provided. Even if the API has multiple gateways, all the gateways
directs the requests to the same back end of the defined URL as the
following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint 
and works with it. Person B, which is in another region, <
https://backend-region-2:8280> with the same back end database needs that
API for some purpose. He deploys the API exported by Person A in the
gateway of his region and try to use. But the API will never connect with
the back end of his region. But in this situation, the API doesn't get
connected with the back end of region-2. As the endpoint which the Person A
entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one)
with a different endpoint(region) other than the already defined endpoint
in the API, the API won't be able to connect with it. Simply, a designed
API cannot be deployed in a region with a different back end *URL *(not a
different back end).

Solution :

The proposed solution is to enter a *dynamic endpoint* at the time the API
is designed. This endpoint should only be resolved at the run time so the
API so the gateway would point a dedicated back end. This also applies when
an API has more than one gateway.


​



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

[Architecture] Redis Connector

[Nirthika Rajendran]

Hi All,

I'm verifying the PR[1] for Redis connector with EI 6.1.1, which is already
developed for ESB 4.8.1.
There are nearly 82 methods with about 51 test cases. Test cases are
written for 53 methods.
>From 82 methods I found some issues in 22 methods. I'm correcting those
issues and writing test cases for other methods .
And also I'm planing to write documentation in GitHub.

Please find the methods details in the attached file

[1] https://github.com/wso2-attic/esb-connectors/pull/245

Regards,
*Nirthika Rajendran*
*Associate Software Engineer*
WSO2 Inc : http://wso2.org
Mobile   : +94 77 719 8368
LinkedIn: https://www.linkedin.com/in/nirthika/
Blog  :
*http://nirthika-tech-stuff.blogspot.com/
*


Redis Connector Operations - Sheet1.pdf
Description: Adobe PDF document
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture