date:20180514

Re: [Dev] Retry with authenticators for adaptive authentication.

2018-05-14 Thread Maduranga Siriwardena

Hi Omindu,

This applies only if you are enabling the script. Otherwise it will behave
as before without any change.

Thanks,

On Tue, May 15, 2018 at 9:26 AM Omindu Rathnaweera  wrote:

> Hi Maduranga,
>
> On Mon, May 14, 2018 at 11:57 AM Maduranga Siriwardena 
> wrote:
>
>> After trying several methods to implement a retry mechanism, we decided
>> to go for below approach.
>>
>> Authentication framework will not prompt for retrying unless it is
>> specifically written in the script. So if we want to retry the
>> authentication, the conditional authentication script would be like below.
>>
>
> Not sure whether I got this right. But does this mean, moving forward, if
> we need the retry behavior of the basic authenticator, we will have to get
> it done through a script ?
>
>
>>
>> function onInitialRequest(context) {
>> retryCount = 3;
>> executeBasicAuth(context, retryCount);
>> }
>>
>> function executeBasicAuth(context, retryCount) {
>>Log.info('--- executeBasicAuth retryCount ' + retryCount);
>>executeStep({
>>id: '1',
>>on: {
>>success: function (context) {
>>Log.info('--- authentication succcessfull ');
>>var isAdmin = hasRole(context, 'admin');
>>Log.info('--- Has Admin ' + isAdmin);
>>if (isAdmin) {
>>executeStep({id: '2'});
>>}
>>},
>>fail: function (context) {
>> Log.info('--- fail retryCount ' + retryCount);
>> --retryCount;
>> if (retryCount > 0) {
>> executeBasicAuth(context, retryCount);
>> } else {
>> Log.info('--- login failed ');
>> }
>>}
>>}
>>});
>> }
>>
>>
>> This script will try to authenticate the user 3 times in case credentials
>> are incorrect. This approach will ensure that the authentication flow is
>> strictly controlled by the script and there is no unnecessary/unwanted
>> behavior.
>>
>> But with this approach we have a issue with how to get the authentication
>> failure reason in case of a retrying step. At the moment in the basic
>> authenticator, this failure message is set by checking
>> "context.isRetrying()" [1]. With the new implementation, authentication
>> framework is not aware if this is a retrying step or not. We are trying to
>> find a solution for this. Any suggestions are welcome.
>>
>> [1]
>> https://github.com/wso2-extensions/identity-local-auth-basicauth/blob/v5.3.7/components/org.wso2.carbon.identity.application.authenticator.basicauth/src/main/java/org/wso2/carbon/identity/application/authenticator/basicauth/BasicAuthenticator.java#L108
>>
>> Thanks,
>> Maduranga.
>>
>>
>>
>> On Tue, May 8, 2018 at 12:26 PM Maduranga Siriwardena 
>> wrote:
>>
>>> Hi Gayan,
>>>
>>> Thanks for the suggestion.
>>>
>>> Yes its better to provide a configuration to change the number of retry
>>> attempts. Apart from the above mentioned behavior, we will consider this
>>> also in the implementation.
>>>
>>> Thanks,
>>>
>>> On Tue, May 8, 2018 at 9:31 AM gayan gunawardana <
>>> gmgunaward...@gmail.com> wrote:
>>>


 On Mon, May 7, 2018 at 7:17 PM, Maduranga Siriwardena <
 madura...@wso2.com> wrote:

> Hi devs,
>
> In the Identity Server at the moment "retryAuthenticationEnabled"
> method in the authenticators decide whether the user is allowed to retry
> the authentication with that particular authenticator. Based on the result
> from this method, authenticator itself triggers the retry flow.
>
> Because of this we have a main disadvantage for the implementation of
> adaptive authentication. If retry is enabled, fail call back function in
> JavaScript is not triggered.
>
> So we are planning to change this behavior and send the authentication
> retry flow through the authentication framework. Below is the planned
> behavior.
>
>- Authenticator will retry to authenticate by default.
>- If the fail callback function has other steps to execute,
>authenticator will not retry to authenticate.
>- Developers can disable retry for a authentication sequence by
>setting a parameter in the context.
>
> Isn't it better to invoke fail callback function after pre-configured
 number of retry attempts.

> Please provide us with feedback what need to be changed from the above
> mentioned behavior.
>
> Thanks,
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591
> Blog: *https://madurangasiriwardena.wordpress.com/
> *
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
>

Re: [Dev] Retry with authenticators for adaptive authentication.

2018-05-14 Thread Omindu Rathnaweera

Hi Maduranga,

On Mon, May 14, 2018 at 11:57 AM Maduranga Siriwardena 
wrote:

> After trying several methods to implement a retry mechanism, we decided to
> go for below approach.
>
> Authentication framework will not prompt for retrying unless it is
> specifically written in the script. So if we want to retry the
> authentication, the conditional authentication script would be like below.
>

Not sure whether I got this right. But does this mean, moving forward, if
we need the retry behavior of the basic authenticator, we will have to get
it done through a script ?


>
> function onInitialRequest(context) {
> retryCount = 3;
> executeBasicAuth(context, retryCount);
> }
>
> function executeBasicAuth(context, retryCount) {
>Log.info('--- executeBasicAuth retryCount ' + retryCount);
>executeStep({
>id: '1',
>on: {
>success: function (context) {
>Log.info('--- authentication succcessfull ');
>var isAdmin = hasRole(context, 'admin');
>Log.info('--- Has Admin ' + isAdmin);
>if (isAdmin) {
>executeStep({id: '2'});
>}
>},
>fail: function (context) {
> Log.info('--- fail retryCount ' + retryCount);
> --retryCount;
> if (retryCount > 0) {
> executeBasicAuth(context, retryCount);
> } else {
> Log.info('--- login failed ');
> }
>}
>}
>});
> }
>
>
> This script will try to authenticate the user 3 times in case credentials
> are incorrect. This approach will ensure that the authentication flow is
> strictly controlled by the script and there is no unnecessary/unwanted
> behavior.
>
> But with this approach we have a issue with how to get the authentication
> failure reason in case of a retrying step. At the moment in the basic
> authenticator, this failure message is set by checking
> "context.isRetrying()" [1]. With the new implementation, authentication
> framework is not aware if this is a retrying step or not. We are trying to
> find a solution for this. Any suggestions are welcome.
>
> [1]
> https://github.com/wso2-extensions/identity-local-auth-basicauth/blob/v5.3.7/components/org.wso2.carbon.identity.application.authenticator.basicauth/src/main/java/org/wso2/carbon/identity/application/authenticator/basicauth/BasicAuthenticator.java#L108
>
> Thanks,
> Maduranga.
>
>
>
> On Tue, May 8, 2018 at 12:26 PM Maduranga Siriwardena 
> wrote:
>
>> Hi Gayan,
>>
>> Thanks for the suggestion.
>>
>> Yes its better to provide a configuration to change the number of retry
>> attempts. Apart from the above mentioned behavior, we will consider this
>> also in the implementation.
>>
>> Thanks,
>>
>> On Tue, May 8, 2018 at 9:31 AM gayan gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, May 7, 2018 at 7:17 PM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 Hi devs,

 In the Identity Server at the moment "retryAuthenticationEnabled"
 method in the authenticators decide whether the user is allowed to retry
 the authentication with that particular authenticator. Based on the result
 from this method, authenticator itself triggers the retry flow.

 Because of this we have a main disadvantage for the implementation of
 adaptive authentication. If retry is enabled, fail call back function in
 JavaScript is not triggered.

 So we are planning to change this behavior and send the authentication
 retry flow through the authentication framework. Below is the planned
 behavior.

- Authenticator will retry to authenticate by default.
- If the fail callback function has other steps to execute,
authenticator will not retry to authenticate.
- Developers can disable retry for a authentication sequence by
setting a parameter in the context.

 Isn't it better to invoke fail callback function after pre-configured
>>> number of retry attempts.
>>>
 Please provide us with feedback what need to be changed from the above
 mentioned behavior.

 Thanks,
 --
 Maduranga Siriwardena
 Senior Software Engineer
 WSO2 Inc; http://wso2.com/

 Email: madura...@wso2.com
 Mobile: +94718990591
 Blog: *https://madurangasiriwardena.wordpress.com/
 *
 

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Gayan
>>>
>>
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: madura...@wso2.com
>> Mobile: +94718990591
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> *
>> 
>>
>
>

Re: [Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

2018-05-14 Thread Prabushi Samarakoon

WSO2 EI 6.2.0 tooling documentation can be found at [2]
 under relevant tutorials.

Thanks,
Prabushi

[2] - https://docs.wso2.com/display/EI620/Tutorials


On Mon, May 14, 2018 at 10:56 PM, Prabushi Samarakoon 
wrote:

> Hi Segers,
>
> WSO2 Developer Studio 3.8.0 is not fully compatible with EI 6.2.0 since we
> have introduced synapse definition changes (eg: new cache mediator
> configuration), new feature support (eg: Nashorn support with script
> mediator), etc. with WSO2 EI 6.2.0. Therefore, we have released product
> compatible tooling distributions with WSO2 EI 6.2.0 release.
>
> Furthermore, we have introduced separate Developer Studio tooling
> documentation for WSO2 EIxx [1]
>  
> within
> the product documentation.
>
> Thanks,
> Prabushi
>
> [1] - https://docs.wso2.com/display/EI600/WSO2+Enterprise+
> Integrator+Tooling
>
> On Mon, May 14, 2018 at 7:52 PM, R. Carl Segers  > wrote:
>
>> Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager
>> 2.2?
>>
>>
>>
>> If so, why is wso2 developer studio 3.8.0 listed in the Legacy section of
>> the doc site?
>>
>>
>>
>> Thanks,
>>
>> Carl
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Prabushi Samarakoon*
> Software Engineer
> Mobile: +94715434580
> Email: prabus...@wso2.com
>



-- 
*Prabushi Samarakoon*
Software Engineer
Mobile: +94715434580
Email: prabus...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

2018-05-14 Thread Prabushi Samarakoon

Hi Segers,

WSO2 Developer Studio 3.8.0 is not fully compatible with EI 6.2.0 since we
have introduced synapse definition changes (eg: new cache mediator
configuration), new feature support (eg: Nashorn support with script
mediator), etc. with WSO2 EI 6.2.0. Therefore, we have released product
compatible tooling distributions with WSO2 EI 6.2.0 release.

Furthermore, we have introduced separate Developer Studio tooling
documentation for WSO2 EIxx [1]
 within
the product documentation.

Thanks,
Prabushi

[1] - https://docs.wso2.com/display/EI600/WSO2+Enterprise+Integrator+Tooling

On Mon, May 14, 2018 at 7:52 PM, R. Carl Segers 
wrote:

> Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?
>
>
>
> If so, why is wso2 developer studio 3.8.0 listed in the Legacy section of
> the doc site?
>
>
>
> Thanks,
>
> Carl
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>

-- 
*Prabushi Samarakoon*
Software Engineer
Mobile: +94715434580
Email: prabus...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

2018-05-14 Thread R. Carl Segers

Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

If so, why is wso2 developer studio 3.8.0 listed in the Legacy section of the 
doc site?

Thanks,
Carl
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] ClassNotFoundException: org.wso2.carbon.webapp.mgt.filter.AuthorizationHeaderFilter

2018-05-14 Thread Madhawa Gunasekara

Hi All,

We can specify this filter in global web.xml. However some profiles don't
need this feature, therefore, OSGI won't load this bundle. If we use tomcat
annotations, we get this CNF exception. since we are using a shared plugins
folder among the profiles. therefore we can't use annotations.

@Identity Team: Can you fix this properly.

[1]
https://github.com/wso2/carbon-deployment/blob/4.7.x/components/webapp-mgt/org.wso2.carbon.webapp.mgt/src/main/java/org/wso2/carbon/webapp/mgt/filter/AuthorizationHeaderFilter.java

Thanks,
Madhawa

On Fri, May 11, 2018 at 8:49 AM, Madhawa Gunasekara 
wrote:

> Hi All,
>
> I'm getting this ClassNotFound exception, I have seen that this issue can
> be avoid by installing web app hosting features to the p2-profile [1]. but
> I don't need web apps hosting feature for the p2-profile
>
> How can I avoid this issue?
>
> [2018-05-11 08:39:03,831] [EI-Lightweight] ERROR - StandardContext
> Exception starting filter org.wso2.carbon.webapp.mgt.filter.
> AuthorizationHeaderFilter
> java.lang.ClassNotFoundException: org.wso2.carbon.webapp.mgt.filter.
> AuthorizationHeaderFilter
> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
> WebappClassLoaderBase.java:1907)
> at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(
> WebappClassLoaderBase.java:1750)
> at org.apache.catalina.core.DefaultInstanceManager.loadClass(
> DefaultInstanceManager.java:534)
> at org.apache.catalina.core.DefaultInstanceManager.
> loadClassMaybePrivileged(DefaultInstanceManager.java:516)
> at org.apache.catalina.core.DefaultInstanceManager.newInstance(
> DefaultInstanceManager.java:148)
> at org.apache.catalina.core.ApplicationFilterConfig.getFilter(
> ApplicationFilterConfig.java:264)
> at org.apache.catalina.core.ApplicationFilterConfig.
> (ApplicationFilterConfig.java:108)
> at org.apache.catalina.core.StandardContext.filterStart(
> StandardContext.java:4958)
> at org.apache.catalina.core.StandardContext.startInternal(
> StandardContext.java:5660)
> at org.apache.catalina.util.LifecycleBase.start(
> LifecycleBase.java:145)
> at org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1700)
> at org.apache.catalina.core.ContainerBase$StartChild.call(
> ContainerBase.java:1690)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> [2018-05-11 08:39:03,833] [EI-Lightweight] ERROR - StandardContext One or
> more Filters failed to start. Full details will be found in the appropriate
> container log file
> [2018-05-11 08:39:03,833] [EI-Lightweight] ERROR - StandardContext Context
> [/] startup failed due to previous errors
>
> [1] https://github.com/wso2/product-ei/issues/1275
>
> Thanks,
> Madhawa
>
> --
> *Madhawa Gunasekara*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 719411002 <+94+719411002>
> blog: *http://madhawa-gunasekara.blogspot.com
> *
> linkedin: *http://lk.linkedin.com/in/mgunasekara
> *
>



-- 
*Madhawa Gunasekara*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 719411002 <+94+719411002>
blog: *http://madhawa-gunasekara.blogspot.com
*
linkedin: *http://lk.linkedin.com/in/mgunasekara
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Update Binary attribute in Active directory via wso2 ldap Connector

2018-05-14 Thread chathura prasad amarathunga

hi Shakila,

I tried the update thumbnailPhoto via LDAP Connector and I have following
issue on update image.
In AD keep the image as byte[] but from the ESB cannot pass the Binary data
. I can sent it with encode with base64 it update the attribute value but
it is not the default data type in the AD.

Is there a way to send via ESB . Appreciate your help

Cheers!
Chathura

On Thu, Apr 19, 2018 at 5:40 PM, Shakila Sasikaran  wrote:

> Hi Chathura,
>
> Since this is an attribute, can you add a JSON entry with the key
> *thumbnailPhoto* and add the byte array as the value into the *attribute*
> object and try? You can refer the documentation [1] for more information
> about the update entry operation.
>
> [1] https://docs.wso2.com/display/ESBCONNECTORS/Working+with+CRU
> D+operations+in+LDAP#WorkingwithCRUDoperationsinLDAP-updateEntry
>
> Thanks
>
> On Thu, Apr 19, 2018 at 4:05 PM, chathura prasad amarathunga <
> drchath...@gmail.com> wrote:
>
>> Hi Team,
>> Is it possible to update binary attribute in the Active Directory ( like
>> update Profile Image ). by using the Wso2 LDAP Connector.
>>
>> Cheers!
>> Chathura
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Shakila Sasikaran
> Software Engineer
> Mobile :+94 (0) 77 526 6848
> shak...@wso2.com
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Problem with IE6 using WS-SecurityPolicy

2018-05-14 Thread Bernard Paris

Hi devs,

We need to useWS-SecurityPolicy with x509Token to query a ws, so we defined an 
address endpoint with policy, something like
https://remote.server;>




Here is the initiatorToken part of the policy file I defined in the policy file:


 
  http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>


 
  http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient;>

   
  
  
   
  
 


…. expecting I will got some "ds:X509Data" datas in the SOAP header to send, 
something like

 
 
 
 
CN=WSJanusTEST_BULL001 
1243600900 


Unfortunately the only thing I get is


http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 wsu:Id="STRId-171B34AA705833EBA0152628551959218">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>




Could you tell me where I'm wrong ?
Here are the related carbon logs:
[2018-05-14 10:44:27,520] [EI-Core] DEBUG - WSDoAllSender WSDoAllSender: enter 
invoke()
[2018-05-14 10:44:27,520] [EI-Core] DEBUG - AsymmetricBindingBuilder 
AsymmetricBindingBuilder build invoked
[2018-05-14 10:44:27,520] [EI-Core] DEBUG - BindingBuilder Processing symmetric 
binding: Setting up encryption token and signature token
[2018-05-14 10:44:27,520] [EI-Core] DEBUG - BindingBuilder Obtaining the 
Encryption Token
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - BindingBuilder Token inclusion: 3
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - BindingBuilder User : CertEcole
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - RampartUtil loading class : 
be.ucl.sgsi.sisg.bp.PWCBHandler
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - BindingBuilder Password : aSecret
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - RampartUtil Loading Signature crypto
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - RampartUtil Using provider: 
org.apache.ws.security.components.crypto.Merlin
[2018-05-14 10:44:27,521] [EI-Core] DEBUG - RampartUtil Cache Hit : Crypto 
Object was found in cache.
[2018-05-14 10:44:27,527] [EI-Core] DEBUG - AsymmetricBindingBuilder 
AsymmetricBindingBuilder build invoked : DONE




Thanks for any help,
Bernard

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] VFS FTP connection timeout settings

2018-05-14 Thread Fernandes, Norberto

Hi Riyafa,
Created two issues. On for this scenario and another one that is related
with another setting that I was investigating in parallel.

https://github.com/wso2/product-ei/issues/2166
https://github.com/wso2/product-ei/issues/2167

Let me know if you need any further clarification.

Cheers,
Norberto

On 11 May 2018 at 04:34, Riyafa Abdul Hameed  wrote:

> Hi Norberto,
>
> Can you please report an issue here[1] with a complete example on how to
> reproduce. Please include a sample proxy and the logs generated. Also
> include details on how to enable the logs you generated. We shall look into
> it.
>
> [1] https://github.com/wso2/product-ei/issues
>
> Thanks,
> Riyafa
>
> On Wed, May 9, 2018 at 3:03 PM Fernandes, Norberto <
> nfern...@jaguarlandrover.com> wrote:
>
>> Hi,
>>
>> Riyafa, I am using EI 6.2.0.
>>
>> Thishani, On the proxy I defined the maxRetryCount and reconnectTimeout
>> like:
>>
>> 
>>ftp://:a@10.
>> xxx.206/QA/J?transport.vfs.ReconnectTimeout=10
>> transport.vfs.MaxRetryCount=5>
>>
>> If you notice on the log that I sent, these parameters are defined and
>> printed by the VFSOutTransportInfo. But I don't think these parameters are
>> sent to the vfs ftp provider classes.
>> Or there are other set of parameters to set it. But I could not find any
>> documentation on these.
>>
>> Regards,
>> Norberto
>>
>>
>>
>> On 9 May 2018 at 05:25, Thishani Lucas  wrote:
>>
>>> Hi Norberto,
>>>
>>> As you can see from the code [1], these logs are printed if there's a
>>> number format exp. How did you define the MaxRetryCount and
>>> ReconnectTimeout?
>>>
>>> [1] https://github.com/wso2/wso2-commons-vfs/blob/2.2.x/
>>> commons-vfs2/src/main/java/org/apache/commons/vfs2/
>>> provider/ftp/FtpClientFactory.java#L140
>>>
>>> Thanks,
>>> Thishani
>>>
>>> On Wed, May 9, 2018 at 5:48 AM, Riyafa Abdul Hameed 
>>> wrote:
>>>
 Hi,

 Which version of ESB/EI are you using?

 Regards,
 Riyafa

 On Tue, 8 May 2018, 20:11 Fernandes, Norberto, <
 nfern...@jaguarlandrover.com> wrote:

> Hi team,
>
> I have a proxy that is sending data using the vfs transport and ftp
> protocol.
> I have this logging when I enable the logging.
>
> TID: [-1234] [] [2018-05-08 15:11:18,818] DEBUG
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo} -  Using the
> fileURI: ftp://userQA:pas...@10.xxx.xx.
> XXX/QA/AXES/XXion_Test.csv?transport.v
>
> fs.ReconnectTimeout=10=5
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo}
>
> TID: [-1234] [] [2018-05-08 15:11:18,818] DEBUG
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo} -  Using the
> maxRetryCount  : 5 {org.apache.synapse.commons.
> vfs.VFSOutTransportInfo}
>
> TID: [-1234] [] [2018-05-08 15:11:18,818] DEBUG
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo} -  Using the
> reconnectionTimeout : 1 {org.apache.synapse.commons.
> vfs.VFSOutTransportInfo}
>
> TID: [-1234] [] [2018-05-08 15:11:18,819] DEBUG
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo} -  Using the
> append : false {org.apache.synapse.commons.
> vfs.VFSOutTransportInfo}
>
> TID: [-1234] [] [2018-05-08 15:11:18,819] DEBUG
> {org.apache.synapse.commons.vfs.VFSOutTransportInfo} -  File locking
>   : OFF {org.apache.synapse.commons.vfs.VFSOutTransportInfo}
>
> TID: [-1234] [] [2018-05-08 15:11:18,819]  WARN
> {org.apache.commons.vfs2.provider.ftp.FtpClientFactory$FtpConnectionFactory}
> -  Invalid connection timeout null. Set the connectionTimeout as
> 5000. (default) {org.apache.com
>
> mons.vfs2.provider.ftp.FtpClientFactory$FtpConnectionFactory}
>
> TID: [-1234] [] [2018-05-08 15:11:18,819]  WARN
> {org.apache.commons.vfs2.provider.ftp.FtpClientFactory$FtpConnectionFactory}
> -  Invalid connection retry count null. Set the connectionRetryCount
> as 5. (default) {org.apache
>
> .commons.vfs2.provider.ftp.FtpClientFactory$FtpConnectionFactory}
>
>
> I have the RecoonectTimeout and the MaxRetryCount settings defined.
> But the apache commons vfs class indicates that the connection timeout and
> retry count is not defined.
>
> How can I defined these parameters?
>
> Regards,
> Norberto
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Regards,
>>>
>>> *Thishani Lucas*
>>> *Software Engineer*
>>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>>> *lean.enterprise.middle-ware*
>>>
>>> *Tel: +94 77 2556931 *
>>>
>>> *LinkedIn:

Re: [Dev] Retry with authenticators for adaptive authentication.

2018-05-14 Thread Maduranga Siriwardena

After trying several methods to implement a retry mechanism, we decided to
go for below approach.

Authentication framework will not prompt for retrying unless it is
specifically written in the script. So if we want to retry the
authentication, the conditional authentication script would be like below.

function onInitialRequest(context) {
retryCount = 3;
executeBasicAuth(context, retryCount);
}

function executeBasicAuth(context, retryCount) {
   Log.info('--- executeBasicAuth retryCount ' + retryCount);
   executeStep({
   id: '1',
   on: {
   success: function (context) {
   Log.info('--- authentication succcessfull ');
   var isAdmin = hasRole(context, 'admin');
   Log.info('--- Has Admin ' + isAdmin);
   if (isAdmin) {
   executeStep({id: '2'});
   }
   },
   fail: function (context) {
Log.info('--- fail retryCount ' + retryCount);
--retryCount;
if (retryCount > 0) {
executeBasicAuth(context, retryCount);
} else {
Log.info('--- login failed ');
}
   }
   }
   });
}


This script will try to authenticate the user 3 times in case credentials
are incorrect. This approach will ensure that the authentication flow is
strictly controlled by the script and there is no unnecessary/unwanted
behavior.

But with this approach we have a issue with how to get the authentication
failure reason in case of a retrying step. At the moment in the basic
authenticator, this failure message is set by checking
"context.isRetrying()" [1]. With the new implementation, authentication
framework is not aware if this is a retrying step or not. We are trying to
find a solution for this. Any suggestions are welcome.

[1]
https://github.com/wso2-extensions/identity-local-auth-basicauth/blob/v5.3.7/components/org.wso2.carbon.identity.application.authenticator.basicauth/src/main/java/org/wso2/carbon/identity/application/authenticator/basicauth/BasicAuthenticator.java#L108

Thanks,
Maduranga.



On Tue, May 8, 2018 at 12:26 PM Maduranga Siriwardena 
wrote:

> Hi Gayan,
>
> Thanks for the suggestion.
>
> Yes its better to provide a configuration to change the number of retry
> attempts. Apart from the above mentioned behavior, we will consider this
> also in the implementation.
>
> Thanks,
>
> On Tue, May 8, 2018 at 9:31 AM gayan gunawardana 
> wrote:
>
>>
>>
>> On Mon, May 7, 2018 at 7:17 PM, Maduranga Siriwardena > > wrote:
>>
>>> Hi devs,
>>>
>>> In the Identity Server at the moment "retryAuthenticationEnabled" method
>>> in the authenticators decide whether the user is allowed to retry the
>>> authentication with that particular authenticator. Based on the result from
>>> this method, authenticator itself triggers the retry flow.
>>>
>>> Because of this we have a main disadvantage for the implementation of
>>> adaptive authentication. If retry is enabled, fail call back function in
>>> JavaScript is not triggered.
>>>
>>> So we are planning to change this behavior and send the authentication
>>> retry flow through the authentication framework. Below is the planned
>>> behavior.
>>>
>>>- Authenticator will retry to authenticate by default.
>>>- If the fail callback function has other steps to execute,
>>>authenticator will not retry to authenticate.
>>>- Developers can disable retry for a authentication sequence by
>>>setting a parameter in the context.
>>>
>>> Isn't it better to invoke fail callback function after pre-configured
>> number of retry attempts.
>>
>>> Please provide us with feedback what need to be changed from the above
>>> mentioned behavior.
>>>
>>> Thanks,
>>> --
>>> Maduranga Siriwardena
>>> Senior Software Engineer
>>> WSO2 Inc; http://wso2.com/
>>>
>>> Email: madura...@wso2.com
>>> Mobile: +94718990591
>>> Blog: *https://madurangasiriwardena.wordpress.com/
>>> *
>>> 
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Gayan
>>
>
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591
> Blog: *https://madurangasiriwardena.wordpress.com/
> *
> 
>


-- 
Maduranga Siriwardena
Senior Software Engineer
WSO2 Inc; http://wso2.com/

Email: madura...@wso2.com
Mobile: +94718990591
Blog: *https://madurangasiriwardena.wordpress.com/
*

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Retry with authenticators for adaptive authentication.

Re: [Dev] Retry with authenticators for adaptive authentication.

Re: [Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

Re: [Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

[Dev] Is wso2 developer studio 3.8.0 still useful for EI 6.2 and API manager 2.2?

Re: [Dev] ClassNotFoundException: org.wso2.carbon.webapp.mgt.filter.AuthorizationHeaderFilter

Re: [Dev] Update Binary attribute in Active directory via wso2 ldap Connector

[Dev] Problem with IE6 using WS-SecurityPolicy

Re: [Dev] VFS FTP connection timeout settings

Re: [Dev] Retry with authenticators for adaptive authentication.

10 matches

Site Navigation

Mail list logo

Footer information