Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: LDAP authentication and new users
I am in the process of modifying my current portal to do three things in a new way:
I have been able to get the LDAP authentication working. I have the value from AD being added as a custom field. And, I have logic that will assign roles at login to the user based on the value from the LDAP/AD process. However, I have only been able to do that when the user has already been created in the DB. So, if I cannot do this all in memory without persisting the user and roles in the DB, how should I handle a brand new user that has never signed in before but is a legitimate user as authenticated in LDAP? My first attempt at trying a new user generated this response:
Can a user be completely ephemeral? That is, not persisted in the DB? I am think that you cannot have a user that hasn't been persisted based on what I see, but could someone confirm that?
- Authenticate users using LDAP (Active Directory)
- Use a value from the LDAP/AD process as a custom user field (OU is what I am currently using because it basically identifies the department)
- Assign roles based on the value returned by the LDAP/AD process
I have been able to get the LDAP authentication working. I have the value from AD being added as a custom field. And, I have logic that will assign roles at login to the user based on the value from the LDAP/AD process. However, I have only been able to do that when the user has already been created in the DB. So, if I cannot do this all in memory without persisting the user and roles in the DB, how should I handle a brand new user that has never signed in before but is a legitimate user as authenticated in LDAP? My first attempt at trying a new user generated this response:
WARN [http-nio-8080-exec-9][SecurityPortletContainerWrapper:348] User 0 is not allowed to access URL [url=http://localhost:8080/web/guest/welcome and portlet com_liferay_login_web_portlet_LoginPortlet]http://localhost:8080/web/guest/welcome and portlet com_liferay_login_web_portlet_LoginPortlet[/url]
Searching on the warning produces several unrelated causes and solutions, so I am not sure if I have a configuration issue or just bad assumptions and logic in my code. Assuming that a completely ephemeral user isn't possible, what would be the suggest way to handle the following:UPDATE: The warning was a red herring and all of what I described above DOES work. So, the only question in all of this that is unanswered is:I am most of the way there. I think I just need help or a better understanding of what is going on when a user authenticates with LDAP and that user is not in the DB....
- Authenticate the user using LDAP
- Add the user and the custom field data to the DB
- Assign roles to the user
- Access the portal and menus based on the role assignments
Can a user be completely ephemeral? That is, not persisted in the DB? I am think that you cannot have a user that hasn't been persisted based on what I see, but could someone confirm that?
Pete Helgren:
Correct assumption.
UPDATE: The warning was a red herring and all of what I described above DOES work. So, the only question in all of this that is unanswered is:
Can a user be completely ephemeral? That is, not persisted in the DB? I am think that you cannot have a user that hasn't been persisted based on what I see, but could someone confirm that?
Background: Liferay will need user information even if LDAP is currently not available, or if a user has been renamed/removed in LDAP. E.g. in order to show the author, with name, profile picture and job description in a directory, as blog- or forum-post-author. Or as the creator of another asset. That's when the database steps in, thus the user information always will be copied into the database.
However, this copy happens at least during log in of a user, so that you can be sure the information isn't stale for any logged in user. You can also update user information based on a schedule, but typically this is not too interesting. At the time of login, the information is guaranteed to be most up-to-date, and that's when it's updated anyways.
Thanks Olaf. Just what I figured but not what I hoped. I am going to go with the approach I am using. It seems to work OK and over time I can refine it if I run into issues.
I really appreciate the confirmation.
I really appreciate the confirmation.
The only problem we usually have is when users are deleted/moved away (in another tree) in ldap. The user in Liferay is still there and while it might not be able to authenticate, it will still be visible/available. e.g. in the search or in applications.
Please note that this might not be an issue for you at all. It depends on your usecases.
Anyway: We resolved that by implementing a daily job that checks if a user is gone and removes it in portal too.
Please note that this might not be an issue for you at all. It depends on your usecases.
Anyway: We resolved that by implementing a daily job that checks if a user is gone and removes it in portal too.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™