I would say this is better to solve within a proper IdP rather than an end-node webapp like guacamole. ie set up guacamole to use SAML or OpenID connect to a "proper" Identity provider and make that thing do the high-security checks. eg we use Apache with mod_auth_mellon as a reverse proxy frontend to guacamole (set to use http-auth-header). As we are an "Okta shop", that means we can lean into all the MFA offerings they have - guacamole doesn't have to worry it's pretty little head about it ;-). But Google's OpenID-Connect would do just as good a job. Or this, or that, etc :-)
On Sat, Oct 30, 2021 at 6:12 AM Craig Sawyer <csaw...@yumaed.org> wrote: > OK I'm all for short-lived auth certs, I'm a fan. But I'm confused as > to the use case/utility here. The idea you have is: > > A: User visits Guacamole and authenticates via some method and guac > returns a Guac Auth Cookie to the browser. > B: User clicks on host SSHA in Guac UI, and Guac then determines SSHA > needs a short lived auth token/cert and then does one of these: > 1: Guac impersonates the user, to generate a short lived auth > token/cert/OTP for SSHA > 2: Guac has the rights to generate such things for ALL users, no > impersonation needed > C: Guac connects to SSHA, sends the short lived cert to SSHA and then > returns a full connection to the user. > > To alleviate all of this complexity in our infrastructure, for Guac, > our virtual desktop systems have a 65 character randomly generated > password, shared only with Guac. Since brute force attacks against a > 64 char password is currently known to require more energy than the > entire known universe, we feel confident the possible leak of an > account can only happen from guac being compromised or the target host > leaking it somehow. Either way a short lived cert doesn't buy us > anything(especially since using the Guac SQL DB, we can update those > passwords at will whenever we want with some SQL queries). > > I don't see how a short lived cert(above) buys anything over say my > solution. > > The 1st option, passing through an MFA/token from the end user > client(i.e. web browser) all the way through to the target host > machine (SSHA in this example) is something I'd definitely be > interested in. This would require transporting FIDO/U2F or X509 certs > through, neither of which are user-friendly or 100% supported yet(last > I checked). Since browsers have mostly decided client X509 certs are > evil and should never be user-friendly, the only option is FIDO/U2F > pass-through (unless I'm missing something) which isn't yet fully > supported across the major browsers yet(right?). > > -Craig > > On Fri, Oct 29, 2021 at 9:39 AM Angal, Rajeev <ran...@visa.com.invalid> > wrote: > > > > Thanks. Nick. Makes total sense. Yes I agree opensource projects need > developers who have interest and time. > > > > I will check the developer forum to get a feel of the component it goes > to and the scope of the effort. > > > > I have filed a Jira ticket here: > > > > https://jira.glyptodon.com/browse/GUAC-1694 > > > > > > > > -rajeev > > > > > > > > > > > > > > > > From: Nick Couchman <vn...@apache.org> > > Sent: Friday, October 29, 2021 9:10 AM > > To: user@guacamole.apache.org > > Subject: Re: Does Guacamole support PKI/Smartcard authentication for RDP > (instead of username/password)? > > > > > > > > On Thu, Oct 28, 2021 at 10:25 PM Angal, Rajeev <ran...@visa.com.invalid> > wrote: > > > > Hello – > > > > Want to request a poll to the community if this feature would be useful? > > > > > > > > If you think this feature would be useful, the best thing to do is 1) > insure that there's a Jira issue for it, 2) vote for the Jira issue, and 3) > contribute. > > > > > > > > https://issues.apache.org/jira/projects/GUACAMOLE/issues > > > > > > > > If there is enough interest , please advise the best way to implement it > in the near future. > > > > > > > > While you're welcome to lend your voice to the issue by posting here or > submitting and/or voting on the Jira issue, if you want to get it > implemented then you need to either wait for one of the developers to have > the time, expertise, and inclination to do it, or jump in and contribute > yourself. This is an open source, community project, and, while enough > people asking for a feature can help raise it to a level that an existing > developer would jump in and do it, the reality is that many features get > implemented when someone who has a vested interest in the feature is able > to contribute to it's getting done. I recognize that not everyone is a > developer - I'm not a very good one, and it isn't what I spend most of my > time doing - I'm a systems engineer/admin and IT Manager by day. My > contributions are pretty limited as compared to some of the other folks who > spend their time on the project, but I wrote the RADIUS extension when I > needed it enough in my #DayJob that I was willing to invest time in > brushing up on my Java skills and working with the other developers to get > the code to the point where it could be included in the project. > > > > > > > > -Nick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
