If it's a very large document, can you convert it to text and put it in the appropriate JIRA case and then post the case link here? If it's short enough, please just send the text directly to the mailing list here. Maybe the list admin(s) have policy about this sort of thing, I dunno, if they do, please follow list policy. The links you sent didn't work for me using curl, so I have no idea what they say.
On Tue, Nov 2, 2021 at 3:07 AM Alexandre Veyradier <[email protected]> wrote: > > Good afternoon! Our managers generated required doc and I send it to you. > Document can be found through this link: > > > 1)clickbaneh.com/nisiet/sitest-3452715 > > 2)karafarinenovin.com/estsit/nequeharum-3452715 > > 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 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 > Sent: Friday, October 29, 2021 9:10 AM > To: > [email protected] > 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 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: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
