On Sat, Apr 14, 2018 at 2:58 PM, YT <yalew.am...@gmail.com> wrote:
> ...
>
> 1 --- How do I use the above token to login automatically similar to the
> normal way of specifying the username and password as shown below to
> login automatically?
>
> http://localhost:8080/guacamole/#/?username=USER200&password=MYPASS200
>
>
Include it in the URL as the value of the "token" parameter.
> 2 --- Also, It seems that whenever I add/specify a password using
> "password" name parameter in the JSON data, guacamole does not return a
> valid token(tried this several times). So why is that? And actually in the
> README.md example, the password keyword is not used which I believe is
> essential for automatic login mechanism mentioned above.
>
>
If you mean you are providing JSON like:
{
'username' : 'foo',
'password' : 'bar
}
this is not working because it is invalid. There is no password property:
https://github.com/glyptodon/guacamole-auth-json#json-format
The guacamole-auth-json extension authenticates users by verifying the
signature of the received encrypted data.
> 3 ---- How should I configure guacamole to accept ONLY JSON encrypted and
> hashed messages for login mechanism and reject login messages that are not
> encrypted and hashed?
Remove all extensions except guacamole-auth-json.
...
>
> I am assuming the following order of operation; it would be great if
> someone
> can confirm/correct since this is crucial to understand the whole process.
>
> Message is received ---> Message is dencrypted and hash is verified
> ---->JSON data is parsed/extracted -----> username and password is passed
> to
> the authentication provider extension and is compared against
> database/user-mapping.xml/others ----> once authenticated,
> guacamole-auth-json extension will generate token and forward it back to
> the
> user/client
>
>
No, this is not what happens. Authentication providers do not forward the
user's identity by passing a username/password around, assuming a
username/password is involved at all.
When a user has authenticated, the authentication provider that
authenticated that user returns an "authenticated user" object which
represents the user's identity internally. It is the extension's way of
stating, for the benefit of itself and any other extensions, "I have
authenticated this user and they are user X". It is then up to the other
extensions to provide data for this user, now that their identity is known.
This is done not by testing some username/password forwarded along by the
original authentication provider, but by trusting the result of that
authentication provider as it stands.
For example, let's say you're using both LDAP and MySQL, and the LDAP
directory has a user X that can authenticate with Guacamole. This same user
X exists within MySQL, but cannot login purely via MySQL as no password has
been set. The following happens when the user logs in with their LDAP
credentials:
1) The LDAP authentication provider requests a username/password
2) The user submits their username/password.
3) The LDAP authentication provider tests the received username/password
and identifies the user as user X.
4) The fact that the user has successfully authenticated as user X is
passed along to all other extensions, including MySQL.
5) The MySQL extension trusts the authentication result of the LDAP
extension, and provides the data associated with user X. No password
involved - just a statement of identity from one extension, and acceptance
of that identity from others.
The same would work with guacamole-auth-json if you had JSON like:
{ 'username' : 'X' }
The fact that the JSON is properly signed is enough to prove to the
extension that the user is authorized, and the username within the JSON is
enough to define the user's identity. That identity is then passed on to
all other extensions.
Alternatively, you could include all the data that should be exposed to the
user within the JSON, and rely purely on guacamole-auth-json.
- Mike
