I've recently updated Glassfish from 3.1.2 to 4.0 and wanted to set up a JDBCRealm that I used before on my app which uses FORM based authentication. The passwords are hashed with SHA-256 in the database (that is the default Digest Algorithm option).
The realm has a property that became mandatory in this Glassfish version: Password Encryption Algorithm. Quite incredibly, the official Glassfish documentation says it's optional, and the note under the input field says it is a risk to leave it empty, however you cannot leave it empty as it is mandatory.
I cannot log in in my app that was working before no matter what I set in this property. (This is true to both the newly registered and old users.) I was googling for days but couldn't find the options for this field. What are the options?
Also, I'm using Glassfish with MySQL. Does Glassfish send the hashed passwords encrypted to the DB or is it just some instruction to MySQL to store the hashed passwords with this kind of encryption?
This question helped me somewhat but didn't solve my problem.
UPDATE: Actually, I don't use the classic FORM based authentication, but a custom JSF form with programmatic login using HttpServletRequest#login(), but I don't think it matters in this issue.
I've tested a simple use case with Glassfish 4.1 and a JDBC Realm configured for MySQL.
You can set up a simple user table:
name: stores the username
password: stores the SHA-256 hash of the user's
password (without salting)
group: stores the user group (i.e. admin, user)
I.e.
INSERT INTO users (name, password, group) VALUES ("admin", SHA2("password", 256), "admins");
In the admin console, go to Configurations > Security > Realms and edit your realm.
In the "Password Encryption Algorithm" field enter "AES".
In the "Digest Algorithm" field enter "SHA-256".
In the "Charset" field enter "UTF-8".
Related
I'm switching over from a heroku addon to a direct redis cloud account and am a bit puzzled on how to generate the redis url with the auth info.
The old heroku add-on url was in the format of redis://rediscloud:mypassword#redis...
However in the dashboard and documentation I don't see any mention of a username to go along with the password. Do I still set rediscloud as the username in my new account and connection string. Does it even matter what I set as the username there?
I use golang (https://github.com/garyburd/redigo) and connect to aliyun cloud Redis (link: https://www.aliyun.com/product/kvstore?spm=5176.8006303.267657.7.cW2xH)
By the connect string:
redis://arbitrary_usrname:password#ipaddress:6379/0
when 0 is the database index and success
At the moment (up to and including v4), Redis doesn't support users and only provides authentication against a global password. In order to be compliant with the URI RFC (https://www.rfc-editor.org/rfc/rfc3986) and based on the provisional RFC for Redis URIs (https://www.iana.org/assignments/uri-schemes/prov/redis), you can pass anything as a username, including the empty string, and it will be okay (i.e. ignored).
P.S. thanks for bringing up this obscurity in our docs, I'll see that it is amended.
Version 6+ now supports users: https://redis.io/topics/acl
If you aren't using an Access Control List (ACL) for your instance (meaning you auth as the default user) or are using an older version of Redis, you should omit the username from your Redis URL (e.g., redis://rediscloud:mypassword#... → redis://:mypassword#...)
If you include a username like rediscloud in the URL and your instance doesn't have that user configured in your ACL, you will likely run into auth issues for WRONGPASSWORD errors as more Redis client libraries implement ACL support.
This format worked for me when SSL is required:
rediss://:password=#redis-server-url:6380/0?ssl_cert_reqs=CERT_REQUIRED'
An example is below:
CELERY_BROKER_URL='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/0?ssl_cert_reqs=CERT_REQUIRED'
CELERY_RESULT_BACKEND='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/1?ssl_cert_reqs=CERT_REQUIRED'
I opened a demo xsp page and a window popped up asking me to input the name and password to login to the domino server. Then I entered my own id and password created in domino, but it didn't work. Only the Administrator name and its password worked. Anybody knows what's the problem? I already edited the corresponding ACL entries.
Thanks!
In order to use a database in a browser (no matter if classic notes web development or Xpages) one needs to meet several requirements.
First of all you need access to all NSF files that are used in the process.
As mentioned by Richard you either need to be mentioned in the ACL (namely or by group membership, or by setting -Default- and/or Anonymous to a level greater than No access).
AND the ACL has to allow Web- Access by not setting the Maximum Internet Name and Password to No Access
But this is not enough.
To be able to do authentication you do not have an ID- file in the browser.
You need a username and password. This password is NOT the password of your ID- file unless the admins choose to synchronize them using a policy.
It is the password stored in your person document in the names.nsf on the server.
But still these points are not enough yet: If you have access to the server with your username and internet password (can be tested by just trying to login to http://yourServer/names.nsf?open&login), then you might still not be able to access the application if -as umeli pointed out in the comment- the signer of the Xpage- application does not have enough rights to sign the XPages (Server document - security).
You see: There is a lot stuff to check. But if all of these points are OK, then access to the database will not be a problem anymore.
I omitted one reason for not beeing able to login because of your error description: If the Session Authentication on your server is configured for Multiple Servers (SSO) then you need to use the fully qualified internet host name of the server in the URL (or at least a hostname, that contains the SSO- domain), otherwise you will be redirected to the loginpage over and over again, even after supplying the right username / password. But as you wrote about a "Window popping up" I am quite sure, that Session authentication on that server is set to "Disabled"
You could be being rejected because of the
ACL of the NSF file not having the level of access required for operations performed in the code on the Xpage. I know you said you edited the ACL, but bear in mind that access also depends on the 'Maximum Internet Name and Password' setting for the NSF.
ACL in other NSF files that are accessed in the code of the Xpage not having the level of access required for operations performed on it by the code. This also includes the 'Maximum Internet Name and Password' setting.
I have this problem:
I have enabled Liferay to import and export users from/to OpenLDAP server.
When I create a user in Liferay I obtain this page:
So, I have create a new user and Liferay has assigned to it a password (3zbPk6KA).
But.. if I try to login with new user (and generated password) I obtain the error message of incorrect credentials. In LDAP server I can see the new account but, the corresponding password seems to be different from that generated by Liferay..
In Java console i read this warning:
14:20:15,882 WARN [http-bio-8080-exec-6][LDAPAuth:208] Passwords do not match for userDN cn=myUser,ou=users,dc=myProject,dc=com
Some suggestions?
Had this problem too. what's your value for Ldap password policy and what's your liferay version ?
I think you have 2 options :
Disable Ldap password policy, and if your Liferay version has no bug on exporting new user's autogenerated passwords, Your scenario is supposed to work. Else, you'll have to create a patch/hook that sends that password to LDAP
Enable LDAP password policy, setup a fixed default LDAP password, and hook the login process, so that you inform the new registered user (Screen Message + validation email) on her initial password. Note that there's still a security issue here, because of the fixed password, as someone could create accounts for other users if he knows their e-mails and tries to register before them.
You have to unmark "required" in controlpanel→portal→configuration→autenticathion→LDAP to di
I don't know why that specific scenario doesn't work. I have used Liferay 6.1 and know there are a number of bugs with the LDAP function of version 6.1. The problem that I faced was that checking "Use LDAP Password Policy" resulted in a user being created without a password.
However, if your password is being created in Liferay, you can turn off the export in Liferay LDAP wizard and programmatically export users through a hook using Java LDAP look up. I had to do it and it fixed a number of similar issues for me.
The link is a below
http://abhirampal.com/2014/12/20/liferay-ldap-export-to-active-directory-disabled-user-bug/
I am trying to use hashing for a test case in tomcat-users.xml. (I plan on implementing a subclass of one of the Realm classes to do the real authentication with auditing, logging, etc.) I ran the command
$TOMCAT_HOME/bin/digest.sh -a sha secret
and got the result 'secret:e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4'. I pasted this into the
<user password="e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4" roles="test" username="tester"/>
line. I added the appropriate magic words to my web.xml to use DIGEST authentication for the servlet (role = test), but when I try logging in, I get a 401 error.
I "watched" the transactions with wireshark, and it seems the browser is sending all of the right responses.
Am I doing this right? It seems to me that the digest authentication will send back MD5("username:realm:password"), so there is no way for tomcat to compare the value stored in the tomcat-users.xml file with the value sent by the browser, since it would require either "unhashing" the password value from tomcat-users.xml or "username:realm:password".
Should I be storing the hash of "username:realm:password" instead?
Boy, that was a DUE (dumb user error)!
I should have read the tomcat docs more carefully:
If using digested passwords with DIGEST authentication, the cleartext used to generate the digest is different. In the examples above {cleartext-password} must be replaced with {username}:{realm}:{cleartext-password}. For example, in a development environment this might take the form testUser:localhost:8080:testPassword.
Exactly the last part of my own question :-).
I would like to use an LDAP server (probably Apache directory) to manage logins and credentials for an application. From time to time the application needs to work offline (on a laptop) without a connection to the LDAP server.
What is the best way to replicate the credentials localy?
I have already thought about:
Using Mitosis to replicate the LDAP server on the laptop.
But it would be a quite "heavy" and complicated solution. Moreover Mitosis seems not be be finished yet.
Exporting the credentials as LDIF file that could be stored on the laptop.
But I would need a way to check that the LDIF file actually comes from the LDAP server (The file should include a kind of signature). Moreover I would like to reject LDIF files that haven't be updated for more than a week. It would be nice if I could avoid implementing signing and age check myself.
Any other ideas or tools that could help me?
Edited Edit: I had a look at Kerberos because the documentation of the Java-Kerberos-API seems to say that it is possible to use a cached ticket in a local cache and I thought this might be a solution for me. Moreover Kerberos can be added as plugin to Apache Directory.
But the Kerberos cache stores decrypted tickets (aiming at sharing them with other applications). I would need the crypted version of the ticket to be able to check the user password during an offline session. Conclusion: Kerberos doesn't offer a simple solution to my problem.
Knowing that it will be probably ok if the user have to log on once online before being able to log on offline, consider the following algorithm:
user provides your application with a (username + password)
application attempts to contact LDAP for authentication
working online? (e.g. connection successful)
application authenticates against LDAP using (username + password)
authentication succesful?
application stores or updates hash(password) as (cached_credentials) for (username) into local secure storage
application proceeds as authenticated [[STOP]]
authentication failed?
application proceeds as non-authenticated (incorrect credentials) [[STOP]]
working offline? (e.g. network error)
application attempts retrieve (cached_credentials) for (username) from local secure storage
(cached_credentials) exists AND more recent than (1 week)?
application compares (cached_credentials) against hash(password)
match?
application proceeds as authenticated [[STOP]]
no match?
application proceeds as non-authenticated (incorrect credentials) [[STOP]]
(cached_credentials) does not exist OR less recent than (1 week)?
application proceeds as non-authenticated (network error) [[STOP]]
This is (or was, IIRC), by the way, the same model employed by Windows NT+ for user authentication against domain controllers. Upon login an attempt is made to authenticate against the domain controller and create or update the local (cached) version of the user profile. If the domain controller is not available, the user is prompted to proceed with authentication against the credentials captured in the local (cached) profile (if one exists.)
EDIT
Yes, this is, in spirit, the same solution as copying an ldif file locally, except that you do not have to parse ldif when you're offline. :)
It is understood that you can store any additional attributes (permissions, etc.) in your cache
It is also understood that 'secure storage' is at least signed. :) You can do this easily enough with a SHA-1 hash and a secret, or you can use full-fledged cryptographic providers available on your platform (or in Java, if using Java.) You do not need to crypt it as long as no secret information is stored inside.
Here is the solution I decided to use (I have already described it in an edit to my question, but I would like to able to accept an answer to "close" the question):
As I have not found another solution, I decided to use an LDIF export, add a timestamp as comment at the beginning of the file and then sign the file. To sign the file I calculate an hash value (SHA-1) of the file + a secret key. The signature is added as comment at the beginning of the file. To check the signature I remove the first line of the signed file and recalculate the hash value.