Cockpit itself is unprivileged and doesn’t make decisions related to authentication. The credentials given out by Foreman in step 4 just need to be accepted by sshd in step 5. Foreman might decline access in step 4 based on which user the session is for, etc.
Yes, the Foreman API fortunately allows access with a valid _session_id cookie, and the token exchanged in steps 2 and 3 is the value of that cookie. cockpit-auth-foreman turns the token back into a cookie.
A customer asked for better integration in regard to PCP performance data from hosts. While we will unlikely be writing a Foreman PCP plugins to present data from PCP, we should be able to have a button for hosts that opens up Cockpit interface on Performance page. I see there are plans on elaborating Cockcpit-PCP integration: https://github.com/cockpit-project/cockpit/wiki/Feature:-PCP-Integration
This is the code that makes the “Web Console” button appear and also implements the OAuth thing that transfers the Foreman session cookie to Cockpit. It introduces a new REX setting that the installer would need to set based on where the COckpit instance actually is.
This is the API in the SmartProxy that does all the work: it establishes a long running, interactive session via ssh on a target host. This happens via HTTP protocol upgrades and currently relies on using Puma with the SmartProxy.
Putting it all together to make it actually work is still a bit tricky.
Next steps for me:
Look into adding tests to my PRs above
Move foreman-cockpit-session into foreman_remote_execution and turn the foreman-cockpit repo into mostly documentation for how to set it all up, including the Apache reverse proxy thing.
Learn how the Foreman installer works and how we could do the setup
Open issues:
Normally, connections to the SmartProxy are done via HTTPS with client certificates. The foreman-cockpit-session program needs to be able to do that.
If the only supported way to set this all up is to have Cockpit on the same origin as Foreman (via a Apache reverse proxy), can’t we then rely on getting the session cookie directly and do away with the OAuth complication? This might need changes to Cockpit itself…
we have HTTPS between the Cockpit session helper and the Smart Proxy working now, but the details of where the session helper gets the certificates from are still open.
Hi, Firstly when I read it first time I understand you want to open the cockpit with different Foreman User. That is possible as lzap wrote, You will create new user with correct roles and you can open the cockpit.
But if I understand correctly you want to achieve something else:
With new_user you want to open cockpit and you want to differentiate also the cockpit users. Right now you are logged as root and you would expect to be logged as new_user right ?
Can you please explain why you need to this behavior, please ?
IMO when you create a new user and you give him enough roles to open cockpit
You are giving the new_user access, and now he can manipulate with host in cockpit. So in this point of view it doesn’t matter if he is logged as root inside the cockpit because you as admin already gave him a permission to manipulate with a machine.
I think this behavior is not implemented. I am not sure. @lzap hopefully knows the answer.
As per my understanding cockpit login is nothing to do with foreman user , when you click on Webconsole it open new tab on browser and open cockpit with root as I already add foreman -proxy key in host authorise keys.
But if I understand correctly you want to achieve something else:
With new_user you want to open cockpit and you want to differentiate also the cockpit users. Right now you are logged as root and you would expect to be logged as new_user right ?
I don’t want any new user in foreman, I just want existing foreman admin user open cockpit web console with non root user simple.
Can you please explain why you need to this behavior, please ?
IMO when you create a new user and you give him enough roles to open cockpit
You are giving the new_user access, and now he can manipulate with host in cockpit. So in this point of view it doesn’t matter if he is logged as root inside the cockpit because you as admin already gave him a permission to manipulate with a machine.
User is admin with full rights but foreman webconsole open cockpit only with root which I don’t want , I want cockpit should open with non root user.
I think this behavior is not implemented. I am not sure. @lzap hopefully knows the answer.
I think there is some simple parameter I can add in host parameters and It will work @lzap help me out bro.