LDAP configuration

[atothep]

Hi,

in principle, we have LDAP running with our KNIME Server. I can logon with my LDAP user name, e.g. as a consumer, when I explicitly add that user name to com.knime.server.login.consumer.allowed_accounts:

However, since we have many users, we don’t want to specify each user separately here, but - of course - we just want to use LDAP groups to specify allowed users and consumers. But for some reason, that doesn’t work:

Question: is it really correct that we can simply add the LDAP group names in these two fields together with or right next to the local group names? No need to mark them as LDAP groups?

And another question:
This regards the setting com.knime.server.login.allowed_groups
The user guide says " This setting has to include all groups that should be allowed to login to KNIME Server, regardless of whether they are users or consumers." Is that really correct? If that’s really the case, why doesn’t the KNIME server simply create this list automatically?? Why do I have to specify it manually? I mean, it’s just the UNION of the two setings user.allowed_groups and consumer.allowed_groups. Why should any user or consumer NOT be in the list of allowed login? That doesn’t really make sense. My feeling is that there is another meaning to this setting which is not mentioned in the user guide. Can someone please comment on this? Thank you!

[NDekay]

Hello,

Documentation at [1] demonstrates the expected use-case for the login.allowed_groups property.
In the example, it allows marketing, research, and analysts groups to login to the server at all; users outside those groups (for example, group business or group marvelfans) would not be able to login at all.
Then, through the use of consumer.allowed_groups and user.allowed_groups we filter which ones can login from AP (the users who are developing workflows; group research, in the example) and which ones are merely consumers who can use the workflows via the webportal or REST API (all 3 groups can do this).

Documentation at [2] describes the definitions and defaults slightly more thoroughly:

com.knime.server.login.allowed_groups =,,…​ [RT]
Defines the groups that are allowed to log in to the server.
Default value allows users from all groups.

com.knime.server.login.consumer.allowed_accounts =,,…​ [RT]
Defines account names that are allowed to log in to the server as consumer.
Default value allows login as consumer for all users.

com.knime.server.login.consumer.allowed_groups =,,…​ [RT]
Defines the groups that are allowed to log in to the server as consumer.
Default value allows login as consumer from all groups.

com.knime.server.login.user.allowed_accounts =,,…​ [RT]
Defines account names that are allowed to log in to the server as user. Default value allows login as user for all users.

com.knime.server.login.user.allowed_groups =,,…​ [RT]
Defines the groups that are allowed to log in to the server as a user.
Default value allows login as user from all groups.

That being said, you are correct in that you must specify ALL groups that can login whatsoever in login.allowed_groups.
Don’t think of it as a UNION of the two smaller groups.
Think of it as defining who can login at all, and then the two smaller groups are defining their roles/login types.
The two smaller groups are refined subsets of the login.allowed_groups set.

Regards,
Nickolaus

[1] KNIME Server Administration Guide
[2] KNIME Server Administration Guide

[atothep]

Hi Nickolaus,
thanks for your response!

Well, yes, I understand all this, and I have read the documentation. But still, I don’t get why I need to repeat all the groups from the other two settings. This could just as well be done automatically/internally by the server.
The only use case I see for specifying the allowed login separately would be that someone is a user (or consumer), but he or she is not allowed to login. I don’t see why I should do that…
But anyway, never mind I just accept this for the time being and do a copy-paste of user and consumer groups…

Yet another follow-up question:
What does it mean if com.knime.server.login.allowed_groups is left empty?
Does it mean “no one can login”, or does it mean “everyone can login”?

(This is not as stupid as it might seem. In the case of login.user.allowed_groups, “empty” means everyone can be a user! From my point of view, this is both counter-intuitive and dangerous because users typically occupy licenses. So you better be careful and don’t accidentally leave this field empty…)

[NDekay]

Hi! You’re welcome.

What does it mean if com.knime.server.login.allowed_groups is left empty?
Does it mean “no one can login”, or does it mean “everyone can login”?

com.knime.server.login.allowed_groups =,,…​ [RT]
Defines the groups that are allowed to log in to the server.
Default value allows users from all groups.

Empty will go to default value, which is allow users from all groups.

(This is not as stupid as it might seem. In the case of login.user.allowed_groups, “empty” means everyone can be a user! From my point of view, this is both counter-intuitive and dangerous because users typically occupy licenses. So you better be careful and don’t accidentally leave this field empty…)

Seems accurate. Though they’d only count as a user if they connected to the server through AP.

You could, for example, leave login.allowed_groups= and login.consumer.allowed_groups=, but specify login.user.allowed_groups=research, so that anyone in the company could login (on the webportal, as a consumer) to run data apps or workflows, but only the research group could login from AP to upload workflows.

I think you’ve got the gist of it, though. The awkwardness of login.allowed_groups requiring the bit of repetition (being a drill-down rather than build-up configuration) could be a feature request, but I think management will be different in the Hub going forward anyway so it may be a moot point after a few versions.

Let me know if you have any other questions!

Regards,
Nickolaus

[atothep]

@NDekay

You could, for example, leave login.allowed_groups= and login.consumer.allowed_groups=, but specify login.user.allowed_groups=research, so that anyone in the company could login (on the webportal, as a consumer) to run data apps or workflows, but only the research group could login from AP to upload workflows.

Good point! I didn’t think of such a situation. +1 for you
Anyway, a bit more explicitness in the formulation (like introducing a keyword ALL or the like instead of just leaving it empty) would be nice.

Thanks for the good discussion!

Any comment/answer to my first question regarding the configuration of LDAP groups?

[NDekay]

@atothep

Question: is it really correct that we can simply add the LDAP group names in these two fields together with or right next to the local group names?

Sorry, I think I neglected to answer this earlier.
I think the answer is “yes”, you can put them together, side by side, in the unlikely use case where you have some users authenticating against the local H2 db and other users authenticating against LDAP. (I say users, here, but really it could be users or consumers.)
In practice, most organizations go with one or the other - if you’re using LDAP, then it’s pretty unlikely you’d need anyone to authenticate against H2. So in that case, you’d have it almost, or entirely, comprised of LDAP group names.

And if you have, say, 10 members in LDAP group “research” but still want only 5 of them to be able to connect via AP, you can further restrict who can login via com.knime.server.login.user.allowed_accounts.

Hope that clears any last questions up?
Or let me know, if not.

Regards,
Nickolaus

[atothep]

Thanks again for your help!

With your hints, I rethought our whole setup and actually ended up with a very simple configuration that works. Basically, I leave all fields empty except user.allowed_groups where I specify very few local (H2 DB) groups that may login as users. All others (i.e. our whole company) can hence login as consumers with their LDAP accounts - and that’s OK since we have unlimited consumers. But, of course, we specify permissions on workflow repository level anyway. So only those LDAP users which are in any group with permissions for any workflow can acutally do something. All others can login, but they can’t do anything. That’s fine.

Nevertheless, I have another follow-up question now
And this one refers to the setting com.knime.enterprise.executor.msgq.rules

We have distributed executors in our setup, and the selection of an executor depends on the (LDAP) group of the user/consumer executing. Like:

com.knime.enterprise.executor.msgq.rules=(group=’GroupA’), (group=’GroupB’) || (group=’GroupC’)

Any chance to use wildcards in this expression? Like e.g.:

com.knime.enterprise.executor.msgq.rules=(group=’Group*’), (group=’*B’) || (group=’*C’)

(This is getting interesting now because new LDAP groups with WF execution permission might be created. But we don’t want to modify these rules every time a new LDAP groups comes into play. Especially because changing that setting requires a tomcat restart…)

Any ideas on that?

[NDekay]

Hi,

I see that we already have an open support case for that very question - it is assigned out to one of our support agents. I will nudge them to update the case and get an answer for you.

I will note, however, that tomcat restarts aren’t really a big deal.
sudo systemctl restart knime-server and it’s back in operation immediately.

Additionally, any knime server directive that is marked as [RT] in the documentation means the knime server will apply changes to that property in realtime, which won’t even require a restart. Most directives are [RT]. Only a few are [ST] and require a restart.

Regards,
Nickolaus