Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Thanuja Jayasinghe]

Hi Farasath,

On Tue, Jun 21, 2016 at 2:57 AM, Farasath Ahamed  wrote:

> Hi Thanuja,
>
>
> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> We are planning to prevent this flow from brute force attacks by
>> enabling followings,
>>
>>1. Enable captcha/reCaptcha after n failed attempts
>>2. Lock the account after n failed attempts for a period of time
>>
>> How are we going to keep track of this "period of time" after an account
> is locked?
>

We calculate unlock time as current timestamp + locked time * 60 * 1000.
After that time, a user can try to reset the password, as in a normal flow.


>
>
>> *How to track failed attempts?*
>>
>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
>> which used in the login flow to track failed login attempts. Since this is
>> a different flow, using the same claim to track the failed password
>> reset attempts will lead to unintended situations. (Ex: After n number
>> of failed attempts in the login flow, a user may try to reset the password.
>> In this case, the user will see captcha if the number of failed attempts
>> reached to the maximum. But since this is the first time which the user
>> tries to reset the password, captcha is redundant.)
>>
>> So we will introduce a new claim call "
>> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
>> this.
>>
>>
>> *Implementation*
>>
>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>> connector will introduce to handle this. The configuration of the connector
>> UI will allow modifying connector according to the requirements.
>>
>> *Lock the account after n failed attempts for a period of time *-
>> Account lock will handle from the identity recovery rest API logic. Also 
>> "PRE_SET_USER_CLAIMS"
>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>> in case of account lock.
>>
>> Appreciate your input.
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
> Thanks,
> Farasath.
>



-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Caching Support for Analytics Event Tables

[Anjana Fernando]

Hi,

Not sure, if it'll be easy to merge the code like that, specially
considering the two implementations are very different from the code level,
as in, the points used to cache the data would be a bit different. In
future, a better option would be to cache the data from CEP itself, rather
than from individual event table implementation. Anyways, let's check the
two implementations and see, at least from the configuration level.

Cheers,
Anjana.

On Mon, Jun 20, 2016 at 8:36 PM, Mohanadarshan Vivekanandalingam <
mo...@wso2.com> wrote:

>
>
> On Mon, Jun 20, 2016 at 8:17 PM, Sriskandarajah Suhothayan 
> wrote:
>
>> Is this in line with the RDBMS implementation? Else it will be confusing
>> to the users.
>> Shall we have a chat and merge the caching code?
>>
>
> Yes, let's have a chat..
>
>>
>> @Mohan can you work with Anjana
>>
>
> sure...
>
>
>>
>> Regards
>> Suho
>>
>> On Mon, Jun 20, 2016 at 12:49 PM, Anjana Fernando 
>> wrote:
>>
>>> Hi,
>>>
>>> With a chat we had with Srinath, we've decided to set the default cache
>>> timeout to 10 seconds, so from this moment, it is set to 10 seconds by
>>> default in the code.
>>>
>>> Cheers,
>>> Anjana.
>>>
>>> On Wed, Jun 15, 2016 at 1:57 PM, Nirmal Fernando 
>>> wrote:
>>>
 Great! Thanks Anjana!

 On Wed, Jun 15, 2016 at 11:26 AM, Anjana Fernando 
 wrote:

> Hi,
>
> We've added the $subject. Basically, a local cache is now maintained
> in each event table, where it will store the most recently used data items
> in the cache, up to a certain given cache size, for a maximum given
> lifetime. The format is as follows:-
>
>  @from(eventtable = 'analytics.table' , table.name = 'name', *caching*
> = 'true', *cache.timeout.seconds* = '10', *cache.size.bytes* =
> '10')
>
> The cache.timeout.seconds and cache.size.bytes values are optional,
> with default values of 60 (1 minute) and 1024 * 1024 * 10 (10 MB)
> respectively.
>
> Also, there are some debug logs available in the component, if you
> want to check for explicit cache hit/miss situations and record lookup
> timing, basically enable debug logs for the class
> "org.wso2.carbon.analytics.eventtable.AnalyticsEventTable".
>
> So basically, if you use analytics event tables in performance
> sensitive areas in your CEP execution plans, do consider using caching if
> it is possible to do so.
>
> The unit tests are updated with caching, and the updated docs can be
> found here [1].
>
> [1]
> https://docs.wso2.com/display/DAS310/Understanding+Event+Streams+and+Event+Tables#UnderstandingEventStreamsandEventTables-AnalyticseventtableAnalyticseventtable
>
> Cheers,
> Anjana.
> --
> *Anjana Fernando*
> Senior Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



 --

 Thanks & regards,
 Nirmal

 Team Lead - WSO2 Machine Learner
 Associate Technical Lead - Data Technologies Team, WSO2 Inc.
 Mobile: +94715779733
 Blog: http://nirmalfdo.blogspot.com/



>>>
>>>
>>> --
>>> *Anjana Fernando*
>>> Senior Technical Lead
>>> WSO2 Inc. | http://wso2.com
>>> lean . enterprise . middleware
>>>
>>
>>
>>
>> --
>>
>> *S. Suhothayan*
>> Technical Lead & Team Lead of WSO2 Complex Event Processor
>> *WSO2 Inc. *http://wso2.com
>> * *
>> lean . enterprise . middleware
>>
>>
>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>> http://suhothayan.blogspot.com/ twitter:
>> http://twitter.com/suhothayan  | linked-in:
>> http://lk.linkedin.com/in/suhothayan *
>>
>
>
>
> --
> *V. Mohanadarshan*
> *Associate Tech Lead,*
> *Data Technologies Team,*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
> email: mo...@wso2.com
> phone:(+94) 771117673
>



-- 
*Anjana Fernando*
Senior Technical Lead
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Prabath Siriwardana]

This thread is also related to [Architecture][Dev][IS] Improvements in
handling incorrect login attempts [1].

[1]:
http://wso2-oxygen-tank.10903.n7.nabble.com/Dev-IS-Improvements-in-handling-incorrect-login-attempts-td138672.html

Thanks & regards,
-Prabath

On Mon, Jun 20, 2016 at 1:05 AM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>
> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] Multiple Attribute Profiles Support for IS

[Prabath Siriwardana]

[-strategy@  +architecture@]

Hi Johann,

This captures the high-level overview and looks fine - let me add little
more to clarify few areas, as per the discussion we had a few weeks back on
the $subject...

1. A claim has an identifier.The identifier is unique within a group of
claims - or a claim dialect.

2. A claim does not exist by itself - any given claim will belong to a
claim dialect. We would need to have a root dialect. A claim dialect itself
has an identifier.

3. You define a claim - within a claim dialect. The claim definition
carries following attributes:

- mapped attribute id (s) by multiple attribute providers.
- a reference to a policy, which defines who can read/write to the claim -
under, which criteria the claim is released.
- criteria to validate the value written to the claim.
- the type of the claim (String, Integer, Boolean).
- support multi-values of not.

4. Apart from the root dialect, the system can have standard dialects and
custom dialects.

5. There is no semantic difference between a standard dialect and a custom
dialect. Standard dialects are, OpenID, InfoCard, SCIM.

6. Like the root dialect, a custom dialect is also a collection of claim
definitions. And each of these claim definitions can just refer to the root
claim dialect - and also override 'some' of its attributes.

7. Claim dialects are just definitions - do not define their usage. The
usage of claim dialects is defined in claim profiles (take SAML profile as
an analogy).

8. There are multiple usages of claims. Some of them are listed below:

- during SSO share users claims in the SSO response.
- during federated SSO - request claims from the external identity provider.
- during inbound provisioning
- during outbound provisioning
- during just-in-time provisioning
- during user sign up.

9. Each usage above is a claim-profile.

10. There can be a root claim-profile for each of the above scenarios and
any custom claim profile can extend from them.

11. Based on the type of the profile, claim-profile adds additional
attributes to it. For example, the signup profile will have following
metadata:

- a reference to the claim dialect (which is the root claim dialect)
- define required claims for the user sign up.
- define optional claims for the user sign up.
- define which claims should be verified (for example, email address, phone
number).
- override criteria to validate the values written to the claim.
- default value by claims for optional claims.
- display order of claims
- relationships between claims as expressions. For example fullName =
firstName.concat(' ' + lastName) or emailAddress = firstName.concat('@
wso2.com').

12. Another example, the JIT provisioning profile will have following
metadata:

- a reference to the parent profile (which is the root signup profile)
- override any values - for example, make some optional attributes required
- and remove the requirement for verification (because we assume these are
already verified by the identity provider).

13. There can be saved claim-profiles and dynamic claim profiles. The above
two examples are for saved claim profiles. A good example for a dynamic
claim profile is the definition of the required attributes for a service
provider. You can just select a claim dialect and pick what is required and
what is not.

14. Now let's see how the above concept relates to user attributes. A user
can have multiple named attribute profiles - and pick attributes from which
profile he/she likes to share with the service provider at the time of
login. This does not directly relate to the claim profile concept we
discussed before.

15. When we support for multiple attribute providers (or stores) - a given
user's attributes can come from different attribute stores. At the moment
we assume user attributes are coming only from the user store, the user
belongs to. How to find the attribute stores for a given user is
out-of-the-scope of this discussion. Once you find the corresponding user
store, the claim definitions, will help you to find the mapping
attributed ids corresponding to that attribute stores.

Thanks & regards,
-Prabath

On Sun, Jun 19, 2016 at 8:49 AM, Johann Nallathamby  wrote:

> The user attribute profile management story in IS is weak and not able to
> cater to requirements from various use cases and protocols. Multiple
> attribute profiles support is also limited to JDBC user stores. At a very
> high level I think we need the following design changes to this feature.
>
> Definition:
> *A attribute profile is a collection of claim URIs.*
>
> 1. Attribute profile should not have anything to do with the attribute
> mapping with the underlying user store. Creation of a attribute profile
> would mean aggregating a set of claim URIs.
>
> 2. Some of the metadata we currently define against claims are in fact
> metadata of a attribute profile.
> E.g.
> Display Order - when showing a input form to fill the profile values the
> order in which the claims are displayed

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Farasath Ahamed]

Hi Thanuja,


On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
> How are we going to keep track of this "period of time" after an account
is locked?


> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>
> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Thanks,
Farasath.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev][IS] Improvements in handling incorrect login attempts

[Prabath Siriwardana]

I guess we discussed some of the options in a different thread too...

Here are few things we should do to mitigate brute force attacks...

1. Lock the account after n number of failed login attempts - only the
identity admin (or helpdesk admin) can unlock the account.
2. Lock the account after n number of failed login attempts - and
automatically unlock the account after t minutes.
3. Lock the account after n number of failed login attempts - and unlock
the account only when the account own clicks on a link sent to his
registered email address.
4. Do not lock the account - after n number of failed login attempts
display a captcha
5. Do not lock the account - incrementally increase the response time of
the failed login responses

In all these scenarios - we need to track all the data associated with the
login request - and build an IP blacklist.

Can we represent all the above scenarios as policies? Ideally, we should be
able to engage these policies to users by the tenant, role or group, user
store or globally...

Thanks & regards,
-Prabath


On Thu, Jun 16, 2016 at 12:23 PM, Harsha Thirimanna 
wrote:

> Hi All,
>
> Currently We are working on $subject.
>
> When user tries to login using invalid credential until reach the maximum
> attempts count, we lock the account for some specific time. After the time,
> we allow to user to try again and  it will be locked again after user tries
> to login using invalid credential for the maximum attempts. Now we are
> going to increase the lock time than the previous time. This ratio would be
> a configurable value.
>
> As an another improvement when a registered user tries to login to the
> system without email confirmation, inform him verification is pending and
> give the ability to resend the confirmation code to the registered email
> address.
>
> Your comments and suggestions are highly appreciated.
>
> thanks
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * *
> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ *
> *harshathirimannlinked-in: **http:
> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> *
>
> *Lean . Enterprise . Middleware*
>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] [DAS] Overhauling the Spark JDBC Connector

[Dulitha Wijewantha]

Hi Niranda,
INSERT INTO syntax is available but I can't insert arbitrary values without
using a select. This is for testing purposes.

Cheers~

On Fri, Jun 17, 2016 at 2:03 AM, Niranda Perera  wrote:

> Hi Dulitha,
>
> This is a new connector only. It does not affect Spark SQL queries (apart
> from the options you specify in the CREATE TEMPORARY TABLE queries). INSERT
> INTO was available in the previous CarbonJDBC connector as well.
>
> Best
>
> On Fri, Jun 17, 2016 at 12:47 AM, Dulitha Wijewantha 
> wrote:
>
>> Hi Gokul,
>> Will this allow us to perform INSERT INTO queries with sample data (not
>> from a table)? This is useful in the DEV phase.
>>
>> Cheers~
>>
>> On Tue, Jun 14, 2016 at 7:38 AM, Gokul Balakrishnan 
>> wrote:
>>
>>> Hi product analytics leads,
>>>
>>> Please make sure that the configuration file spark-jdbc-config.xml is
>>> added to the product-analytics packs, especially is you're using the
>>> CarbonJDBC provider. Example commit may be found at [1].
>>>
>>> [1]
>>> https://github.com/wso2/product-das/commit/4bdbf68833bd2bc8a20549eaf726873cacde468f
>>>
>>> Thanks,
>>>
>>> On 13 June 2016 at 17:37, Gokul Balakrishnan  wrote:
>>>
 Hi Anjana, Nirmal,

 The schema being mandatory is an architectural decision we've had to
 take. If I go into a bit more detail as to the reasons, Spark requires its
 own catalyst schema to be constructed when a relation is being created. In
 the previous implementation, this was achieved through dropping the target
 RDBMS table and recreating it in a format Spark understands. However, in
 the current implementation, we have removed the need for and DML operation
 during table creation, unless specifically requested.

 The issue with making this parameter optional is that we will have to
 again fall back to the earlier behaviour of the schema being inferred from
 the table metadata, if not specified. This will mean having to maintain a
 list of reverse mappings which will pollute the implementation. Moreover,
 we will have inconsistencies when certain table schemata are inferred while
 others are specified.

 Please note that this is not an API change nor is it a change in
 deployable artefacts: the user merely has to do edit his/her DAS extensions
 (i.e. Spark scripts) if applicable. We will clearly point out the changes
 that need be done, in the DAS 3.1.0 migration guide.

 Thanks,

 On 13 June 2016 at 16:44, Anjana Fernando  wrote:

> Hi,
>
> On Mon, Jun 13, 2016 at 12:23 PM, Nirmal Fernando 
> wrote:
>
>>
>> The "schema" option is required, and is used to specify the schema to
>>> be utilised throughout the temporary table's lifetime. Here, the field
>>> types used for the schema match what we have for the CarbonAnalytics
>>> provider (i.e. not JDBC nor databridge), and correspond to Spark 
>>> catalyst
>>> types. Moreover, the optional "-i" keyword for a field if specified will
>>> create an RDBMS index for that field.
>>>
>>
>> Can't we make 'schema' optional as it was earlier? This introduces a
>> backward incompatible change otherwise.
>>
>
> The schema was optional before, because earlier it mandated the user
> to create the table beforehand, which was not desirable, where for
> subsequent "insert override" statements, they drop the table and tried to
> re-create it, and didn't do a good job in doing so. So this approach was
> done to make it more consistent in the way we create the tables. And in 
> the
> new implementation, we need the schema to be known beforehand to know 
> about
> its primary keys etc.. to do the operations properly. But yeah, for the
> sake of backward compatibility, we can do somewhat of a best effort
> implementation by, looking up the table schema using JDBC and trying to
> figure out the table schema, mainly the primary keys, which is the 
> critical
> information we need. But this is not always a definite thing we can expect
> from JDBC, where some DBMSs may not expose this properly through that. So
> anyway, it is highly recommended to move into the new approach when you're
> using CarbonJDBC. But we will try to do a best effort implementation to
> retain backward compatibility, @Gokul, please check on this.
>
> Cheers,
> Anjana.
>
>
>>
>>> The "primaryKeys" option is not mandatory, and may be used to denote
>>> unique key fields in the underlying RDBMS table. It is based on this 
>>> option
>>> that INSERT or UPSERT queries will be chosen when doing Spark INSERT 
>>> INTO
>>> queries, as explained above.
>>>
>>> We're in the process of documenting the usage patterns of this
>>> provider so that they can be better understood.
>>>
>>> Thanks,
>>>
>>> On 10 June 2016 at 15:16, Inosh Goonewardena  wrote:

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Malithi Edirisinghe]

Hi Thanuja,


On Mon, Jun 20, 2016 at 7:55 PM, Thanuja Jayasinghe 
wrote:

> Hi Darshana,
>
> On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
> wrote:
>
>> Hi Thanuja,
>>
>> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> We are planning to prevent this flow from brute force attacks by
>>> enabling followings,
>>>
>>>1. Enable captcha/reCaptcha after n failed attempts
>>>2. Lock the account after n failed attempts for a period of time
>>>
>>>
>>> *How to track failed attempts?*
>>>
>>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; 
>>> claim
>>> which used in the login flow to track failed login attempts. Since this is
>>> a different flow, using the same claim to track the failed password
>>> reset attempts will lead to unintended situations. (Ex: After n number
>>> of failed attempts in the login flow, a user may try to reset the password.
>>> In this case, the user will see captcha if the number of failed attempts
>>> reached to the maximum. But since this is the first time which the user
>>> tries to reset the password, captcha is redundant.)
>>>
>>> So we will introduce a new claim call "
>>> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
>>> this.
>>>
>>>
>>> *Implementation*
>>>
>>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>>> connector will introduce to handle this. The configuration of the connector
>>> UI will allow modifying connector according to the requirements.
>>>
>>
>> I assume this new connector will be much similar to "
>> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
>> depending on the "failedLoginAttempts" claim, the new connector will
>> depends on new "failedPasswordResetAttempts" claim.
>>
>
> Yes. They will share a similar design.
>
>
>>
>> *Lock the account after n failed attempts for a period of time *-
>>> Account lock will handle from the identity recovery rest API logic. Also 
>>> "PRE_SET_USER_CLAIMS"
>>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>>> in case of account lock.
>>>
>>
>> Are you referring locking the password recovery flow? What would be the
>> impact of locking the "password recovery flow" to the "login flow"?
>>
>
> Account lock from any flow (either from "password recovery flow" to the
> "login flow") will consider as an account locked situation for the user.
>

Suppose both flows ('login flow' discussed at [3] and the 'password
recovery flow'), will be sharing the same configurations with regard to
locking the account of the user and behaving similarly.


>
>
>
>>
>> Going through supported password recovery flows listed in [2],
>> > Recover with Notification : Has less risk on brute force attacks
>>
> > Recover with Secret Questions (one question at a time) : Has moderate
>> risk on brute force attacks
>> > Recover with Secret Questions (multiple questions at a time) : Has
>> higher risk on brute force attacks
>>
>
>> Considering above, it's better to have this feature enabled by default if
>> the password recovery is enabled.
>>
>
> +1 . We planning to apply these security enhancements only to 'Recover
> with Secret Questions' flows due the less risk in 'Recover with
> Notification' flow.
>
>
>> [1] "[Architecture][IS] Support for Google reCaptha"
>> [2] "Identity Management Recovery API improvements"
>>
>> Thanks,
>> Darshana
>>
>>>
>>> Appreciate your input.
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
[3] '[Architecture] [Dev][IS] Improvements in handling incorrect login
attempts'

Thanks,
Malithi.

-- 

*Malithi Edirisinghe*
Associate Technical Lead
WSO2 Inc.

Mobile : +94 (0) 718176807
malit...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Initial Implementation of content-aware support in Carbon-Gateway

[Nandika Jayawardana]

Even though we should avoid axis2, I think axiom is fine to be used. Since
XML and SOAP  are matured technologies, we do not need frequent releases. I
do not see a reason why we cannot maintain axiom upto date with java 8, 9
 and continue to use it since axiom is one of the most comprehensive
libraries when it comes to processing SOAP.

Regards
Nandika

On Mon, Jun 20, 2016 at 12:20 PM, Isuru Ranawaka  wrote:

>
>
> On Mon, Jun 20, 2016 at 10:35 AM, Afkham Azeez  wrote:
>
>> I don't think we should use Axiom. It probably will be put into the attic
>> in the near future. It is not actively maintained. In the rest of the new
>> C5 based platform, we have avoided using Axiom/Axis2. Not a good choice for
>> something we are building for the future.
>>
>
> Yeah.. That's the problem with Axiom.But we did not find a better
> alternative yet.we are looking for  a better one.
>
>
>>
>> On Fri, Jun 17, 2016 at 10:09 AM, Isuru Ranawaka  wrote:
>>
>>> Hi Nandika,
>>>
>>> yes .we choose Axiom has default soap processing library because it
>>> supports  differed building and uses StAx API for processing XML events
>>> and  XPath support . Seems it is matured library for handling SOAP .
>>>
>>> On Fri, Jun 17, 2016 at 9:59 AM, Nandika Jayawardana 
>>> wrote:
>>>
 Hi Isuru,

 So the XML processing library will be Axiom right.  +1 for axiom since
 its very comprehensive when it comes to soap processing.

 Regards
 NAndika

 On Fri, Jun 17, 2016 at 9:55 AM, Isuru Ranawaka 
 wrote:

> Hi Jochen,
>
> Your suggestion is very interesting and thanks for providing  a
> valuable idea. Actually we are in the process of  designing error handling
> in CGW and need to think about error handling strategies like,   Per
> exception based error handling, Mediation level error handling , Pipeline
> level error handling ,  Global level error handling etc .. and how to fit
> them with Next GEN ESB Language and runtime.
>
> Thanks
> Isuru
>
> On Thu, Jun 16, 2016 at 1:18 AM, Jochen Traunecker <
> jochen.traunec...@googlemail.com> wrote:
>
>> Hi Isuru,
>>
>> have you considered some kind of robust "Fallback-Reader" capable of
>> reading whatever comes in as binary raw data? It might be very handy in
>> error handling like illegal characters in XML payloads, wrong encoding of
>> payloads, malformed payloads and so on.
>>
>> A typical scenario is like this: a illegal payload ends up in some
>> fault-handler ( e.g. XML parser throws an exception). Fault-Handling 
>> should
>> be able to process the illegal payload like encoding it as Base64 
>> compliant
>> text and write it to the log-file and so on. By that Fault-Handling 
>> should
>> be able to access the payload as binary data stream through
>> "Fallback-Reader". Ideally "Fallback-Reader" provides convenience
>> functionality like base64 encoding, compressing, ...
>>
>> Regards,
>> Jochen
>> --
>> Jochen Traunecker
>> https://www.linkedin.com/in/jochen-traunecker
>>
>>
>>
>>
>> Isuru Ranawaka  schrieb am Di., 14. Juni 2016 um
>> 19:27 Uhr:
>>
>>> Hi all,
>>>
>>>
>>> We have identified three scenarios when considering content aware
>>> support in Next Gen ESB . These can be categorized as  a pure pass thru
>>> scenario where payload is  not touched , reading the  content without
>>> modifying  scenario and reading and modifying the content. So we came 
>>> up of
>>> initial design  and implementation of the content reading part. We have
>>> come up with  different message readers for different content types .  
>>> For
>>> example,  for the XML message  XMLReader is used and for the JSON 
>>> Messages
>>> JSONReader is used. Message readers are pluggable via OSGI service.
>>>
>>> [image: reader_implementation.png]
>>>
>>>
>>> Reader Registration
>>>
>>>-
>>>
>>>Gateway core consists of in memory registry which keeps
>>>registered MessageReaders according to content type.
>>>-
>>>
>>>Message readers are registered via OSGI  services.
>>>-
>>>
>>>JSON message reader and XML message reader are implemented as
>>>two different OSGI bundles.
>>>-
>>>
>>>CarbonMessage is supported with reading content as InputStream
>>>and write content via OutputStream.
>>>
>>>
>>> Message Flow
>>>
>>>-
>>>
>>>Need to specify the portion of the message that needs to be
>>>read via XPath or JSONPath according to  the  content type.
>>>-
>>>
>>> When message hits the content aware mediator it checks weather
>>>message is already read if so then it takes MessageDataSource which 
>>> is data
>>>holder for already read message inputstrea

[Architecture] WSO2 App Manager 1.2.0-Beta Released!

[Lahiru Cooray]

*WSO2 App Manager 1.2.0-Beta Released!*


WSO2 App Manager team is pleased to announce WSO2 App Manager 1.2.0-BETA
release. Download distribution here
.
This release comes with following new features, improvements and bug fixes.

New Features
[APPM-1442]  - New asset type -
Sites.
[APPM-1443]  - Configurable
subscription options for Web App and Sites asset types.
[APPM-1444]  - Multiple version
support for Web App and Sites  asset types.
[APPM-1446]  - Java APIs for all
key App Manager functionalities that need to be integrated with device
management functionalities.
[APPM-1445]  - Role based
visibility control for mobile apps
[APPM-1441]  - Redesign product
REST APIs with JAX-RS implementation and secure with OAuth
[APPM-1447]  - Business Owner
concept implementation
[APPM-1493]  - Supporting custom
fields to be added in publisher UI and new REST APIs
[APPM-1492]  - One time download
link support for mobile apps
Improvements
[APPM-1437]  - Navigation
improvement to Store
[APPM-1440]  - New theme for store
UI
Tasks
[APPM-1438]  - Responsive store UI
by Boostrap3 upgrade
[APPM-1439]  - Kernal version
upgrade to 4.4.5


Bug Fixes
WSO2 App Manager 1.2.0-beta resolved issues





Reporting Problems
Issues can be reported through public JIRA
 project assigned to WSO2 AppM.


Thanks,
App Manager team

-- 
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware

Mobile: +94 715 654154
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Caching Support for Analytics Event Tables

[Mohanadarshan Vivekanandalingam]

On Mon, Jun 20, 2016 at 8:17 PM, Sriskandarajah Suhothayan 
wrote:

> Is this in line with the RDBMS implementation? Else it will be confusing
> to the users.
> Shall we have a chat and merge the caching code?
>

Yes, let's have a chat..

>
> @Mohan can you work with Anjana
>

sure...


>
> Regards
> Suho
>
> On Mon, Jun 20, 2016 at 12:49 PM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> With a chat we had with Srinath, we've decided to set the default cache
>> timeout to 10 seconds, so from this moment, it is set to 10 seconds by
>> default in the code.
>>
>> Cheers,
>> Anjana.
>>
>> On Wed, Jun 15, 2016 at 1:57 PM, Nirmal Fernando  wrote:
>>
>>> Great! Thanks Anjana!
>>>
>>> On Wed, Jun 15, 2016 at 11:26 AM, Anjana Fernando 
>>> wrote:
>>>
 Hi,

 We've added the $subject. Basically, a local cache is now maintained in
 each event table, where it will store the most recently used data items in
 the cache, up to a certain given cache size, for a maximum given lifetime.
 The format is as follows:-

  @from(eventtable = 'analytics.table' , table.name = 'name', *caching*
 = 'true', *cache.timeout.seconds* = '10', *cache.size.bytes* =
 '10')

 The cache.timeout.seconds and cache.size.bytes values are optional,
 with default values of 60 (1 minute) and 1024 * 1024 * 10 (10 MB)
 respectively.

 Also, there are some debug logs available in the component, if you want
 to check for explicit cache hit/miss situations and record lookup timing,
 basically enable debug logs for the class
 "org.wso2.carbon.analytics.eventtable.AnalyticsEventTable".

 So basically, if you use analytics event tables in performance
 sensitive areas in your CEP execution plans, do consider using caching if
 it is possible to do so.

 The unit tests are updated with caching, and the updated docs can be
 found here [1].

 [1]
 https://docs.wso2.com/display/DAS310/Understanding+Event+Streams+and+Event+Tables#UnderstandingEventStreamsandEventTables-AnalyticseventtableAnalyticseventtable

 Cheers,
 Anjana.
 --
 *Anjana Fernando*
 Senior Technical Lead
 WSO2 Inc. | http://wso2.com
 lean . enterprise . middleware

>>>
>>>
>>>
>>> --
>>>
>>> Thanks & regards,
>>> Nirmal
>>>
>>> Team Lead - WSO2 Machine Learner
>>> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
>>> Mobile: +94715779733
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>>
>>>
>>
>>
>> --
>> *Anjana Fernando*
>> Senior Technical Lead
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>
>
>
> --
>
> *S. Suhothayan*
> Technical Lead & Team Lead of WSO2 Complex Event Processor
> *WSO2 Inc. *http://wso2.com
> * *
> lean . enterprise . middleware
>
>
> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
> http://suhothayan.blogspot.com/ twitter:
> http://twitter.com/suhothayan  | linked-in:
> http://lk.linkedin.com/in/suhothayan *
>



-- 
*V. Mohanadarshan*
*Associate Tech Lead,*
*Data Technologies Team,*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*

email: mo...@wso2.com
phone:(+94) 771117673
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Caching Support for Analytics Event Tables

[Sriskandarajah Suhothayan]

Is this in line with the RDBMS implementation? Else it will be confusing to
the users.
Shall we have a chat and merge the caching code?

@Mohan can you work with Anjana

Regards
Suho

On Mon, Jun 20, 2016 at 12:49 PM, Anjana Fernando  wrote:

> Hi,
>
> With a chat we had with Srinath, we've decided to set the default cache
> timeout to 10 seconds, so from this moment, it is set to 10 seconds by
> default in the code.
>
> Cheers,
> Anjana.
>
> On Wed, Jun 15, 2016 at 1:57 PM, Nirmal Fernando  wrote:
>
>> Great! Thanks Anjana!
>>
>> On Wed, Jun 15, 2016 at 11:26 AM, Anjana Fernando 
>> wrote:
>>
>>> Hi,
>>>
>>> We've added the $subject. Basically, a local cache is now maintained in
>>> each event table, where it will store the most recently used data items in
>>> the cache, up to a certain given cache size, for a maximum given lifetime.
>>> The format is as follows:-
>>>
>>>  @from(eventtable = 'analytics.table' , table.name = 'name', *caching*
>>> = 'true', *cache.timeout.seconds* = '10', *cache.size.bytes* = '10')
>>>
>>> The cache.timeout.seconds and cache.size.bytes values are optional, with
>>> default values of 60 (1 minute) and 1024 * 1024 * 10 (10 MB) respectively.
>>>
>>> Also, there are some debug logs available in the component, if you want
>>> to check for explicit cache hit/miss situations and record lookup timing,
>>> basically enable debug logs for the class
>>> "org.wso2.carbon.analytics.eventtable.AnalyticsEventTable".
>>>
>>> So basically, if you use analytics event tables in performance sensitive
>>> areas in your CEP execution plans, do consider using caching if it is
>>> possible to do so.
>>>
>>> The unit tests are updated with caching, and the updated docs can be
>>> found here [1].
>>>
>>> [1]
>>> https://docs.wso2.com/display/DAS310/Understanding+Event+Streams+and+Event+Tables#UnderstandingEventStreamsandEventTables-AnalyticseventtableAnalyticseventtable
>>>
>>> Cheers,
>>> Anjana.
>>> --
>>> *Anjana Fernando*
>>> Senior Technical Lead
>>> WSO2 Inc. | http://wso2.com
>>> lean . enterprise . middleware
>>>
>>
>>
>>
>> --
>>
>> Thanks & regards,
>> Nirmal
>>
>> Team Lead - WSO2 Machine Learner
>> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
>> Mobile: +94715779733
>> Blog: http://nirmalfdo.blogspot.com/
>>
>>
>>
>
>
> --
> *Anjana Fernando*
> Senior Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Thanuja Jayasinghe]

On Mon, Jun 20, 2016 at 7:55 PM, Thanuja Jayasinghe 
wrote:

> Hi Darshana,
>
> On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
> wrote:
>
>> Hi Thanuja,
>>
>> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> We are planning to prevent this flow from brute force attacks by
>>> enabling followings,
>>>
>>>1. Enable captcha/reCaptcha after n failed attempts
>>>2. Lock the account after n failed attempts for a period of time
>>>
>>>
>>> *How to track failed attempts?*
>>>
>>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; 
>>> claim
>>> which used in the login flow to track failed login attempts. Since this is
>>> a different flow, using the same claim to track the failed password
>>> reset attempts will lead to unintended situations. (Ex: After n number
>>> of failed attempts in the login flow, a user may try to reset the password.
>>> In this case, the user will see captcha if the number of failed attempts
>>> reached to the maximum. But since this is the first time which the user
>>> tries to reset the password, captcha is redundant.)
>>>
>>> So we will introduce a new claim call "
>>> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
>>> this.
>>>
>>>
>>> *Implementation*
>>>
>>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>>> connector will introduce to handle this. The configuration of the connector
>>> UI will allow modifying connector according to the requirements.
>>>
>>
>> I assume this new connector will be much similar to "
>> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
>> depending on the "failedLoginAttempts" claim, the new connector will
>> depends on new "failedPasswordResetAttempts" claim.
>>
>
> Yes. They will share a similar design.
>
>
>>
>> *Lock the account after n failed attempts for a period of time *-
>>> Account lock will handle from the identity recovery rest API logic. Also 
>>> "PRE_SET_USER_CLAIMS"
>>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>>> in case of account lock.
>>>
>>
>> Are you referring locking the password recovery flow? What would be the
>> impact of locking the "password recovery flow" to the "login flow"?
>>
>
> Account lock from any flow (either password recovery flow or login flow)
> will consider as an account locked situation for the user.
>
>
>>
>> Going through supported password recovery flows listed in [2],
>> > Recover with Notification : Has less risk on brute force attacks
>>
> > Recover with Secret Questions (one question at a time) : Has moderate
>> risk on brute force attacks
>> > Recover with Secret Questions (multiple questions at a time) : Has
>> higher risk on brute force attacks
>>
>
>> Considering above, it's better to have this feature enabled by default if
>> the password recovery is enabled.
>>
>
> +1 . We planning to apply these security enhancements only to 'Recover
> with Secret Questions' flows due the less risk in 'Recover with
> Notification' flow.
>
>
>> [1] "[Architecture][IS] Support for Google reCaptha"
>> [2] "Identity Management Recovery API improvements"
>>
>> Thanks,
>> Darshana
>>
>>>
>>> Appreciate your input.
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>



-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Thanuja Jayasinghe]

Hi Darshana,

On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
wrote:

> Hi Thanuja,
>
> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> We are planning to prevent this flow from brute force attacks by
>> enabling followings,
>>
>>1. Enable captcha/reCaptcha after n failed attempts
>>2. Lock the account after n failed attempts for a period of time
>>
>>
>> *How to track failed attempts?*
>>
>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
>> which used in the login flow to track failed login attempts. Since this is
>> a different flow, using the same claim to track the failed password
>> reset attempts will lead to unintended situations. (Ex: After n number
>> of failed attempts in the login flow, a user may try to reset the password.
>> In this case, the user will see captcha if the number of failed attempts
>> reached to the maximum. But since this is the first time which the user
>> tries to reset the password, captcha is redundant.)
>>
>> So we will introduce a new claim call "
>> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
>> this.
>>
>>
>> *Implementation*
>>
>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>> connector will introduce to handle this. The configuration of the connector
>> UI will allow modifying connector according to the requirements.
>>
>
> I assume this new connector will be much similar to "
> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
> depending on the "failedLoginAttempts" claim, the new connector will
> depends on new "failedPasswordResetAttempts" claim.
>

Yes. They will share a similar design.


>
> *Lock the account after n failed attempts for a period of time *- Account
>> lock will handle from the identity recovery rest API logic. Also 
>> "PRE_SET_USER_CLAIMS"
>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>> in case of account lock.
>>
>
> Are you referring locking the password recovery flow? What would be the
> impact of locking the "password recovery flow" to the "login flow"?
>

Account lock from any flow (either from "password recovery flow" to the
"login flow") will consider as an account locked situation for the user.


>
> Going through supported password recovery flows listed in [2],
> > Recover with Notification : Has less risk on brute force attacks
>
> Recover with Secret Questions (one question at a time) : Has moderate
> risk on brute force attacks
> > Recover with Secret Questions (multiple questions at a time) : Has
> higher risk on brute force attacks
>

> Considering above, it's better to have this feature enabled by default if
> the password recovery is enabled.
>

+1 . We planning to apply these security enhancements only to 'Recover with
Secret Questions' flows due the less risk in 'Recover with Notification'
flow.


> [1] "[Architecture][IS] Support for Google reCaptha"
> [2] "Identity Management Recovery API improvements"
>
> Thanks,
> Darshana
>
>>
>> Appreciate your input.
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Thanuja Jayasinghe]

Hi Isura,

On Mon, Jun 20, 2016 at 5:54 PM, Isura Karunaratne  wrote:

> Hi Thanuja,
>
> On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> I'm working on $subject.
>>
>> We are planning to prevent this flow from brute force attacks by
>> enabling followings,
>>
>>1. Enable captcha/reCaptcha after n failed attempts
>>2. Lock the account after n failed attempts for a period of time
>>
>>
>> *How to track failed attempts?*
>>
>> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
>> which used in the login flow to track failed login attempts. Since this is
>> a different flow, using the same claim to track the failed password
>> reset attempts will lead to unintended situations. (Ex: After n number
>> of failed attempts in the login flow, a user may try to reset the password.
>> In this case, the user will see captcha if the number of failed attempts
>> reached to the maximum. But since this is the first time which the user
>> tries to reset the password, captcha is redundant.)
>>
>> So we will introduce a new claim call "
>> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
>> this.
>>
>
> +1 for having a seperate claiam for tracking password reset faliled
> attempts since it is different from login Attempts.
>
>>
>>
>> *Implementation*
>>
>> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
>> connector will introduce to handle this. The configuration of the connector
>> UI will allow modifying connector according to the requirements.
>>
>
>> *Lock the account after n failed attempts for a period of time *-
>> Account lock will handle from the identity recovery rest API logic. Also 
>> "PRE_SET_USER_CLAIMS"
>> and "POST_SET_USER_CLAIMS" events will be reused to send notifications
>> in case of account lock.
>>
> Where can we define the lock time?. Is it a new configuration or same
> configuration used when account lock with invalid credentials?
>
>
Yes, we are planning to use the same configuration used in "account lock
with invalid credentials". Because we can consider this is a possible way
for a user account get locked.


> Thanks
> Isura.
>
>>
>> Appreciate your input.
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isura Dilhara Karunaratne
> Senior Software Engineer
>
> Mob +94 772 254 810
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Thanks,

-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Thanuja Jayasinghe]

Hi Pushpalanka/Isura,


On Mon, Jun 20, 2016 at 4:50 PM, Pushpalanka Jayawardhana 
wrote:

> Hi Isura,
>
> On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne 
> wrote:
>
>> HI all,
>>
>> I am working on $subject for WSO2 Identity Sever 5.3.0 release. Following
>> are the currently identified improvements,
>>
>>
>>- Password History -
>>
>> Last 'n' number of passwords need to be maintained in user's history.
>> When user updates his password we don't allow him to choose one of these
>> 'n' passwords again.
>>
>>
>>- Periodic Password Reset -
>>
>> Force the user to periodically (configurable period) reset his password.
>> When doing this we need to leverage the password history feature as well.
>>
>>
>> CREATE TABLE IF NOT EXISTS idn_password_history_data
>>  (
>>   user_name   *VARCHAR*(255) NOT NULL,
>>   user_domain *VARCHAR*(255) NOT NULL,
>>   tenant_id   *INTEGER* DEFAULT -1,
>>   hash*VARCHAR*(255) NOT NULL,
>>   time_created *TIMESTAMP* NOT NULL DEFAULT
>> CURRENT_TIMESTAMP,
>>   PRIMARY KEY (user_name,user_domain,tenant_id,
>> hash),
>>  )
>>
>>
>> All the passwords which are supposed to store in this table are old
>> passwords (expired).
>>
>> - I think we don't need to use the same  password hashing algorithm (with
>> or without salted value) which is defined user-mgt.xml for password history
>> validation.
>> - admin users can change other user's passwords without giving their old
>> passwords. In that case, how can we find the old password hash value to
>> store for password history validation?
>>
> In the given table schema we may need to pay special attention to handle
> user_domain, as secondary user store domain can be changed. Ideally we
> should incorporate a *unique user store domain id* than using user domain
> here.
>

We already have a listener to handle user store domains related operations
called 'AbstractUserStoreConfigListener'. This listener provides "
onUserStoreNamePreUpdate" and "onUserStorePreDelete" methods, which we can
use here to modify "idn_password_history_data" table accordingly.  Also
these methods work with user store domain name.
You can refer [1] for such implementation.


>
>>
>> Your comments and suggestions are highly appreciated.
>>
>> Thanks
>> Isura.
>>
>>
>> Isura Dilhara Karunaratne
>> Senior Software Engineer
>>
>> Mob +94 772 254 810
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Pushpalanka.
> --
> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
> Mobile: +94779716248
> Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
> lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
[1] -
https://github.com/wso2-extensions/identity-user-account-association/blob/master/components/org.wso2.carbon.identity.user.account.association/src/main/java/org/wso2/carbon/identity/user/account/association/internal/UserStoreConfigListenerImpl.java

-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Darshana Gunawardana]

Hi Thanuja,

On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
> this.
>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>

I assume this new connector will be much similar to "
SSOLoginReCaptchaConnector" which is discussed in [1], rather than
depending on the "failedLoginAttempts" claim, the new connector will
depends on new "failedPasswordResetAttempts" claim.

*Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>

Are you referring locking the password recovery flow? What would be the
impact of locking the "password recovery flow" to the "login flow"?

Going through supported password recovery flows listed in [2],
> Recover with Notification : Has less risk on brute force attacks
> Recover with Secret Questions (one question at a time) : Has moderate
risk on brute force attacks
> Recover with Secret Questions (multiple questions at a time) : Has higher
risk on brute force attacks

Considering above, it's better to have this feature enabled by default if
the password recovery is enabled.

[1] "[Architecture][IS] Support for Google reCaptha"
[2] "Identity Management Recovery API improvements"

Thanks,
Darshana

>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; http://wso2.com

*E-mail: darsh...@wso2.com *
*Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Isura Karunaratne]

Hi Thanuja,

On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track
> this.
>

+1 for having a seperate claiam for tracking password reset faliled
attempts since it is different from login Attempts.

>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>

> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
Where can we define the lock time?. Is it a new configuration or same
configuration used when account lock with invalid credentials?

Thanks
Isura.

>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] Adding deployment.properties file to override configurations in components

[Shan Mahanama]

Hi Manuranga,

Is it feasible to support something like below?
> [carbon.yaml]/transports/xyz/port = $sys->https.port
>

Internally, we convert yaml file to an xml file. Then we apply these new
configurations using XPath operations. XPath does not support
*/transports/xyz/port* syntax where *xyz* is the value of a sub element. So
it is not feasible.

Consider the following example.

transports:
  - transport:
  name: abc
  port: 8000
  secure: false
  - transport:
  name: xyz
  port: 9000
  secure: true

When we use *xyz* like you mentioned above, we'll have to go through all
child elements(name, port, secure) of both transports to find the value
*xyz* because we don't exactly know which child element contains this *xyz*
value.
But in the current format, it specifies that the *name *sub element should
contain the *xyz* value. So it is clearer as well.

Thanks,
Shan.

-- 
Shan Mahanama
Software Engineer, WSO2 Inc. http://wso2.com

Email: sh...@wso2.com
Mobile: +94712000498
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Caching Support for Analytics Event Tables

[Anjana Fernando]

Hi,

With a chat we had with Srinath, we've decided to set the default cache
timeout to 10 seconds, so from this moment, it is set to 10 seconds by
default in the code.

Cheers,
Anjana.

On Wed, Jun 15, 2016 at 1:57 PM, Nirmal Fernando  wrote:

> Great! Thanks Anjana!
>
> On Wed, Jun 15, 2016 at 11:26 AM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> We've added the $subject. Basically, a local cache is now maintained in
>> each event table, where it will store the most recently used data items in
>> the cache, up to a certain given cache size, for a maximum given lifetime.
>> The format is as follows:-
>>
>>  @from(eventtable = 'analytics.table' , table.name = 'name', *caching* =
>> 'true', *cache.timeout.seconds* = '10', *cache.size.bytes* = '10')
>>
>> The cache.timeout.seconds and cache.size.bytes values are optional, with
>> default values of 60 (1 minute) and 1024 * 1024 * 10 (10 MB) respectively.
>>
>> Also, there are some debug logs available in the component, if you want
>> to check for explicit cache hit/miss situations and record lookup timing,
>> basically enable debug logs for the class
>> "org.wso2.carbon.analytics.eventtable.AnalyticsEventTable".
>>
>> So basically, if you use analytics event tables in performance sensitive
>> areas in your CEP execution plans, do consider using caching if it is
>> possible to do so.
>>
>> The unit tests are updated with caching, and the updated docs can be
>> found here [1].
>>
>> [1]
>> https://docs.wso2.com/display/DAS310/Understanding+Event+Streams+and+Event+Tables#UnderstandingEventStreamsandEventTables-AnalyticseventtableAnalyticseventtable
>>
>> Cheers,
>> Anjana.
>> --
>> *Anjana Fernando*
>> Senior Technical Lead
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Team Lead - WSO2 Machine Learner
> Associate Technical Lead - Data Technologies Team, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.blogspot.com/
>
>
>


-- 
*Anjana Fernando*
Senior Technical Lead
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Darshana Gunawardana]

Hi,

As I see these two requirements are orthogonal and better to discuss in
separate threads. If we consider one by one,

1. Password History Validation.

This is another layer of password pattern validation, which is done when an
user try to change his password.

Hashing method of old password matters only to this requirement and IMO we
should treat old passwords in the same manner for the current password,
hence the default option would be set the same hashing mechanism for both
old and current passwords. Having a configuration to override this
behaviour and set any password hashing mechanism is fine..

But if we implement  "allowing to change hashing algorithm", it would be
tricky to move current password to idn_password_history_data table with the
new hashing in scenarios like "password recovery", "change password by
admin" where old password is not provided.

One other thing should take note is, password hashing algorithm can vary
from one user store to another, hence hashing algorithm should be a picked
from idn_password_history_data table.


2. Force Password Reset.

This policy enforced when an user try to login.

During login, if user subjected to this policy, the default behaviour would
be to force to change password. As Dulanja mentioned, it will be useful
make password reset optional and give user to skip it, if the admin enable
that option.

If user wanted\have to change the password, it would initiate password
change flow... then depending on the Password history validation feature is
enabled or any other password policy is enabled, user have to enter suited
new password. My point is, Force password reset feature should take care
upto only initiating the password change flow, rest of the password change
flow is depends on password policy features.

As I recall, there was some other requirement came up with this feature
where an user should get an notification before (2weeks, 3days, 1day...
etc) he\she reach to the threshold period. We should implement these
features, in a way we could easily implement such supplementary requirments
as well.


If we consider generally for both these features,

1. What would needed to be configurable for service provider \ application
wise?
> IMO, Force Password Reset feature would be a configurable option for
service provider wise. Having this feature enabled for a service provider
would contribute towards to strong authentication index.

2. How to get use of underlying user store implementations?
> Some userstore implementations (LDAP\AD) do have OOTB support for both
these features. Its better if we can come up with a model where we can get
use of those implementations.

Thanks,
Darshana

On Mon, Jun 20, 2016 at 3:43 PM, Omindu Rathnaweera  wrote:

> Hi,
>
>
>> All the passwords which are supposed to store in this table are old
>>> passwords (expired).
>>>
>>> - I think we don't need to use the same  password hashing algorithm
>>> (with or without salted value) which is defined user-mgt.xml for password
>>> history validation.
>>>
>>
>> IMO using the same hashing algo is cleaner. Isn't the current password
>> also stored in this table? If stored, it's mandatory to use salting.
>>
>
> I believe we should use either the hashing algorithm specified in the
> user-mgt.xml or provide a separate config to specify a hashing algo for
> password history.
>
> Consider the following scenario.
>
> Let's say we have specified the hashing algo in user-mgt.xml as SHA-512
> and we use SHA-256 (hard coded) to store old passwords. Given that the user
> has the option to maintain the old password during a periodic password
> reset, then the old password will be the same as the existing password if
> the user decides to stick with the old password. Now, in the history table
> the current password will be stored in a much weaker hash. This doesn't
> seems right, does it ? Also using the hashing algorithm specified in the
> user-mgt.xml or a different config means that we'll have to store the
> hashing algo in the history table.
>
> Regards,
> Omindu.
>
>
>>
>>
>>> - admin users can change other user's passwords without giving their old
>>> passwords. In that case, how can we find the old password hash value to
>>> store for password history validation?
>>>
>>>
>>> Your comments and suggestions are highly appreciated.
>>>
>>> Thanks
>>> Isura.
>>>
>>>
>>> Isura Dilhara Karunaratne
>>> Senior Software Engineer
>>>
>>> Mob +94 772 254 810
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Dulanja Liyanage
>> Lead, Platform Security Team
>> WSO2 Inc.
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,


*Darshana Gunawardana*Associate Technical Lead
WSO2 Inc.; ht

Re: [Architecture] [Dev]Force Password Reset and Password History validation

[Pushpalanka Jayawardhana]

Hi Isura,

On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne  wrote:

> HI all,
>
> I am working on $subject for WSO2 Identity Sever 5.3.0 release. Following
> are the currently identified improvements,
>
>
>- Password History -
>
> Last 'n' number of passwords need to be maintained in user's history. When
> user updates his password we don't allow him to choose one of these 'n'
> passwords again.
>
>
>- Periodic Password Reset -
>
> Force the user to periodically (configurable period) reset his password.
> When doing this we need to leverage the password history feature as well.
>
>
> CREATE TABLE IF NOT EXISTS idn_password_history_data
>  (
>   user_name   *VARCHAR*(255) NOT NULL,
>   user_domain *VARCHAR*(255) NOT NULL,
>   tenant_id   *INTEGER* DEFAULT -1,
>   hash*VARCHAR*(255) NOT NULL,
>   time_created *TIMESTAMP* NOT NULL DEFAULT
> CURRENT_TIMESTAMP,
>   PRIMARY KEY (user_name,user_domain,tenant_id,
> hash),
>  )
>
>
> All the passwords which are supposed to store in this table are old
> passwords (expired).
>
> - I think we don't need to use the same  password hashing algorithm (with
> or without salted value) which is defined user-mgt.xml for password history
> validation.
> - admin users can change other user's passwords without giving their old
> passwords. In that case, how can we find the old password hash value to
> store for password history validation?
>
In the given table schema we may need to pay special attention to handle
user_domain, as secondary user store domain can be changed. Ideally we
should incorporate a *unique user store domain id* than using user domain
here.

>
>
> Your comments and suggestions are highly appreciated.
>
> Thanks
> Isura.
>
>
> Isura Dilhara Karunaratne
> Senior Software Engineer
>
> Mob +94 772 254 810
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Pushpalanka.
-- 
Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
Mobile: +94779716248
Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ESB 5.0 Data Mapper plan - Dynamic schema generation for connectors.

[Dmitry Sotnikov]

I guess, also there would be some sort of default schema built-in (e.g.
salesforce.com has some default schema out of the box) and like you guys
discussed ability to refresh from live connection.

On Mon, Jun 20, 2016 at 8:13 AM, Malaka Silva  wrote:

> ​
> Hi Maheeka,
>
> On Mon, Jun 20, 2016 at 10:22 AM, Maheeka Jayasuriya 
> wrote:
>
>> ​​
>> Hi Malaka,
>>
>> In order to get the dynamic schemas we need a connection to Salesforce.
>> Right now we are not providing the connection when getting the schema for a
>> connector. Refer screenshot below.
>>
>
> ​IMO design time connection should be independent from run time
> connections.​
>
>
>>
>> [image: Inline image 1]
>>
>> How about we keep a property (a flag) in the connector meta-data whether
>> it is a dynamic schema connector or a static schema connector. If it is a
>> dynamic schema connector, in addition to above, we can add a field to
>> select the connection (from already created connections) and perform the
>> partner API call there. Instead of operation field we can load the entity
>> definitions to load the schema.
>>
> ​Yes those can be added later. Generating dynamic schema part should not
> be a part of connector. However some reference should be there and should
> be available to the tool on demand.
>
> First we need to find the best way to integrate this to tooling. Will
> arrange an discussion on this.
>
>>
>>
> Thanks,
>> Maheeka
>>
>> Maheeka Jayasuriya
>> Senior Software Engineer
>> Mobile : +9450661
>>
>> On Sat, Jun 18, 2016 at 8:01 PM, Malaka Silva  wrote:
>>
>>> Hi,
>>>
>>> Data mapper will be introduced with ESB 5.0.0 tooling soon. This
>>> discussion is related to using data mapper with connectors in your
>>> integration flow.
>>>
>>> Data mapper is a tool that work at design time. So for each connector
>>> operation we need to include a schema in order to make use of data mapping.
>>>
>>> Currently there are two types of connector operations.
>>>
>>>1. Static output and/or input required - If the connector always
>>>produce same output format no issue and we can simply generate the schema
>>>and bundle it with connector.
>>>2. Dynamic output and/or input required - This is becoming a
>>>changeling since output may change depend on the customization done on
>>>individual apps.
>>>
>>> Good example is Salesforce. Object structure from one Salesforce org to
>>> another org can be different.
>>>
>>> So we need some generic mechanism to run this dynamic schema generation
>>> within tooling and specific implementation should be included in the
>>> connector.
>>>
>>> However including this part in a connector can make the connector heavy
>>> and this may not require during the run time. Best we have those in some
>>> place and get to tooling on demand.
>>>
>>> I have done a POC how we can do this for Salesforce. Sample code is
>>> available in [1]. We may have to do the same for each method.
>>>
>>> Here we are using metadata api to get the sObject list. Partner api
>>> describe sObject method to get fields.
>>>
>>> So this way we can get the required input and output and using this we
>>> can generate the schema. This is purely written in java.
>>>
>>> Now the next challenge is to include this with ESB tooling and
>>> connectors. Please put your suggestions.
>>>
>>> [image: Inline image 1]
>>>
>>> [image: Inline image 2]
>>>
>>> Generated output.
>>>
>>> Query
>>>
>>> 
>>> Account
>>> UK
>>> 2016-01-05T09:44:15.000Z
>>> 
>>> Test
>>> 
>>> 
>>> .
>>> 
>>>
>>> Upsert
>>>
>>> 
>>> 
>>> value
>>> value
>>> value
>>> 
>>> ...
>>> 
>>> 
>>>
>>> [1]
>>> https://github.com/malakasilva/ESB/tree/master/salesforce-dynamic-schema
>>>
>>> Best Regards,
>>>
>>> Malaka Silva
>>> Senior Technical Lead
>>> M: +94 777 219 791
>>> Tel : 94 11 214 5345
>>> Fax :94 11 2145300
>>> Skype : malaka.sampath.silva
>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
>>> Blog : http://mrmalakasilva.blogspot.com/
>>>
>>> WSO2, Inc.
>>> lean . enterprise . middleware
>>> http://www.wso2.com/
>>> http://www.wso2.com/about/team/malaka-silva/
>>> 
>>> https://store.wso2.com/store/
>>>
>>> Save a tree -Conserve nature & Save the world for your future. Print
>>> this email only if it is absolutely necessary.
>>>
>>
>>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Technical Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
> 
> https://store.wso2.com/store/
>
> Save a tree -Conserve nature & Save t

Re: [Architecture] [DS]Embeddable gadgets feature for Dashboard Server

[Sinthuja Ragendran]

Hi all,

So far based on all the discussions above I see below facts.

1) APIM log viewer app is using portal as 'Gadget Store', and wants to
embed the gadgets which are residing in the portal app.
2) Without any additional authentication process, the user should be able
to embed the gadget to APIM log viewer app.
3) APIM admin app is using the js, libs, etc from the portal app into their
app, by just importing the files. Also currently you have shiding feature
in the server.

Based on above facts, IMO DS is not correctly exploited here. Basically
portal is NOT a gadget store, and we have the in built gadget store to
cater the main functionality of the DS which is creating dashboards and
managing them. Hence if APIM just want to use gadget a place to store
gadget and render it, then it's not a best place to do so. As you already
have shiding feature in your pack, I would suggest that you just add your
gadgets somewhere in APIM log viewer app it self, and render it. That will
not require and authentication nor perf issues.

Additionally you can only include the js files you required into the APIM
log viewer app it self, and remove the portal app entirely from APIM pack.
Because importing the js files from another application, is a wrong
practice, and we can only make sure we don't change the external APIs not
the internal js files, etc, and that will heavily break APIM log viewer,
which will be a maintenance night mare.

As embedded gadget functionality for DS, we need to embed the gadget
including the settings which have been done to the DS as it's shown in the
DS server (such as permissions to page, gadgets, views, themes at DS, and
gadget settings). Also as we are working on several level of authorization
for gadgets, pages, and views, logged in user information is mandatory and
user should be specifically say which actually he/she want to embed into
their app as the same gadget may have different settings in each
pages/views. Therefore we need the logged in user information, and for that
as I have already mentioned we support basic auth and SSO, which will cover
the third party use cases . Other than that we will include an loading icon
than showing the SSO redirection for this which will provide better user
experience. But anyhow, this is for the sake of DS embeddable gadget
feature, and not for APIM log viewer usecase which is simply embedding a
gadget into their app. IMO the APIM log viewer usecase, it's far more
easier to just maintain the gadgets in their app itself as mentioned above
without actually using the portal app, because anyhow none of the DS main
functionalities not used in the intended way.

Thanks,
Sinthuja.

On Tue, Jun 14, 2016 at 8:29 PM, Manuranga Perera  wrote:

> There are a few ways to get rid of iframe:
> 1) Ignore security and come up with a way to just embed as divs. But this
> may break the parent
> 2) Use Google Caja. We have to feather look into this. It seems they have
> some compatibility with Shindig as well.
> 3) Use WebComponents. This approach needs significant research and coming
> up with new ways to leverage latest browser specs.
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Omindu Rathnaweera]

Hi,


> All the passwords which are supposed to store in this table are old
>> passwords (expired).
>>
>> - I think we don't need to use the same  password hashing algorithm (with
>> or without salted value) which is defined user-mgt.xml for password history
>> validation.
>>
>
> IMO using the same hashing algo is cleaner. Isn't the current password
> also stored in this table? If stored, it's mandatory to use salting.
>

I believe we should use either the hashing algorithm specified in the
user-mgt.xml or provide a separate config to specify a hashing algo for
password history.

Consider the following scenario.

Let's say we have specified the hashing algo in user-mgt.xml as SHA-512 and
we use SHA-256 (hard coded) to store old passwords. Given that the user has
the option to maintain the old password during a periodic password reset,
then the old password will be the same as the existing password if the user
decides to stick with the old password. Now, in the history table the
current password will be stored in a much weaker hash. This doesn't seems
right, does it ? Also using the hashing algorithm specified in the
user-mgt.xml or a different config means that we'll have to store the
hashing algo in the history table.

Regards,
Omindu.


>
>
>> - admin users can change other user's passwords without giving their old
>> passwords. In that case, how can we find the old password hash value to
>> store for password history validation?
>>
>>
>> Your comments and suggestions are highly appreciated.
>>
>> Thanks
>> Isura.
>>
>>
>> Isura Dilhara Karunaratne
>> Senior Software Engineer
>>
>> Mob +94 772 254 810
>>
>>
>
>
> --
> Thanks & Regards,
> Dulanja Liyanage
> Lead, Platform Security Team
> WSO2 Inc.
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Omindu Rathnaweera
Software Engineer, WSO2 Inc.
Mobile: +94 771 197 211
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev]Force Password Reset and Password History validation

[Isura Karunaratne]

Hi Dulanja,

On Mon, Jun 20, 2016 at 12:14 PM, Dulanja Liyanage  wrote:

>
>
> On Mon, Jun 20, 2016 at 12:11 PM, Dulanja Liyanage 
> wrote:
>
>>
>>
>> On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne 
>> wrote:
>>
>>> HI all,
>>>
>>> I am working on $subject for WSO2 Identity Sever 5.3.0 release.
>>> Following are the currently identified improvements,
>>>
>>>
>>>- Password History -
>>>
>>> Last 'n' number of passwords need to be maintained in user's history.
>>> When user updates his password we don't allow him to choose one of these
>>> 'n' passwords again.
>>>
>>>
>>>- Periodic Password Reset -
>>>
>>> Force the user to periodically (configurable period) reset his password.
>>> When doing this we need to leverage the password history feature as well.
>>>
>>>
> There can be a requirement where the system forces the user to change the
> password, but at the same time give him the option to use the old password.
> I've seen some financial organizations doing this.
>
If we are going to support this cofiguration, I think it is better to user
same hashing method.


>
>>>
>>> CREATE TABLE IF NOT EXISTS idn_password_history_data
>>>  (
>>>   user_name   *VARCHAR*(255) NOT NULL,
>>>   user_domain *VARCHAR*(255) NOT NULL,
>>>   tenant_id   *INTEGER* DEFAULT -1,
>>>   hash*VARCHAR*(255) NOT NULL,
>>>   time_created *TIMESTAMP* NOT NULL DEFAULT
>>> CURRENT_TIMESTAMP,
>>>   PRIMARY KEY (user_name,user_domain,tenant_id,
>>> hash),
>>>  )
>>>
>>>
>>> All the passwords which are supposed to store in this table are old
>>> passwords (expired).
>>>
>>> - I think we don't need to use the same  password hashing algorithm
>>> (with or without salted value) which is defined user-mgt.xml for password
>>> history validation.
>>>
>>
>> IMO using the same hashing algo is cleaner. Isn't the current password
>> also stored in this table? If stored, it's mandatory to use salting.
>>
> Current password will not store in the new table.

>
>>
>>> - admin users can change other user's passwords without giving their old
>>> passwords. In that case, how can we find the old password hash value to
>>> store for password history validation?
>>>
>>>
>>> Your comments and suggestions are highly appreciated.
>>>
>>> Thanks
>>> Isura.
>>>
>>>
>>> Isura Dilhara Karunaratne
>>> Senior Software Engineer
>>>
>>> Mob +94 772 254 810
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Dulanja Liyanage
>> Lead, Platform Security Team
>> WSO2 Inc.
>>
>
>
>
> --
> Thanks & Regards,
> Dulanja Liyanage
> Lead, Platform Security Team
> WSO2 Inc.
>



-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Milan Perera]

>
> My suggestion is: default should be to force the user and not give him/her
>> the option to use the old password, but make it configurable so the
>> scenarios I mentioned above could be catered, if required. WDYT?
>>
>
​+1 for having it as an configurable option​


-- 
*Milan Perera *| Software Engineer
WSO2, Inc | lean. enterprise. middleware.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 77 309 7088 | Work: +94 11 214 5345
Email: mi...@wso2.com  | Web: www.wso2.com

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

[Architecture] WSO2 Carbon Kernel 4.4.6 Released

[Kalpa Welivitigoda]

The Carbon team is pleased to announce the release of Carbon Kernel 4.4.6.

*Improvements and Bug fixes*
https://wso2.org/jira/issues/?filter=13090

*Known Issues*
https://wso2.org/jira/issues/?filter=13103

*How to Contribute*

   - WSO2 Carbon Kernel code is hosted in github.
   - The Git repository is https://github.com/wso2/carbon-kernel/
   - Carbon Kernel 4.4.6 release tag is
https://github.com/wso2/carbon-kernel/releases/tag/v4.4.6
   - Please report issues at Carbon Jira,
https://wso2.org/jira/browse/CARBON

*Contact Us*

​WSO2 Carbon developers​ can be contacted via following mailing lists:

   - WSO2 Developers List: d...@wso2.org
   - WSO2 Architecture List: architecture@wso2.org

​You can download the released distribution from the following location.
http://wso2.com/products/carbon/

​Thank you for your interest in WSO2 Carbon Kernel​.

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

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Great: we are in agreement :-))


Best regards,
Frank

2016-06-20 9:05 GMT+02:00 Vinod Kavinda :

> Hi Frank,
> Agreed for the both suggestions.
>
> As Nandika mentioned "Not accepting a change in the substitute" is the
> option we also decided, whenever we have the ability to do so. But there
> are situations that we cannot do this when the cyclic situation arisen due
> to a time event. Theoratically, we don't have anyone to assign this task at
> this point, so it has to go back to Business Administrator as you suggested.
>
> However, in Activiti the corresponding role is "Task Owner". We will have
> to assign to task owner in this situation. One issue is the task owner is
> optional. Only in such a situation(no owner), we will have to make the task
> Claimable/Unreserved.
>
> Regards,
> Vinod
>
> On Mon, Jun 20, 2016 at 10:48 AM, Nandika Jayawardana 
> wrote:
>
>> Hi Frank,
>>
>> Not accepting a change in the substitute when there is a cyclic situation
>> is the options we decided as well.
>>
>> Regards
>> Nandika
>>
>> On Fri, Jun 17, 2016 at 11:26 PM, Frank Leymann  wrote:
>>
>>> Hi Vinod,
>>>
>>> Whenever a user changes his/her substitute, we check for a circular
>>> dependency.  This check happens independent of the fact whether substitutes
>>> are defined when the user are created ("modeling time") or when the
>>> substitute of a user is changed during "runtime". Is that your
>>> understanding too?
>>>
>>> If a circular dependency is detected, the request for the new substitute
>>> is not accepted.  And, yes, that's problematic because it may become quite
>>> cumbersome or even impossible to find a possible substitute (i.e. one that
>>> our cycle checker will accept).  For example, in case of n users U1,
>>> U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we
>>> have a problem. During modeling time their may be time to fix the problem,
>>> but during runtime that may be critical.  Setting the Reserved or
>>> inProgress tasks of the user just defining his new substitute in state
>>> Ready doesn't help because there may be no potential owners who may get
>>> aware about the task.
>>>
>>> For this purpose, the key principle of Human Task is that the engine
>>> must do everything to push tasks to (at least) Reserve status. This is done
>>> by corresponding deadline processing, or by nomination: i.e. the engine
>>> informs the Business Administrator of the task who then assigns the task to
>>> an owner. But this may result in a burden of the Business Administrator in
>>> case he will get many tasks to nominate.
>>>
>>> So, let's discuss. My current preference is to *not accept* a change in
>>> the substitute definition in case a cyclic structure would result.  WDYT?
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2016-06-16 3:31 GMT+02:00 Vinod Kavinda :
>>>
 Hi Frank,
 Yes, it's when changing the substitute user. We have to use the second
 suggestion also.

 In a scenario where substitution starts in a future time(not just after
 changing the substitute user), we do not have the option of rejecting the
 substitution request. In such a scenario, we will have to make his tasks
 unclaimed!

 Regards,
 Vinod
 On Jun 16, 2016 2:28 AM, "Frank Leymann"  wrote:

 Hi Vinod,

 yes, that's a well-known issue :-)   I suggest to adopt your first
 suggestion, namely checking circular dependencies when a new substitute has
 been specified (I guess that's what you meant - not when adding a new user,
 right?).



 Best regards,
 Frank

 2016-06-15 13:25 GMT+02:00 Vinod Kavinda :

> Hi all,
> I ran into an issue while implementing this.
>
> What if we ran into a *circular dependency between user substitutes*?
> We can't calculate a transitive substitute in this scenario. No one will 
> be
> available to take up the tasks of the unavailable user.
>
> Here is my suggestion for this:
>
> *Circular dependency detected while adding a new user*
> We abort this user addition and reply back to the user asking for a
> new substitute.
>
> *Circular dependency detected while resolving transitive subs in a
> scheduled event (Due to a user's substitution starting at this point )*
>
> Mark the transitive sub is "UNDEFINED". Future tasks that are
> assigning to this user will be reverted back as unclaimed tasks (remove 
> the
> assignee).
>
> Any suggestions?
>
>
>
>
> On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda  wrote:
>
>> Hi Frank,
>> Agreed.
>> I have created Jira [1] to track this improvement after the Human
>> Task integration with BPMN engine.
>>
>> [1] - https://wso2.org/jira/browse/BPS-1043
>>
>> Regards,
>> Vinod
>>
>> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana <
>> nand...@wso2.com> wrote:
>>
>>> Yes, Once the task en

[Architecture] [IS] Block brute force attacks on password recovery flows

[Thanuja Jayasinghe]

Hi All,

I'm working on $subject.

We are planning to prevent this flow from brute force attacks by enabling
followings,

   1. Enable captcha/reCaptcha after n failed attempts
   2. Lock the account after n failed attempts for a period of time


*How to track failed attempts?*

We already have a "http://wso2.org/claims/identity/failedLoginAttempts"; claim
which used in the login flow to track failed login attempts. Since this is
a different flow, using the same claim to track the failed password reset
attempts will lead to unintended situations. (Ex: After n number of failed
attempts in the login flow, a user may try to reset the password. In this
case, the user will see captcha if the number of failed attempts reached to
the maximum. But since this is the first time which the user tries to reset
the password, captcha is redundant.)

So we will introduce a new claim call "
http://wso2.org/claims/identity/failedPasswordResetAttempts"; to track this.


*Implementation*

*Enable captcha/reCaptcha after n failed attempts* -  New Captcha connector
will introduce to handle this. The configuration of the connector UI will
allow modifying connector according to the requirements.

*Lock the account after n failed attempts for a period of time *- Account
lock will handle from the identity recovery rest API logic. Also
"PRE_SET_USER_CLAIMS"
and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
case of account lock.

Appreciate your input.

Thanks,
Thanuja

-- 
*Thanuja Lakmal*
Senior Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94715979891 +94758009992
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Prasad Tissera]

+1 for having an configurable option to use an old password. This gives
security admins the flexibility to decide what best suite there security
policies.

On Mon, Jun 20, 2016 at 4:35 PM, Dulanja Liyanage  wrote:

> Yes, but in a scenario where multi-factor authentication is used, risk
> might be minimal. Also, if the server is catering only internal
> requirements, like in a corporate department, and not exposed to the
> outside, having to change the password every 3 months or so on might affect
> the usability. People tend to run out of passwords that could be easily
> remembered. Then they might opt to write it somewhere.
>
> My suggestion is: default should be to force the user and not give him/her
> the option to use the old password, but make it configurable so the
> scenarios I mentioned above could be catered, if required. WDYT?
>
> On Mon, Jun 20, 2016 at 12:44 PM, Milan Perera  wrote:
>
>>
>> ​Hi Dulanja,​
>>
>>
>>> There can be a requirement where the system forces the user to change
>>> the password, but at the same time give him the option to use the old
>>> password. I've seen some financial organizations doing this.
>>>

>
>> IMO, letting use of one of ​old password again creates a security threat.
>> Isn't it?
>>
>> Regards,
>> --
>> *Milan Perera *| Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>>
>
>
>
> --
> Thanks & Regards,
> Dulanja Liyanage
> Lead, Platform Security Team
> WSO2 Inc.
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


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

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Dulanja Liyanage]

Yes, but in a scenario where multi-factor authentication is used, risk
might be minimal. Also, if the server is catering only internal
requirements, like in a corporate department, and not exposed to the
outside, having to change the password every 3 months or so on might affect
the usability. People tend to run out of passwords that could be easily
remembered. Then they might opt to write it somewhere.

My suggestion is: default should be to force the user and not give him/her
the option to use the old password, but make it configurable so the
scenarios I mentioned above could be catered, if required. WDYT?

On Mon, Jun 20, 2016 at 12:44 PM, Milan Perera  wrote:

>
> ​Hi Dulanja,​
>
>
>> There can be a requirement where the system forces the user to change the
>> password, but at the same time give him the option to use the old
>> password. I've seen some financial organizations doing this.
>>
>>>

> IMO, letting use of one of ​old password again creates a security threat.
> Isn't it?
>
> Regards,
> --
> *Milan Perera *| Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
> Email: mi...@wso2.com  | Web: www.wso2.com
> 
>



-- 
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Force Password Reset and Password History validation

[Milan Perera]

​Hi Dulanja,​


> There can be a requirement where the system forces the user to change the
> password, but at the same time give him the option to use the old password.
> I've seen some financial organizations doing this.
>
>>
>>>
IMO, letting use of one of ​old password again creates a security threat.
Isn't it?

Regards,
-- 
*Milan Perera *| Software Engineer
WSO2, Inc | lean. enterprise. middleware.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 77 309 7088 | Work: +94 11 214 5345
Email: mi...@wso2.com  | Web: www.wso2.com

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

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Vinod Kavinda]

Hi Frank,
Agreed for the both suggestions.

As Nandika mentioned "Not accepting a change in the substitute" is the
option we also decided, whenever we have the ability to do so. But there
are situations that we cannot do this when the cyclic situation arisen due
to a time event. Theoratically, we don't have anyone to assign this task at
this point, so it has to go back to Business Administrator as you suggested.

However, in Activiti the corresponding role is "Task Owner". We will have
to assign to task owner in this situation. One issue is the task owner is
optional. Only in such a situation(no owner), we will have to make the task
Claimable/Unreserved.

Regards,
Vinod

On Mon, Jun 20, 2016 at 10:48 AM, Nandika Jayawardana 
wrote:

> Hi Frank,
>
> Not accepting a change in the substitute when there is a cyclic situation
> is the options we decided as well.
>
> Regards
> Nandika
>
> On Fri, Jun 17, 2016 at 11:26 PM, Frank Leymann  wrote:
>
>> Hi Vinod,
>>
>> Whenever a user changes his/her substitute, we check for a circular
>> dependency.  This check happens independent of the fact whether substitutes
>> are defined when the user are created ("modeling time") or when the
>> substitute of a user is changed during "runtime". Is that your
>> understanding too?
>>
>> If a circular dependency is detected, the request for the new substitute
>> is not accepted.  And, yes, that's problematic because it may become quite
>> cumbersome or even impossible to find a possible substitute (i.e. one that
>> our cycle checker will accept).  For example, in case of n users U1,
>> U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we
>> have a problem. During modeling time their may be time to fix the problem,
>> but during runtime that may be critical.  Setting the Reserved or
>> inProgress tasks of the user just defining his new substitute in state
>> Ready doesn't help because there may be no potential owners who may get
>> aware about the task.
>>
>> For this purpose, the key principle of Human Task is that the engine must
>> do everything to push tasks to (at least) Reserve status. This is done by
>> corresponding deadline processing, or by nomination: i.e. the engine
>> informs the Business Administrator of the task who then assigns the task to
>> an owner. But this may result in a burden of the Business Administrator in
>> case he will get many tasks to nominate.
>>
>> So, let's discuss. My current preference is to *not accept* a change in
>> the substitute definition in case a cyclic structure would result.  WDYT?
>>
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-06-16 3:31 GMT+02:00 Vinod Kavinda :
>>
>>> Hi Frank,
>>> Yes, it's when changing the substitute user. We have to use the second
>>> suggestion also.
>>>
>>> In a scenario where substitution starts in a future time(not just after
>>> changing the substitute user), we do not have the option of rejecting the
>>> substitution request. In such a scenario, we will have to make his tasks
>>> unclaimed!
>>>
>>> Regards,
>>> Vinod
>>> On Jun 16, 2016 2:28 AM, "Frank Leymann"  wrote:
>>>
>>> Hi Vinod,
>>>
>>> yes, that's a well-known issue :-)   I suggest to adopt your first
>>> suggestion, namely checking circular dependencies when a new substitute has
>>> been specified (I guess that's what you meant - not when adding a new user,
>>> right?).
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2016-06-15 13:25 GMT+02:00 Vinod Kavinda :
>>>
 Hi all,
 I ran into an issue while implementing this.

 What if we ran into a *circular dependency between user substitutes*?
 We can't calculate a transitive substitute in this scenario. No one will be
 available to take up the tasks of the unavailable user.

 Here is my suggestion for this:

 *Circular dependency detected while adding a new user*
 We abort this user addition and reply back to the user asking for a new
 substitute.

 *Circular dependency detected while resolving transitive subs in a
 scheduled event (Due to a user's substitution starting at this point )*

 Mark the transitive sub is "UNDEFINED". Future tasks that are assigning
 to this user will be reverted back as unclaimed tasks (remove the 
 assignee).

 Any suggestions?




 On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda  wrote:

> Hi Frank,
> Agreed.
> I have created Jira [1] to track this improvement after the Human Task
> integration with BPMN engine.
>
> [1] - https://wso2.org/jira/browse/BPS-1043
>
> Regards,
> Vinod
>
> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana  > wrote:
>
>> Yes, Once the task engine refactoring is complete, we can integrate
>> our own task implementation with activiti . Then we can overcome the
>> current limitations of user tasks.
>>
>> Regards
>> Nandika
>>
>> On Wed, Jun 8, 2016 at 7:18 PM, Milinda Perera 
>> wrote:
>