[jira] [Created] (RANGER-3673) Need to enable cipher configuration for Usersync

2022-03-20 Thread Vishal Suvagia (Jira) 
Vishal Suvagia created RANGER-3673:
--

 Summary: Need to enable cipher configuration  for Usersync
 Key: RANGER-3673
 URL: https://issues.apache.org/jira/browse/RANGER-3673
 Project: Ranger
  Issue Type: Improvement
  Components: usersync
Affects Versions: 2.2.0, 3.0.0
Reporter: Vishal Suvagia
Assignee: Vishal Suvagia


Ranger Usersync supports enabling for TLS, need to enable cipher suite 
configuration for same.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73898: RANGER-2362: Limit Login Attempt Failure

2022-03-20 Thread bhavik patel 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73898/#review224182
---



we have to check the successive login failure with in 30min, so default login 
lockout window time should be updated to "1800" sec

- bhavik patel


On March 21, 2022, 3:10 a.m., Kirby Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73898/
> ---
> 
> (Updated March 21, 2022, 3:10 a.m.)
> 
> 
> Review request for ranger, Bhavik Bavishi, Abhay Kulkarni, Madhan Neethiraj, 
> and Pradeep Agrawal.
> 
> 
> Bugs: RANGER-2362
> https://issues.apache.org/jira/browse/RANGER-2362
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RANGER-2362
> 
> 
> Here is a simple demo code for discussion.
> 
> Hard-codeed:
> we limit 3 failures per 30 minutes. A successful login will reset the counter.
> 
> 
> BTW: I think the code of RangerAuthenticationProvider is a bit anti-pattern.
> 
> 1. We new RangerAuthenticationProvider at each time user login. It is 
> unreasonable, it should be a bean.
> 
> see RangerKRBAuthenticationFilter.java and RangerSSOAuthenticationFilter.java
> 
> 2. We new Jdbc/AD/Ldap/Pam authentication provider in 
> RangerAuthenticationProvider at each time user login.
> 
> 3. The member 'private LdapAuthenticator authenticator' seems useless
> 
> 4. The RangerAuthenticationProvider seem should be replaced with 
> ProviderManager or something like spring configuration.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java 
> 6b002cff994dd431a83ef46f10ee839fb83dafbb 
>   security-admin/src/main/java/org/apache/ranger/db/XXAuthSessionDao.java 
> b0270e9d45aa5b5543735318eea4e22683cbfece 
>   
> security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java
>  8f7abbe7df3d0344c7b5b1af89f7322d82a0d238 
>   
> security-admin/src/main/java/org/apache/ranger/security/listener/SpringEventListener.java
>  af5622a5f756db931a7173ad01d8c4162d5ee05a 
>   security-admin/src/main/resources/META-INF/jpa_named_queries.xml 
> b56cd26751b35aef245483ef903768d9a9ece61d 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> 2471f6ac0b5cce97e98a28dd7f1f8faee171f02e 
> 
> 
> Diff: https://reviews.apache.org/r/73898/diff/3/
> 
> 
> Testing
> ---
> 
> Self tested
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>

[jira] [Assigned] (RANGER-2362) [security] Admin webui - Lack of account lockout

2022-03-20 Thread Madhan Neethiraj (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Madhan Neethiraj reassigned RANGER-2362:


Assignee: kirby zhou

> [security] Admin webui - Lack of account lockout
> 
>
> Key: RANGER-2362
> URL: https://issues.apache.org/jira/browse/RANGER-2362
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Affects Versions: 1.0.0
>Reporter: t oo
>Assignee: kirby zhou
>Priority: Major
>
> |Account lockout is a mechanism used to stop non-valid users from guessing 
> for the right password. It is also a protection against brute force attacks 
> wherein an automated system can use common/dictionary passwords or even build 
> passwords based on set of characters just to try to guess the valid one.|
> |The application does not implement an account lockout mechanism, leaving it 
> susceptible to brute force attacks. These login pages were susceptible to 
> this condition.|
> |It is possible for an attacker to use dictionary or brute force attacks and 
> set it to attempt sending the requests on a particular amount of time to 
> bypass the validation. Once a username has been correctly guessed, the 
> attacker may then be able to gain access to the application. Since it is 
> vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the 
> email addresses easier to guess, it will make brute force attack to more 
> likely possible.
> |Enforce account lockout conditions to prevent intrusions and improve 
> password requirements and complexities to avoid the chances of brute force 
> and dictionary attacks from working.|
> |



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73898: RANGER-2362: Limit Login Attempt Failure

2022-03-20 Thread Madhan Neethiraj 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73898/#review224181
---


Ship it!




Ship It!

- Madhan Neethiraj


On March 21, 2022, 3:10 a.m., Kirby Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/73898/
> ---
> 
> (Updated March 21, 2022, 3:10 a.m.)
> 
> 
> Review request for ranger, Bhavik Bavishi, Abhay Kulkarni, Madhan Neethiraj, 
> and Pradeep Agrawal.
> 
> 
> Bugs: RANGER-2362
> https://issues.apache.org/jira/browse/RANGER-2362
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RANGER-2362
> 
> 
> Here is a simple demo code for discussion.
> 
> Hard-codeed:
> we limit 3 failures per 30 minutes. A successful login will reset the counter.
> 
> 
> BTW: I think the code of RangerAuthenticationProvider is a bit anti-pattern.
> 
> 1. We new RangerAuthenticationProvider at each time user login. It is 
> unreasonable, it should be a bean.
> 
> see RangerKRBAuthenticationFilter.java and RangerSSOAuthenticationFilter.java
> 
> 2. We new Jdbc/AD/Ldap/Pam authentication provider in 
> RangerAuthenticationProvider at each time user login.
> 
> 3. The member 'private LdapAuthenticator authenticator' seems useless
> 
> 4. The RangerAuthenticationProvider seem should be replaced with 
> ProviderManager or something like spring configuration.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java 
> 6b002cff994dd431a83ef46f10ee839fb83dafbb 
>   security-admin/src/main/java/org/apache/ranger/db/XXAuthSessionDao.java 
> b0270e9d45aa5b5543735318eea4e22683cbfece 
>   
> security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java
>  8f7abbe7df3d0344c7b5b1af89f7322d82a0d238 
>   
> security-admin/src/main/java/org/apache/ranger/security/listener/SpringEventListener.java
>  af5622a5f756db931a7173ad01d8c4162d5ee05a 
>   security-admin/src/main/resources/META-INF/jpa_named_queries.xml 
> b56cd26751b35aef245483ef903768d9a9ece61d 
>   security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
> 2471f6ac0b5cce97e98a28dd7f1f8faee171f02e 
> 
> 
> Diff: https://reviews.apache.org/r/73898/diff/3/
> 
> 
> Testing
> ---
> 
> Self tested
> 
> 
> Thanks,
> 
> Kirby Zhou
> 
>

[jira] [Updated] (RANGER-3672) Show better error messages during failed logins

2022-03-20 Thread kirby zhou (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

kirby zhou updated RANGER-3672:
---
Attachment: 截屏2022-03-21 12.07.03.jpg

> Show better error messages during failed logins
> ---
>
> Key: RANGER-3672
> URL: https://issues.apache.org/jira/browse/RANGER-3672
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: 3.0.0, 2.3.0
>Reporter: kirby zhou
>Priority: Critical
> Attachments: 截屏2022-03-21 12.07.03.jpg
>
>
> When login failure, There are no conspicuous error tips and reasons, just a 
> small red triangle. Should give user a big error prompt box, tell him "The 
> username or password you entered is incorrect..", "The user is disabled or 
> locked for too many attempts. Try again 5 minutes later".
>  
> It seems RANGER-375 did some works before. But I can not see the text message 
> now.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (RANGER-3672) Show better error messages during failed logins

2022-03-20 Thread kirby zhou (Jira) 
kirby zhou created RANGER-3672:
--

 Summary: Show better error messages during failed logins
 Key: RANGER-3672
 URL: https://issues.apache.org/jira/browse/RANGER-3672
 Project: Ranger
  Issue Type: Improvement
  Components: admin
Affects Versions: 3.0.0, 2.3.0
Reporter: kirby zhou


When login failure, There are no conspicuous error tips and reasons, just a 
small red triangle. Should give user a big error prompt box, tell him "The 
username or password you entered is incorrect..", "The user is disabled or 
locked for too many attempts. Try again 5 minutes later".

 

It seems RANGER-375 did some works before. But I can not see the text message 
now.

 

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (RANGER-3619) REST API should return 403 when authenticated client is not allowed to access API.

2022-03-20 Thread kirby zhou (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509579#comment-17509579
 ] 

kirby zhou commented on RANGER-3619:


[~bhavikpatel]
[~mad...@apache.org]   
[~pradeepagrawal8184] 
[~abhayk] 
 
Hi, any idea?
 
 

> REST API should return 403 when authenticated client is not allowed to access 
> API.
> --
>
> Key: RANGER-3619
> URL: https://issues.apache.org/jira/browse/RANGER-3619
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 3.0.0, 2.2.0
>Reporter: kirby zhou
>Priority: Major
>
> REST API should return 403-Forbidden when authenticated client is not allowed 
> to access API to avoid crash Ranger Clients.
>  
> Now, some API returns 401-Unauthorized instead of 403-Forbidden when client 
> is already passed authentication but now allowed to do something.
> In general, this will not cause any serious problems. However, there is a 
> flaw in the SPNEGO protocol implementation of Java HTTPUrlConnection. It 
> causes the Client to throw an unexpected exception. This will trouble the 
> operators and developers.
>  
> Let me show you how it happens:
>  
> For example:
>  
> The RangerAdminClient inside KMS  want to access API 
> "/service/secure/policies/download", but the principal is not in the 
> allowlist.
>  
>  # RangerAdminClient is based on Jersey-Client
>  # JerseyClient sends a HTTP-request to Ranger Service without authentication 
> information
>  # Tomcat/Spring inside Ranger returns 401 with HTTP header 
> “WWW-Authentication: Neogotiate”
>  # JerseyClient sends request again with Kerberos/SPNEGO authentication 
> tokens.
>  # Tomcat/Spring inside Ranger accept the authentication, then call 
> ServiceRest::getSecureServicePoliciesIfUpdated to reply the API calling.
>  # ServiceRest::getSecureServicePoliciesIfUpdated checks allowlist of “kms 
> service”, and refuse client with 401.
>  # Tomcat/Spring inside Ranger returns 401 with HTTP header 
> “WWW-Authentication: Neogotiate….” for notifying RangerAdminClient the 
> authentication is passed.
>  
> Now, there is a malformed state. HTTP-status code told client authenticate is 
> failed, but HTTP header told client authentication is passed.
>  
> In the RangerAdminClient side, 
>  
>  # sun.net.www.protocol.http.HttpURLConnection.getInputStream0() see the 
> second 401.
>  # 'inNegotiate' = true, so it is in the progress of _Negotiate._
>  # It checks that: if "WWW-Authenticate: Negotiate" exist then disable 
> negotiate for following code to avoid try {_}Negotiate once again{_}.
>  # But "WWW-Authenticate: Negotiate xczsd324…" does not the rule above.
>  # So HttpURLConnection calls AuthenticationInfo.sendHeaders to generate a 
> new request header.
>  # Wow, Null exception happens.
>  # Logs "ERROR RangerAdminRESTClient - Error getting policies; Received NULL 
> response!!. secureMode=true, user=… (auth:KERBEROS), serviceName=kmsdev"
>  # Log of KMS: "ERROR RangerAdminRESTClient - Failed to get response, Error 
> is : java.lang.RuntimeException: java.lang.NullPointerException"
>  
> This log makes admin confused.
>  
>  
> {code:java}
> //ServiceRest::getServicePoliciesIfUpdated
> if (isAllowed) {
> //...
> } else {
>httpCode = HttpServletResponse.SC_UNAUTHORIZED;
> }
>  {code}
> {code:java}
> // sun.net.www.protocol.http.HttpURLConnection.getInputStream0()
> // Read comments labeled "Failed Negotiate" for details.
> boolean dontUseNegotiate = false;
> Iterator iter = responses.multiValueIterator("WWW-Authenticate");
> while (iter.hasNext()) {
> String value = iter.next().trim();
> if (value.equalsIgnoreCase("Negotiate") ||
> value.equalsIgnoreCase("Kerberos")) {
> if (!inNegotiate) {
> inNegotiate = true;
> } else {
> dontUseNegotiate = true;
> doingNTLM2ndStage = false;
> serverAuthentication = null;
> }
> break;
> }
> }
> /**
>  * Failed Negotiate
>  *
>  * In some cases, the Negotiate auth is supported for the
>  * remote host but the negotiate process still fails (For
>  * example, if the web page is located on a backend server
>  * and delegation is needed but fails). The authentication
>  * process will start again, and we need to detect this
>  * kind of failure and do proper fallback (say, to NTLM).
>  *
>  * In order to achieve this, the inNegotiate flag is set
>  * when the first negotiate challenge is met (and reset
>  * if authentication is finished). If a fresh new negotiate
>  * challenge (no parameter) is found while inNegotiate is
>  * set, we know there's a failed auth attempt recently.
>  * Here we'll ignore the header line so that fallback
>  * can be practiced.
>  *
>  * inNegotiateProxy is for proxy

[jira] [Commented] (RANGER-3611) Uncatched NullPointerException when missing lastKnownVersion in ServiceREST::getServicePoliciesIfUpdated

2022-03-20 Thread kirby zhou (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509574#comment-17509574
 ] 

kirby zhou commented on RANGER-3611:


Can it be committed?

> Uncatched NullPointerException when missing lastKnownVersion in 
> ServiceREST::getServicePoliciesIfUpdated
> 
>
> Key: RANGER-3611
> URL: https://issues.apache.org/jira/browse/RANGER-3611
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 2.2.0, 2.3.0
>Reporter: kirby zhou
>Priority: Minor
>
> A simple Rest API call by CURL will cause uncatched NullPointerException in 
> logs.
> Actual:
>  
> {code:java}
> ]% curl -v http://localhost:6080/service/plugins/policies/download/hdfsdev
> ... 
> < HTTP/1.1 404 Not Found
> ...
>  No Message here 
> * Closing connection 0 {code}
>  
> And logs in catalina.out
> {code:java}
> EVERE: Servlet.service() for servlet [REST Service] in context with path [] 
> threw exception
> java.lang.NullPointerException
>   at 
> org.apache.ranger.rest.ServiceREST.getServicePoliciesIfUpdated(ServiceREST.java:3054)
>   at 
> org.apache.ranger.rest.ServiceREST$$FastClassBySpringCGLIB$$92dab672.invoke()
>   at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:779)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
>   at 
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>   at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750)
>   at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:692)
>   at 
> org.apache.ranger.rest.ServiceREST$$EnhancerBySpringCGLIB$$43bccb60.getServicePoliciesIfUpdated()
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>   at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>   at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>   at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>   at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>   at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>   at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
>   at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:232)
>   at 
>

[jira] [Commented] (RANGER-2362) [security] Admin webui - Lack of account lockout

2022-03-20 Thread kirby zhou (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509573#comment-17509573
 ] 

kirby zhou commented on RANGER-2362:


Default Settings of patch:

security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml

 
{code:java}


   
  ranger.admin.login.autolock.enabled
  true
   
   
  ranger.admin.login.autolock.window.seconds
  300
   
   
  ranger.admin.login.autolock.maxfailure
  5
   
 {code}

> [security] Admin webui - Lack of account lockout
> 
>
> Key: RANGER-2362
> URL: https://issues.apache.org/jira/browse/RANGER-2362
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Affects Versions: 1.0.0
>Reporter: t oo
>Priority: Major
>
> |Account lockout is a mechanism used to stop non-valid users from guessing 
> for the right password. It is also a protection against brute force attacks 
> wherein an automated system can use common/dictionary passwords or even build 
> passwords based on set of characters just to try to guess the valid one.|
> |The application does not implement an account lockout mechanism, leaving it 
> susceptible to brute force attacks. These login pages were susceptible to 
> this condition.|
> |It is possible for an attacker to use dictionary or brute force attacks and 
> set it to attempt sending the requests on a particular amount of time to 
> bypass the validation. Once a username has been correctly guessed, the 
> attacker may then be able to gain access to the application. Since it is 
> vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the 
> email addresses easier to guess, it will make brute force attack to more 
> likely possible.
> |Enforce account lockout conditions to prevent intrusions and improve 
> password requirements and complexities to avoid the chances of brute force 
> and dictionary attacks from working.|
> |



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Review Request 73898: RANGER-2362: Limit Login Attempt Failure

2022-03-20 Thread Kirby Zhou 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73898/
---

(Updated 三月 21, 2022, 3:10 a.m.)


Review request for ranger, Bhavik Bavishi, Abhay Kulkarni, Madhan Neethiraj, 
and Pradeep Agrawal.


Bugs: RANGER-2362
https://issues.apache.org/jira/browse/RANGER-2362


Repository: ranger


Description
---

RANGER-2362


Here is a simple demo code for discussion.

Hard-codeed:
we limit 3 failures per 30 minutes. A successful login will reset the counter.


BTW: I think the code of RangerAuthenticationProvider is a bit anti-pattern.

1. We new RangerAuthenticationProvider at each time user login. It is 
unreasonable, it should be a bean.

see RangerKRBAuthenticationFilter.java and RangerSSOAuthenticationFilter.java

2. We new Jdbc/AD/Ldap/Pam authentication provider in 
RangerAuthenticationProvider at each time user login.

3. The member 'private LdapAuthenticator authenticator' seems useless

4. The RangerAuthenticationProvider seem should be replaced with 
ProviderManager or something like spring configuration.


Diffs (updated)
-

  security-admin/src/main/java/org/apache/ranger/biz/SessionMgr.java 
6b002cff994dd431a83ef46f10ee839fb83dafbb 
  security-admin/src/main/java/org/apache/ranger/db/XXAuthSessionDao.java 
b0270e9d45aa5b5543735318eea4e22683cbfece 
  
security-admin/src/main/java/org/apache/ranger/security/handler/RangerAuthenticationProvider.java
 8f7abbe7df3d0344c7b5b1af89f7322d82a0d238 
  
security-admin/src/main/java/org/apache/ranger/security/listener/SpringEventListener.java
 af5622a5f756db931a7173ad01d8c4162d5ee05a 
  security-admin/src/main/resources/META-INF/jpa_named_queries.xml 
b56cd26751b35aef245483ef903768d9a9ece61d 
  security-admin/src/main/resources/conf.dist/ranger-admin-default-site.xml 
2471f6ac0b5cce97e98a28dd7f1f8faee171f02e 


Diff: https://reviews.apache.org/r/73898/diff/3/

Changes: https://reviews.apache.org/r/73898/diff/2-3/


Testing
---

Self tested


Thanks,

Kirby Zhou

Re: Review Request 73898: RANGER-2362: Limit Login Attempt Failure

2022-03-20 Thread Madhan Neethiraj 


> On March 18, 2022, 6:51 a.m., Madhan Neethiraj wrote:
> > security-admin/src/main/java/org/apache/ranger/db/XXAuthSessionDao.java
> > Lines 71 (patched)
> > 
> >
> > This will result in 2 queries for each login attempt:
> >  1. to get the last successful login time
> >  2. to get number of failed login since last successful login
> > 
> > Consider following to use only one query where possible:
> > 
> > public boolean shouldLockUserLogin(String loginId, int seconds, int 
> > maxFailedLoginsBeforeLock) {
> >   boolean ret   = false;
> >   DatestartTime = new Date(DateUtil.getUTCDate().getTime() 
> > - seconds * 1000);
> >   int numOfFailedLogins = getFailedLoginsCountForUserSince(loginId, 
> > startTime);
> >   
> >   if (numOfFailedLogins >= maxFailedLoginsBeforeLock) {
> > Date lastSuccessLoginTime = 
> > getLastSuccessfulLoginTimeSince(loginId, startTime);
> > 
> > if (lastSuccessLoginTime != null) {
> >   numOfFailedLogins = getFailedLoginsCountForUser(loginId, 
> > lastSuccessLoginTime);
> >   
> >   ret = numOfFailedLogins >= maxFailedLoginsBeforeLock;
> > }
> >   }
> >   
> >   return ret;
> > }
> 
> Kirby Zhou wrote:
> ```
>   return getEntityManager()
>   .createQuery("SELECT count(1) FROM 
> XXAuthSession obj" +
>   "   WHERE obj.loginId = 
> :loginId" +
>   " AND obj.createTime > (" +
>   "SELECT 
> max(obj2.createTime) FROM XXAuthSession obj2" +
>   "  WHERE obj2.loginId = 
> :loginId )" +
>   "AND 
> obj2.authStatus = 1 )" +
>   " AND obj.authStatus != 1", 
> Long.class)
>   .setParameter("authWindowStartTime", 
> authWindowStartTime)
>   .setParameter("loginId", loginId)
>   .getSingleResult();
> 
> ```
> 
> How about ?
> 
> Kirby Zhou wrote:
> Sorry for paste error.
> 
> ```
>   .createQuery("SELECT count(1) FROM 
> XXAuthSession obj" +
>   "   WHERE obj.loginId = 
> :loginId" +
>   " AND obj.createTime > 
> :authWindowStartTime" +
>   " AND obj.createTime > (" +
>   "SELECT 
> max(obj2.createTime) FROM XXAuthSession obj2" +
>   "  WHERE obj2.loginId = 
> :loginId " +
>   "AND 
> obj2.authStatus = 1 )" +
>   " AND obj.authStatus != 1", 
> Long.class)
>   .setParameter("authWindowStartTime", 
> authWindowStartTime)
>   .setParameter("loginId", loginId)
>   .getSingleResult();
> ```
> 
> Madhan Neethiraj wrote:
> Does this work when the inner query returns null i.e. when there are now 
> successful logins for the user?
> 
> Kirby Zhou wrote:
> Good Point!
> ```
>   .createQuery("SELECT count(1) FROM 
> XXAuthSession obj" +
>   "   WHERE obj.loginId = 
> :loginId" +
>   " AND obj.createTime > 
> :authWindowStartTime" +
>   " AND obj.createTime > 
> COALESCE(" +
>   "(SELECT 
> max(obj2.createTime) FROM XXAuthSession obj2" +
>   "   WHERE obj2.loginId 
> = :loginId " +
>   " AND 
> obj2.authStatus = 1)," +
>   "1)" +
>   " AND obj.authStatus != 1", 
> Long.class)
> 
> ```

That works!

Here is a slightly better version, as this restricts the query inside 
COALESCE() to look for logins only after authWindowStartTime.

SELECT COUNT(1) FROM XXAuthSession obj
 WHERE obj.loginId= :loginId
   AND obj.authStatus = 1
   AND obj.createTime > COALESCE((SELECT MAX(obj2.createTime) FROM XAuthSession 
obj2
   WHERE obj2.loginId= :loginId
 AND obj2.authStatus = 1
 AND obj2.createTime > 
:authWindowStartTime),

[jira] [Commented] (RANGER-3647) Connection to DB fails for MySQL version above 8.0

2022-03-20 Thread gomathinayagam (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509530#comment-17509530
 ] 

gomathinayagam commented on RANGER-3647:


what is the steps to apply patch

> Connection to DB fails for MySQL version above 8.0
> --
>
> Key: RANGER-3647
> URL: https://issues.apache.org/jira/browse/RANGER-3647
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: 3.0.0
>Reporter: Vishal Suvagia
>Assignee: Vishal Suvagia
>Priority: Major
> Attachments: RANGER-3647-01.patch, RANGER-3647.patch
>
>
> Observed that Ranger DB setup fails when using with MySQL version above 8.0.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)