CAS Extension

[richk <rk...@gmail.com>]

In the docs with regards to the CAS extension it has this line: 

"This module must be layered on top of other authentication extensions that
provide connection information, as it only provides user authentication".

So would I configure the auth-provider property with
BasicFileAuthenticationProvider as usual, but then specify
cas-authorization-endpoint and cas-redirect-uri to override the default
login action to use CAS instead? If so, then can I just specify the
connection configs in user-mapping.xml as usual too? 

Is that how it's intended to work? It seems too easy?





--
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/

Re: CAS Extension

[richk <rk...@gmail.com>]

 
Mike Jumper wrote
> On Mon, Sep 18, 2017 at 8:23 AM, richk <

> rk5devmail@

> > wrote:
> 
>>
>> In the docs with regards to the CAS extension it has this line:
>>
>> "This module must be layered on top of other authentication extensions
>> that
>> provide connection information, as it only provides user authentication".
>>
>> So would I configure the auth-provider property with
>> BasicFileAuthenticationProvider as usual, but then specify
>> cas-authorization-endpoint and cas-redirect-uri to override the default
>> login action to use CAS instead?
> 
> 
> There actually is no "auth-provider" property. This property was
> deprecated
> in 0.9.7 in favor of a new, self-contained extension format [1] and
> finally
> removed entirely in 0.9.10-incubating [2]. Usage of this property between
> 0.9.7 and 0.9.10-incubating would have worked but resulted in a warning in
> the logs, but the property it is now ignored. It is no longer documented
> in
> the manual, and any third-party tutorials which refer to it are out of
> date.
> 
> If so, then can I just specify the
>> connection configs in user-mapping.xml as usual too?
>>
>> Is that how it's intended to work? It seems too easy?
>>
>>
> This is exactly how it's intended to work. Guacamole supports loading
> multiple extensions simultaneously, and will automatically combine
> authentication methods. I'd recommend using the MySQL or PostgreSQL
> extensions instead of "user-mapping.xml", however. Besides the way that
> user-mapping.xml requires the password to be manually defined for each
> user, I believe there is a known issue with using user-mapping.xml
> alongside other auth extensions (where the built-in auth mechanism
> handling
> user-mapping.xml does not properly collaborate with other extensions,
> unlike the database, ldap, etc. auth), but I've thus far not found a link
> to where this was reported.
> 
> - Mike
> 
> [1]
> http://guacamole.incubator.apache.org/releases/0.9.7/#simplified-extensions
> [2]
> http://guacamole.incubator.apache.org/releases/0.9.10-incubating/#removal-of-deprecated-lib-directory-and-auth-provider-properties


Thanks Mike. If there's an issue with the user-mapping file conflicting with
other auth extensions then we'll use the database option. I'll try with the
user-mapping file and report any issues just so you have a record with the
understanding that using the database extensions is the recommended course
of action.

-Rich




--
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/

Re: CAS Extension

[Mike Jumper <mi...@guac-dev.org>]

On Mon, Sep 18, 2017 at 8:23 AM, richk <rk...@gmail.com> wrote:

>
> In the docs with regards to the CAS extension it has this line:
>
> "This module must be layered on top of other authentication extensions that
> provide connection information, as it only provides user authentication".
>
> So would I configure the auth-provider property with
> BasicFileAuthenticationProvider as usual, but then specify
> cas-authorization-endpoint and cas-redirect-uri to override the default
> login action to use CAS instead?


There actually is no "auth-provider" property. This property was deprecated
in 0.9.7 in favor of a new, self-contained extension format [1] and finally
removed entirely in 0.9.10-incubating [2]. Usage of this property between
0.9.7 and 0.9.10-incubating would have worked but resulted in a warning in
the logs, but the property it is now ignored. It is no longer documented in
the manual, and any third-party tutorials which refer to it are out of date.

If so, then can I just specify the
> connection configs in user-mapping.xml as usual too?
>
> Is that how it's intended to work? It seems too easy?
>
>
This is exactly how it's intended to work. Guacamole supports loading
multiple extensions simultaneously, and will automatically combine
authentication methods. I'd recommend using the MySQL or PostgreSQL
extensions instead of "user-mapping.xml", however. Besides the way that
user-mapping.xml requires the password to be manually defined for each
user, I believe there is a known issue with using user-mapping.xml
alongside other auth extensions (where the built-in auth mechanism handling
user-mapping.xml does not properly collaborate with other extensions,
unlike the database, ldap, etc. auth), but I've thus far not found a link
to where this was reported.

- Mike

[1]
http://guacamole.incubator.apache.org/releases/0.9.7/#simplified-extensions
[2]
http://guacamole.incubator.apache.org/releases/0.9.10-incubating/#removal-of-deprecated-lib-directory-and-auth-provider-properties

Re: CAS Extension

[richk <rk...@gmail.com>]

Thanks Nick. Normally, I'd agree with you on using the JDBC extension, but
spinning up a database is kind of an overkill for our simple use cases.
Quick follow-up questions on the basic file authentication with regard to
your comment: 

> In particular, when you configure users in the basic file module, 
> you have to specify a username and password, so you'll need to generate 
> complex enough passwords that no one would be able to guess them."

If I understand correctly the username and password in the basic file would
be a separate way to authenticate forr that same user right? So the user
could authenticate with CAS or use the user name and password in the
user-mapping if they knew what it was?  

If that's the case then generating a random long password for the user
mapping config is acceptable for our use case. Just as long as the user can
authenticate with CAS.








--
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/

Re: CAS Extension

[vnick <vn...@apache.org>]

richk wrote
> In the docs with regards to the CAS extension it has this line: 
> 
> "This module must be layered on top of other authentication extensions
> that
> provide connection information, as it only provides user authentication".
> 
> So would I configure the auth-provider property with
> BasicFileAuthenticationProvider as usual, but then specify
> cas-authorization-endpoint and cas-redirect-uri to override the default
> login action to use CAS instead? If so, then can I just specify the
> connection configs in user-mapping.xml as usual too? 
> 
> Is that how it's intended to work? It seems too easy?

Layering just means that you have/use multiple modules.  Guacamole compares
usernames between the modules to "connect" the user accounts between the
modules.  So, you can definitely use the basic file authentication provider
and put usernames and connections in that file, then install the CAS module
and point it at your CAS server, and, as long as the usernames match, it
will pull in the connections for those users from the basic file provider.

However, using the basic file provider for this layering has a couple of
catches.  In particular, when you configure users in the basic file module,
you have to specify a username and password, so you'll need to generate
complex enough passwords that no one would be able to guess them.  Also, the
basic file module requires that you specify connections under the users in
the XML layout.  Unless there's a way to do it that's not documented in the
Guacamole documentation (Mike?), that means that you cannot specify a
connection and then assign it to multiple users - you'd have to copy that
connection specification multiple times under each of the accounts you'd
want it to apply to.

So, if you're layering it's really better to do it with the JDBC module - it
will auto-generate the passwords for the users you create, and you can allow
multiple to users to access the same connection without have to create it
multiple times.  You could also do this with the LDAP module if you wanted
to layer CAS with LDAP - IMHO the JDBC module just makes the most sense.

-Nick



--
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/