I am configuring Liferay with my organization LDAP.
1.While configuring LDAP, I specify "ldap.security.principal" and "ldap.security.credentials" as my user id and password to authenticate against LDAP and test connection succeeds.
Are these mandatory attributes? As in production ,I will not be able to specify my own credentials in portal-ext.properties. Do I need separate user created in LDAP to specify in portal-ext for production? I unfortunately do not have control over configuring LDAP as its an org LDAP.
Any pointers would help. Thanks.
There are several use-cases where you need privileged system account for accessing the LDAP database.
Authentication
There are two basic methods how you can authenticate against LDAP:
Do a BIND operation against LDAP - you need to know the user DN
Do a password attribute comparison - you need to know the user DN, name of attribute with the password, attribute value encoding (e.g. plaintext, hashed, ...)
For both approaches you need to know the distinguished name of the target user:
Either you are able to construct the DN from credentials (e.g. cn={screenName},ou=Users,o=MyOrg) - which is not supported by Liferay AFAIK;
or you need to do LDAP SEARCH to find the right user DN... for that you need to have a system account.
Account Import & Export
Next to pulling user information right when the user authenticates Liferay offers also LDAP import and export functionality. For obvious reasons you need to have a privileged system account to be able to search for users in LDAP and / or to write user entries.
TL;DR
Properties ldap.security.principal and ldap.security.credentials are mandatory (they can be configured also via user interface). You will need to have a dedicated system account for Liferay in the LDAP for this.
Related
In tomcat, I can setup security constraints that require certain resources to only be accessed by authorized users. The users are authenticated using either BASIC or FORM authentication, where a username and password is provided.
However, I'd also like to allow users to authenticate externally using an oauth provider. Is this possible?
Note that I can already pass all the information I need to acquire the access tokens for the user. From there I can get the username and other profile metadata.
But how do I then log the user into tomcat? The only way I can think to make this work is to take this username and create a tomcat account, maybe setting the access token as the password. Then I could do a tomcat login on behalf of the user, so she is locally authenticated. On subsequent logins I'd just update the password to the new access token.
But this seems like a hack, and when it comes to users and security I'd prefer to avoid hacks.
It looks like JASPIC might offer a solution for this? Unfortunately, it looks like it became available to tomcat starting at 8.5 but I'm stuck using 8.
Are there any other options?
Thanks!
I have setup LDAP authentication with liferay in my application.
I have kept LDAP enabled and required as true. This way only users with LDAP account would be able to login to portal.
ldap.auth.enabled=true
ldap.auth.required=true
Now I have requirement to create a local liferay group having certain users from LDAP (belonging to my team).
After LDAP authentication, this group would be checked if the user logging in is part of this group then only authentication would be allowed.
So basically I need two groups:
Team group (containing subset of LDAP)
Admin group (Subset of team and will be able to add/remove from team group)
I need help on achieving this.
The issue is, as my LDAP account do not have admin rights once I login to liferay, I do not see any administration options, and won't be able to create group.
Is there anyway I can map some of the LDAP accounts to admin accounts and how do I achieve this in production without doing required flag as false?
Thanks in advance!
If I understand your question well, you need to only grant some of your LDAP user login permission. There are several ways to achieve that :
Filter the users you synch with Liferay, by their DN, or by their LDAP group
Add a custom LoginPreAction event to deny login to certain users
To give users admin role, you can add your custom LoginPostAction, and give them the Administrator role if they meat the criterias
So, I'm writing a password verification thingy, loading username and passwords from a database, but I can't figure out how to keep the database username and password out of the code.
String user = "username";//database username, not username to verify
String password = "password";//my password, not users password to check
String url = "jdbc:mysql://databaseurl:3306/table";
//i want this hidden somehow
I could load it from a file, but then people could just read the file.
Obviously I don't want people gaining access to the database and reading secret information. How should I go about doing this?
EDIT: What I'm asking, is, how can I secure MY database credentials. Other people should not have access to the database
You could, for instance, decompile the jar and read the above lines, and access my database using my credentials. (using a program such as jd-gui)
Use password encryption.
If you application runs inside J2EE container, use standart tools
Look at sample for Jboss container
If you're going to give the user direct access to the database, why not just make the username/password you're passing to the database the user's actual username/database?
Typically in secure systems the database is not directly exposed to the user. The user passes a query to some system which then performs authentication and then if passes passes the query to the database.
In other words, if you're relying on the obscuring of the database login credentials as the obstruction to accessing the database, you're relying on the client to authenticate itself with respect to actually querying the database, which is a bad, bad idea. As soon as your database's login credentials are compromised, your whole security scheme has now failed.
You can keep database details in a
property file/database
. It is a kind of one layer of abstraction. And in that property file/database, you give some different keys so that at the time of accessing database, take the keys/columns from property file/database and construct url information.
Secure your authentication and authorization services using a PKI exchange with a properly signed certificate (so it can be revoked if something does go wrong, and it certainly may).
One example is ws-security (a SOAP extension), but if you need to use REST you're stuck with transport-level security (securing your connection with HTTPS).
You might want to read up at http://security.stackexchange.com for more insightful commentary, rather than "store it in a property file."
I am using Liferay 6.1 CE and I have the following issue related to the below blog
Ref: http://www.liferay.com/web/jonas.yuan/blog/-/blogs/6583930
I am trying to do LDAP auth and I am not supposed to import ldap user password and I would also like to use only ldap as auth source and not do liferay auth for second time.
These are my settings in portal-ext.properties:
ldap.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
ldap.referral=follow
ldap.base.provider.url=ldap://localhost:10389
ldap.base.dn=dc=example,dc=com
ldap.security.principal=uid=admin,ou=system
ldap.security.credentials=secret
auth.pipeline.enable.liferay.check=false
ldap.auth.enabled=true
ldap.auth.required=true
ldap.auth.method=bind
ldap.import.enabled=false
ldap.import.on.startup=false
ldap.import.interval=10
ldap.export.enabled=false
ldap.export.group.enabled=false
ldap.auth.search.filter=(mail=#email_address#)
ldap.user.mappings=screenName=cn\npassword=userPassword\nemailAddress=mail\nfirstName=givenName\nlastName=sn
ldap.user.custom.mappings=screenName=cn\npassword=userPassword\nemailAddress=mail\nfirstName=givenName\nlastName=sn
ldap.group.mappings=groupName=cn\ndescription=description\nuser=uniqueMember
ldap.import.user.search.filter=(objectClass=inetOrgPerson)
ldap.import.group.search.filter=(objectClass=groupOfUniqueNames)
ldap.password.policy.enabled=false
ldap.import.user.password.enabled=false
ldap.import.user.password.autogenerated=false
ldap.import.user.password.default=test
What is happening is , if I keep auth.pipeline.enable.liferay.check=false, then I am not able to login even using test#liferay.com user since he is not in ldap (others users also not able to login due to reason given in question 1 below). If I enable the property then the liferay does second validation after ldap and it fails since the password in ldap is different from the local dummy password(test) due to password not import setting.
Also, i have 2 separate questions.
When I load ldap props using this property file, then I can see it in the portalproperties table only after the test user logs in for the first time and goes to control panel (ldap page). If I don do this none of the other users able to do ldap auth (since the props file is not loaded to that portalproperties table)
Is there a way in liferay so that I can do only ldap auth and not create an liferay user
Almost two years late!! But in case that any other people find this thread, Liferay always passes the Auth Pipeline and , if passed, always checks the password again against its database unless
auth.pipeline.enable.liferay.check=false
In portal.properties . In that case, independently of the password stored in Liferay User_ table, the password would be checked only against the LDAP.
Sorry for being two years late!!
i have three active directory servers different address,port and domain name and all
In my app when user log-in the system i have to authenticate. The user provide his username and password only not the domain name or ip address.
How can i authenticate him, whether i have to loop through the all the ldap server and when i get the Context i have to break it .. or is any other possible solution is there for authenticate a user in multiple servers
please suggest. thanks in advance
If the user gives his FDN or UPN (User Principal Name) instead of just an user name it will be helpful. But still there is no guarantee that upn will match your realm name. If he gives FDN then atleast you can cache defaultNamingContext from all the three server and try to match it with the fdn provided by the user and authenticate him against the matching server.
But I guess he is providing the samAccountName in your case. In this case we dont have any clue to identify the server. You have to go through one by one and probably cache it which server he is authenticated against for next time performance improvment. Its also possible that the same username exist in multiple AD. You have to handle this case based on your AD environment.
as a additional note, if its web application try using spring's ldapTemplate. This might ease your task.