LDAP authentication and new users

RE: LDAP authentication and new users

2019-06-14T06:44:41Z

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.

RE: LDAP authentication and new users

2019-06-13T13:59:52Z

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.

RE: LDAP authentication and new users

2019-06-12T16:08:32Z

Pete Helgren:

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?

Correct assumption.
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.

LDAP authentication and new users

2019-06-12T14:44:36Z

I am in the process of modifying my current portal to do three things in a new way:

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

The "gotcha!" is that I would prefer this to be "ephemeral". That is, all of this is done in memory without persisting the user and roles in the DB. Why? Because the roles will constantly change as people move around in the organization and I am trying to avoid reading through the roles each time and determining which ones need to be removed if the position changes. So, first question is: Is this even possible?
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 &nbsp;[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:
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
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....

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?