Hi Joachim, I fail to see how your application invalidates my request for a minimal reorganisation of the whole authentication setup. My basic criticism is not that guacamole can do something (or a lot of things) itself. I am only not seeing a basic design that allows _simple_ setups as well as extensions not seen today. All I am telling is I would very much prefer a simple interface that parts the core guacamole from such extensions (of authentication or your type) in a way that the most basic function (user authentication) can be done in the most simple way. And although everything is very complex now even Nick seems unable to portray a simple way to authenticate a n-tuple (username,pw,ip). And I might well assume he knows guacamole very indepth.
-- Regards, Stephan On Sun, 21 Apr 2024 08:16:54 +0200 "Joachim Lindenberg" <guacam...@lindenberg.one.INVALID> wrote: > Hi Stephan, > I´d agree if authentication were the only goal of the API. However it also > allows to authorize users, and to provide (including create) configuration > data entirely not in the standard database. I visualized that capability and > how I use it in > https://software.lindenberg.one/backup/en/documentation/guacamole-integration. > I am not telling it cannot be done differently, but asking just for > authentication is too limiting. Regards, Joachim > > -----Ursprüngliche Nachricht----- > Von: Stephan von Krawczynski <skraw...@ithnet.com> > Gesendet: Sonntag, 21. April 2024 00:16 > An: user@guacamole.apache.org > Betreff: Re: How to get client IP address ? > > On Sat, 20 Apr 2024 15:52:58 -0400 > Nick Couchman <vn...@apache.org> wrote: > > > > > > > > > > > I believe the issue that Stephan is describing is that, when the > > > > user > > > logs > > > > in to Guacamole, and the remote LDAP server that is authenticating > > > > the > > > user > > > > logs a client IP address, it should log the IP address of the > > > > browser > > > (far > > > > end client) and not the IP address of the Guacamole Client > > > > (tomcat) > > > system. > > > > I'm just trying to get clarity from Stephan on whether this is > > > > what he's actually trying to do and why. > > > > > > > > -Nick > > > > > > Yes, Nick, you are exactly on the right track here. And I am really > > > not in a logging question, but truely in the authentication process > > > where I want to know the far end client. > > > > > > > > After looking at this a bit more, I cannot find a way, at least in the > > Apache LDAP API that we use, to configure a client IP or send any sort > > of a message that will pass that information through to the client, so > > I'm not sure how feasible this actually is. RADIUS uas the NAS IP > > designed specifically for this type of scenario, but I'm not finding > > any sort of feature similar to NAS IP that allows for this kind of > > messaging. > > > > -Nick > > Hello Nick, > > first of all, thank you for looking into the issue. So please let me ask > this as a real question and no offence. Why does the project _at all_ use a > rather complicated API for authentication instead of "outsourcing" the > function into a simple called hook (call it a script), and let this > implement the wanted api to ldap, mysql, radius or just about anything that > might be needed. Still in the end an authentication is no more than giving > parameters (like username, password, or client ip or whatever the caller > (i.e. guacamole) has) and getting the simple answer: yes (authenticated) or > no (login failed). If you cut off the whole process at this point the whole > story gets a lot more flexible, as anyone can then implement his needed hook > (script) for his needs. You may then distribute such hooks inside the > project for standard APIs like ldap or the like - or leave it to the users > to make/find their own. To me, designing (and coding) software since the > 1980s, this is a pretty clear design decision to be taken. > > Regards, > Stephan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org > For additional commands, e-mail: user-h...@guacamole.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
