Closed ChavanShweta closed 4 years ago
There is a symptom that looks the same with this problem. The EndPoint requesting login with the Security Database works the same as the LDAP account.
LDAP Auth Endpoint: user/login/ldap
There is a phenomenon that the above API operates in Security Database as well as in AD/LDAP. This also includes the currently released version of 2.7.0.
Hi
I have deployed OHDSI using the OHDSIonAWS templates and chose to use Atlas security. I created three users but none of them logs in. WebApi version is 2.7.2.
I've checked:
I set the log level to debut in log4j.xml and this is what I get:
2019-08-09 11:01:24.765 DEBUG http-nio-8080-exec-10 org.springframework.boot.web.filter.OrderedRequestContextFilter - - Bound request context to thread: org.apache.catalina.connector.RequestFacade@502c1f4b 2019-08-09 11:01:24.765 DEBUG http-nio-8080-exec-10 org.hibernate.engine.transaction.internal.TransactionImpl - - On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false 2019-08-09 11:01:24.765 DEBUG http-nio-8080-exec-10 org.hibernate.engine.transaction.internal.TransactionImpl - - begin 2019-08-09 11:01:24.805 DEBUG http-nio-8080-exec-10 org.hibernate.engine.transaction.internal.TransactionImpl - - committing 2019-08-09 11:01:24.808 WARN http-nio-8080-exec-10 org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder - - Encoded password does not look like BCrypt 2019-08-09 11:01:24.809 DEBUG http-nio-8080-exec-10 org.springframework.ldap.core.support.AbstractContextSource - - Not using LDAP pooling 2019-08-09 11:01:24.809 DEBUG http-nio-8080-exec-10 org.springframework.ldap.core.support.AbstractContextSource - - Trying provider Urls: /CN=Users,DC=example,DC=org 2019-08-09 11:01:24.810 DEBUG http-nio-8080-exec-10 org.springframework.beans.factory.support.DefaultListableBeanFactory - - Returning cached instance of singleton bean 'loggingService' 2019-08-09 11:01:24.810 INFO http-nio-8080-exec-10 com.odysseusinc.logging.LoggingService - - Log in failed for user login = cdamien 2019-08-09 11:01:24.810 DEBUG http-nio-8080-exec-10 org.springframework.boot.web.filter.OrderedRequestContextFilter - - Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@502c1f4b
Not very clarifying, but may the references to LDAP there point to this issue?
configuration in application.properties:
security.db.datasource.driverClassName=org.postgresql.Driver security.db.datasource.url=jdbc:postgresql://ohdsi-poc-00-main-masterstack-147j82ky-rdscluster-1exzazstnbzsz.cluster-c8hailyuicky.us-east-2.rds.amazonaws.com:5432/OHDSI?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory security.db.datasource.username=ohdsi_security_user security.db.datasource.password=***** security.db.datasource.schema=authentication security.db.datasource.authenticationQuery=select password from authentication.security where email = ?
I run out of clues...
Password is retrieved (if I change it for a Bcrypt 12 passes value I see an error in the log saying it does not look like BCrypt. I reverted to the original value after that)
So the password should be stored in a format of Bcrypt hash. And it seems like you have reverted it to plain text. Do I get it right?
Well, that error happened when,. for troubleshooting purposes, I replaced the password value in the BD with one I generated using 12 passes instead of 4. After that I reverted to the original value and this is the log output:
2019-08-12 08:15:47.346 DEBUG http-nio-8080-exec-8 org.springframework.boot.web.filter.OrderedRequestContextFilter - - Bound request context to thread: org.apache.catalina.connector.RequestFacade@30d5f3e6 2019-08-12 08:15:47.347 DEBUG http-nio-8080-exec-8 org.hibernate.engine.transaction.internal.TransactionImpl - - On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false 2019-08-12 08:15:47.347 DEBUG http-nio-8080-exec-8 org.hibernate.engine.transaction.internal.TransactionImpl - - begin 2019-08-12 08:15:47.399 DEBUG http-nio-8080-exec-8 org.hibernate.engine.transaction.internal.TransactionImpl - - committing 2019-08-12 08:15:47.409 DEBUG http-nio-8080-exec-8 org.springframework.ldap.core.support.AbstractContextSource - - Not using LDAP pooling 2019-08-12 08:15:47.409 DEBUG http-nio-8080-exec-8 org.springframework.ldap.core.support.AbstractContextSource - - Trying provider Urls: /CN=Users,DC=example,DC=org 2019-08-12 08:15:47.410 DEBUG http-nio-8080-exec-8 org.springframework.beans.factory.support.DefaultListableBeanFactory - - Returning cached instance of singleton bean 'loggingService' 2019-08-12 08:15:47.410 INFO http-nio-8080-exec-8 com.odysseusinc.logging.LoggingService - - Log in failed for user login = cdamien 2019-08-12 08:15:47.411 DEBUG http-nio-8080-exec-8 org.springframework.boot.web.filter.OrderedRequestContextFilter - - Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@30d5f3e6
Using an external BCrypt tool to verify the value, it says that the hash does not match the password value:
Hash: $2a$04$MWNGG4KoQsZ3ZuN5axM/7.G5txgtQwRI8Cq5wiNIGPCjf8r5GwpkG Value: g%E%EWD6Fo
Regards
Regards
Found it. The OHDSIonAWS templates are using this command to generate the BCrypt Hash:
htpasswd -bnBC 4 "" g%E%EWD6Fo
It uses 4 passes, while the SpringFramework BCrypt implementation defaults to 10. Moreover, I believe that the Sprint BCrypt should be able to verify the hash whichever number of passes it was generated with, cause it is recorded in the hash itself after the second $ sign. Anyhow, generating a hash with 10 passes and updating the DB value with it did the trick.
I'm opening an issue at OHDSIonAWS
I also face this problem.
I think it is problem in "Encryption Processing in BCrypt"
In my Environment, Occurred this Error.
So temporary Solution I fixed java code. The java file directory is “WebAPI\src\main\java\org\ohdsi\webapi\AuthDataSource.java”.
It is fixed code.
It isn't Encrypt login. It just directly contact DB password.
I also face this problem. I think it is problem in "Encryption Processing in BCrypt" In my Environment, Occurred this Error.
So temporary Solution I fixed java code. The java file directory is “WebAPI\src\main\java\org\ohdsi\webapi\AuthDataSource.java”. It is fixed code.
It isn't Encrypt login. It just directly contact DB password.
You could just have used this command to generate the user password and leave the code unchanged:
python -c "import bcrypt; print(bcrypt.hashpw(\"$i\", bcrypt.gensalt(log_rounds=4)))"
Where $i contains the password value in plain text.
@anthonysena I have found one more case to reproduce this issue and I fixed it https://github.com/OHDSI/WebAPI/pull/1483
also, I upgraded shiro library and check that I did not break anything
I was successfully able to implement Basic Security. I was looking through the webapi logs i found following:
Even if the user is authenticated using the security database, webAPI keeps going in loop to authenticate user using LDAP.
Reference link: https://github.com/OHDSI/WebAPI/issues/1099#issuecomment-494829177 http://forums.ohdsi.org/t/atlas-webapi-authentication-setup-failing/6516/6?u=shweta