assign IP based role or alternative to ext-plugin in LR7

[Markus Krause, geändert vor 6 Jahren.]

Dear all,

I am using an ext-plugin with Liferay 6.1.2CE to assign a role to a (non-authenticated) user depending on the IP range he is coming from. We use this to completely hide our web content from users visiting our portal from the internet but showing some content to (non-authenticated) users who are in our campus LAN (or Wifi). This works quite well (I did that by creating a class which implements Filter to add a session attribute which in turn will be evaluated later in a class which extends the AdvancedPermissionChecker).

Now I am planning to upgrade to Liferay 7 CE (or maybe DXP) but we really need this functionality to assign a role depending on the IP range. Without this feature (as ext-plugins are said to be removed completely from LR7) I would have to abandon Liferay and use something else (which would by very sad!).
Does anyone know now this can be implemented in Liferay 7 CE ?
Can this be done by using an "OSGi override"? Or is this possible "out-of-the-box"?

Thanks in advance for any ideas or solutions (or documentation referrals).

Best regards,
Markus

[Christoph Rabel, geändert vor 6 Jahren.]

If I had to do this, I would have used a different approach.

I would have created a "campususer" with minimal rights. And then I would have created an autologin module that authenticates based on IP. That way I wouldn't have to do anything "hardcore". I would have a normal user with normal permissions.

I just would have to hide the control panel, no user public/private pages (I think if you give him user and not power user for that, but might be wrong here). And I would need to do something about authentication, create a "login portlet" or something like that to allow users to login even though they are "already authenticated".

[Markus Krause, geändert vor 6 Jahren.]

Hi Christoph,

thanks for your suggestion.
Before I wrote this ext-plugin (some 4 years ago) I did also try the autologin approach but had some issues with re-authentication, right now can not remember details but this did somehow not really work reliable, at least not the way I implemented it. But another issue (why I did not try to solve the one just mentioned) was the session expiration which led to the annoying message that the session expires every 30 minutes (which we had to set up due to policies).
Control Panel and private/public pages is not shown/used for any users (except admins).

But thanks for letting me remember this, maybe this works better with Liferay 7 CE!

[David H Nebinger, geändert vor 6 Jahren.]

Yeah, this is a tough one. Christophe's solution is one, but I wonder how hard it would be to re-authenticate as an actual user with the auto login guy getting in the way.

It is probably better handled by audience targeting, but that is not available in LR7CE.

I'm not a fan of the original EXT approach either, I can imagine cases where I'm on campus on the wifi on my phone seeing some content but, as soon as I walk off campus and fall back to cell, everything stops working? Or if I see something while I was on campus yesterday that I need to see but now that I'm off campus, I can't get to the details?

And how does the assigning guest a role thing work? The changing of roles/permissions would result in a database change and a corresponding broadcast message to the cluster, so with the constant changing that generates unnecessary DB and network traffic.

If I had to solve this I would likely take a completely different path. Two different sites, one for off campus and one for on campus, each maintained separately. In apache httpd (or similar), directing traffic to one or the other site based on IP range. On top of this, I would have the on campus site inject a (semi-)permanent cookie that httpd would also use to pass user to on campus site. This gives you the ability to float from on campus outside of wifi but still see the on campus content and fix the bad UX issue.







Come meet me at the 2017 LSNA!

[Andrew Jardine, geändert vor 6 Jahren.]

... and you can use the parent child hierarchy to cover cases where you have content that you want to be available on both sites.

[Markus Krause, geändert vor 6 Jahren.]

Hi Andrew, thanks for your suggestion.
As I just wrote in my answer to Davids post having to sites which almost identical content seems to be a to much effort when maintaining content. Maybe I should have described my use-case in more detail, sorry for the misunderstanding.

[Christoph Rabel, geändert vor 6 Jahren.]

But you don't need to maintain the content twice.

Create a Site Campus (you probably can use your standard site for this)
Create a Site Public

Then place Assetpublishers or Webcontent Displays.
Campus shows content from World and Content
Public shows only content from site Public

Don't forget to configure search portlet, Public: This site only. You might want to hook that or something to disallow "manual" setting of a groupId for search by unauthenticated users.

And that should be it.
Of course, you don't get any "real security" by this, but since this stuff is public on campus anyway, it can't be secret.

[Andrew Jardine, geändert vor 6 Jahren.]

Christoph already replied but to be clear, the whole point I was trying to make is that with Parent -> Child sites, the content doesn't need to be maintained twice. Otherwise, you are right, no business person would ever accept a proposal to double their work load.

[Markus Krause, geändert vor 6 Jahren.]

Thanks David for your input!

David H Nebinger:

Yeah, this is a tough one. Christophe's solution is one, but I wonder how hard it would be to re-authenticate as an actual user with the auto login guy getting in the way.

It is probably better handled by audience targeting, but that is not available in LR7CE.

I actually had some issues with re-authentication when I was trying to use this approach.
If DXP would solve this in an easy way this might be an option for us ...

David H Nebinger:

I'm not a fan of the original EXT approach either, I can imagine cases where I'm on campus on the wifi on my phone seeing some content but, as soon as I walk off campus and fall back to cell, everything stops working? Or if I see something while I was on campus yesterday that I need to see but now that I'm off campus, I can't get to the details?

Yes, thats right but this also is intended. We do actually only show information in our Liferay site (we call it our "Self-Service Portal") which is relevant for our users who can login and then see all information, users-to-be who just want to look up some information how to start and will get an account soon or guests which do not find information valuable for them if they do not stay on campus and become "real" users. We never received any complaints about that.

David H Nebinger:

And how does the assigning guest a role thing work? The changing of roles/permissions would result in a database change and a corresponding broadcast message to the cluster, so with the constant changing that generates unnecessary DB and network traffic.

I did create a role "campusGuest" which is assigned to the user (by extending AdvancedPermissionChecker) in addition to the guest role if he comes from a specific IP range (I add an attribute to the session indicating that the IP is in that range) so I there is no database change involved here.

David H Nebinger:

If I had to solve this I would likely take a completely different path. Two different sites, one for off campus and one for on campus, each maintained separately. In apache httpd (or similar), directing traffic to one or the other site based on IP range. On top of this, I would have the on campus site inject a (semi-)permanent cookie that httpd would also use to pass user to on campus site. This gives you the ability to float from on campus outside of wifi but still see the on campus content and fix the bad UX issue.

A user with the role "guest" (not logged in) does only see the login and no further information.
A user with the role "campusGuest" (assigned by IP range) will see all our service descriptions (except some information dedicated only to our users) and can access our address book portlet.
A user that is logged in sees everthing, e.g. portlets which allows him to do more things like change his password.
Thus a different site for "campusGuest" users and "users" would mean to have an almost identical copy. That would mean I have a lot of web content on two sites with only some more on the "users" site.

To be honest: I never really liked my approach using an ext-plugin either (for obvious reasons) but in our case it seemed the best (easiest) solution. But I am really open for any (more) suggestions!

[Christoph Rabel, geändert vor 6 Jahren.]

Markus Krause:

I actually had some issues with re-authentication when I was trying to use this approach.
If DXP would solve this in an easy way this might be an option for us ...

Couldn't you simply destroy the current session in a filter when /c/portal/login is accessed? Your autologin module probably would need some logic too to prevent it from instantly authenticating the user again, but I think it should work.