A while back, I was playing around with adding OpenID Connect authentication to Web Access and built a prototype implementation in the form of an additional web service that sits in front of Web Access, taking care of the OpenID Connect authentication flow, extracting the username from the token and using the token itself as the password sent to the ThinLinc server. On the server side, this “password”/token is verified by the PAM module pam_oidc developed by Salesforce.
As per the README, this currently requires you to bump the size of the buffer where the password ends up on the server side (as OIDC tokens are way longer than your typical password). As of now, this can be done by applying the supplied patch to the obfuscated ThinLinc code provided in the GitHub repository. Note that this patch will be part of an official ThinLinc release in the near-term future.
I’m curious what the community thinks of this little hack? What are your initial thoughts?
As always, contributions in the form of issues, pull requests and general feedback are always welcome!
For what it is (a work-around) I do like this. I can see how I could take this and make something equivalent for the authentication we use, CAS.
One issue I can think of is that when a session times out and the user clocks the button to reconnect- they will be brought to the ThinLinc login screen and not page for the wrapper SSO.
I would work around this by reverse-proxying through Nginx and having that perform a conditional redirect if the login page was accessed in a way that wasn’t coming from the Flask app (referral check). The proxy adds it’s own complications but hopefully this still works with minor modifications.
One issue I can think of is that when a session times out and the user clocks the button to reconnect- they will be brought to the ThinLinc login screen and not page for the wrapper SSO.
This can actually be partially solved by changing the configuration parameter /webaccess/login_page in /opt/thinlinc/etc/conf.d/webaccess.hconf:
# The url to the login page.
# Example: https://thinlinc.example.com:300/
login_page=https://sso-wrapper-url/
However, this may result in you getting logged back into ThinLinc when you log out (if the SSO provider considers you to still be logged in). This behavior differs between SSO providers, though. You may also work around it by setting /webaccess/login_page to the URL of a landing page with a link to the SSO wrapper.
Worth noting is that the “solution” presented in this thread was the result of the proof-of-concept to prove the viability of OIDC in ThinLinc. Down the line, we aim to have a more user-friendly and robust variant of this without the need for external PAM modules integrated into the product itself. This work is currently under way.
The proxy adds it’s own complications but hopefully this still works with minor modifications.
As far as I know, the linked blog post is still somewhat up to date. Note that we aim to ship significant improvements in the area of Web Access behind a reverse proxy in the upcoming ThinLinc release (4.20.0), which will make the somewhat approach in this blog post largely redundant.