our aim is to provide our KNIME Server Webportal services to external users via different connected ContentManagementSystems (CMS). I am posting it here since it might be relevant for others as well or solved aready.
The problem is, that I have to make sure at the moment, that every new user gets an account in each platform. This is an impossible task, since I don’t have acces to the user managment of CMS which don’t belong to us.
In addition the user have to login everywhere each time they want to use the platforms and might have different credentials each. This is pretty annoying and not userfriendly at all.
I have no real understanding how SingleSignOn would work in detail, but the integration of Oauth in the newest KNIME Server sounds promising.
For a better understanding I try to picture a use case.
NGO-Server 1 in Italy is hosting CMS1
We are hosting CMS2 and the KNIME Server (large)
NGO-Server 3 in Norway is hosting CMS3
I would like to allow defined user groups of CMS1, CMS2 and CMS3 to be automatically logged in via SingleSignOn to our KNIME Server Webportal. Each of these groups would get access to individual workflows in the KNIME Webportal.
It is important to consider, that I have no knowledge about the user from the CMS1, CMS2 and CMS3 - all I can do is to tell the admins of these systems a user group for each purpose.
I hope my remarks are helpful to understand what we would like to achieve. It am looking for simple solution,which is open source, low cost and very secure.
Many thanks in advance!
The login part can indeed be solved by using OAuth, however, you would need an OAuth provider that must be configured at all services (CMS & KNIME Server). The group part is more difficult because most OAuth provider don’t even know the concept of groups/roles (Google, Facebook, etc.). Also the OIDC standard doesn’t have any built-in support for it. Once the authentication tokens issued by the provider contain group/role information it’s at least technically possible to use those in the KNIME Server and restrict access.
I suggest you first solve the general OAuth problem and then we can have a look at the KNIME Server configuration.
Thanks a lot! I would like to fully understand the problems before I start to realise the idea. Since I need to avoid, that things turn out not to work as planned and then the whole project was just wasted time.
I assume I would need to become my own oauth identity provider. For that purpose I found this example https://www.ory.sh/run-oauth2-server-open-source-api-security/ Therefore, this appears to be doable.
If I get you right, all CMS who support Oauth2 have to learn to check my Oauth server. Should be possible as well.
If in the future a member of one of the mentioned CMS (user1) is logged in and clicks on a link to one of our Workflows in the KNIME Webportal, there are no further login steps neded - the user has already access and the workflow can be executed.
If another person (user2), who is a user of the KNIME Webportal, would try the same link, no access would be granted on the KNIME Webportal, but the normal KNIME Webportal credentials can still be used by the user2 to get access to the KNIME Webportal to the workflows that account is allowed to use.
If user2 would have access to the same Webportal workflow as user 1, both would not see the jobs of the other user, since it could contain private information.
The explanation on https://docs.knime.com/2019-12/server_preview_functionality/index.html#oidc-authentication is hard to understand for me. It looks like I would have to create the same user in the CMS and the KNIME Server to map them in the end. Since I plan not to have knowledge of the CMS users, how is that not interferring with my plans?
Do you see any show stoppers? Non of these steps should require oauth experts I have to buy in.
Currently it is no possible to use both OAuth and the local user database. Therefore all users must authentication via OAuth. Also as I mentioned before OAuth doesn’t have any built-in support for groups/roles. Therefore if you want to make use of them you have to create all users in the KNIME Server again and perform the group assignment through the local user database. This is what is mentioned in the documentation. We will add the possibility to use group information from custom fields the in OAuth tokens in the future. If you don’t need groups then you can ignore that for now.