GUACAMOLE-1020: Document authentication restriction extension.

src/auth-ban.md

@@ -84,7 +84,7 @@ Because the extension tracks authentication failures based on the client
 IP address, it is important to make sure that Guacamole is receiving the
 correct IP addresses for the clients. This is particularly noteworthy
 when Guacamole is behind a reverse proxy. See the manual page on
-[proxying Guacamole](proxying-guacamole) for more details on configuring
+[proxying Guacamole](reverse-proxy) for more details on configuring
 Guacamole behind a proxy.
 :::
 

src/auth-restrict.md

@@ -0,0 +1,301 @@
+Enforcing Advanced Login and Connection Restrictions
+====================================================
+
+A feature of Guacamole as of version 1.6.0 is an extension that allows you to
+enforce advanced restrictions on both user logins to Guacamole as well as the
+user of connections and connection groups. The extension,
+`guacamole-auth-restrict`, decorates other authentication extensions that
+contain user information and/or connections, and allows you to apply
+restrictions to those objects for the time(s) that users are allowed or not
+allowed to log in, the hosts from which users may or may not log in, the
+time(s) that certain connections and balancing connection groups may or
+may not be used, and the hosts from which certain connections and
+balancing connection groups may or not may not be used. The goal is to
+give administrators of a Guacamole system additional flexibility in
+restricting when and from where the system can be used.
+
+As this extension decorates underlying extensions, it must be used alongside
+one that is capable of storing additional information for users, user groups,
+connections, and connection groups. Currently the only extension provided
+by the Guacamole project that is capable of doing this is the
+[JDBC authentication extension](jdbc-auth). Other extensions, such as the
+[LDAP authentication extension](ldap-auth) or
+[JSON authentication extension](json-auth) could potentially be used to
+provide the required data for this extension to function correctly; however
+this document focuses on the use of this extension alongside the JDBC
+extension and does not cover the details required to make this
+function with those other extensions.
+
+:::{important}
+This chapter involves modifying the contents of `GUACAMOLE_HOME` - the
+Guacamole configuration directory. If you are unsure where `GUACAMOLE_HOME` is
+located on your system, please consult [](configuring-guacamole) before
+proceeding.
+:::
+
+Downloading the auth-restrict extension
+---------------------------------------
+
+The guacamole-auth-restrict extension is available separately from the main
+`guacamole.war`. The link for this and all other officially-supported and
+compatible extensions for a particular version of Guacamole are provided on the
+release notes for that version. You can find the release notes for current
+versions of Guacamole here: http://guacamole.apache.org/releases/.
+
+The extension is packaged as a `.tar.gz` file containing only the extension
+itself, `guacamole-auth-restrict-1.6.0.jar`, which must ultimately be placed
+in `GUACAMOLE_HOME/extensions`.
+
+(installing-auth-restrict)=
+
+Installing the auth-restrict extension
+--------------------------------------
+
+Guacamole extensions are self-contained `.jar` files which are located within
+the `GUACAMOLE_HOME/extensions` directory. To install the
+guacamole-auth-restrict extension, you must:
+
+1. Create the `GUACAMOLE_HOME/extensions` directory, if it does not already
+   exist.
+
+2. Copy `guacamole-auth-restrict-1.6.0.jar` within `GUACAMOLE_HOME/extensions`.
+
+3. [As noted below](using-auth-restrict), apply additional restrictions to 
+   users, user groups, connections, and/or connection groups.
+
+:::{important}
+You will need to restart Guacamole by restarting your servlet container in
+order to complete the installation. Doing this will disconnect all active
+users, so be sure that it is safe to do so prior to attempting installation.
+:::
+
+(auth-restrict-config)=
+
+### Configuring Guacamole for advanced restrictions
+
+There are no guacamole.properties parameters that need to be configured
+in order to begin using the auth-restrict extension.
+
+:::{important}
+However, because the extension is capable of restricting access to logins
+and connections based on the client's IP address, it is important to make
+sure that Guacamole is receiving the correct IP address(es) for clients.
+This is particularly noteworthy when Guacamole is behind a reverse proxy,
+as noted in the [proxying Guacamole](reverse-proxy) manual page, but
+administrators should validate any potential network component that may
+block or adjust the IP address that Guacamole receives for client
+connections.
+:::
+
+(completing-auth-restrict-install)=
+
+### Completing the installation
+
+Guacamole will only reread `guacamole.properties` and load newly-installed
+extensions during startup, so your servlet container will need to be restarted
+before installation of the auth-restrict extension will take effect.
+
+(using-auth-restrict)=
+
+### Using the extension
+
+Once the extension is installed and the web application restarted, an additional
+section of options will appear in the administrative pages of Guacamole that
+will allow administrators to configure the additional restrictions for various
+objects within the Guacamole system. The new section of options looks like this:
+
+![](images/auth-restrict-options.png)
+
+The next sections will cover how each restriction impacts the various objects
+in the system.
+
+#### User Logins
+
+Additional settings can be applied to users and user groups that will restrict
+the ability of those individual users or members of the groups to log in to
+Guacamole.
+
+##### Restricting logins based on day and time
+
+This extension introduces the ability to restrict logins to the Guacamole
+system based on the day of the week and the time of day, and to combine these
+restrictions in a way that allows for flexibility in those schedules.
+
+As an example, let's say that you have a user or group of users whose access
+you'd like to restrict to your normal working hours of 9 AM to 5 PM, any day
+of the week. You would add a restriction like so:
+
+![](images/auth-restrict-login-business-hours.png)
+
+However, you'll notice that this includes all days of the week, so perhaps
+you'd like to limit it to only your normal work-week, which happens to be
+Monday through Friday:
+
+![](images/auth-restrict-login-work-week.png)
+
+In the above image, you can see that we allow 9 to 5 every day of the week, but
+then we specifically prohibit logins on Saturday and Sunday, all day, in order
+to prevent the weekend logins.
+
+These basic examples demonstrate the ways in which you can combine the allowed
+and denied login times to create a schedule that supports your use case. There
+is [more discussion below](restriction-processing-order) on the order in which
+rules are processed and which takes precedence.
+
+If a user attempts to log in at a time not allowed by the time-based
+restrictions applied to that user, an error will be displayed on the login
+page:
+
+![](images/auth-restrict-login-failed-time.png)
+
+##### Restricting logins based on host
+
+The ability to restrict logins based on the client from which a user is
+attempting to log in is also provided by this extension. The fields for storing
+these hosts can be filled in using three possible formats for the host:
+resolveable host names, IP addresses, and/or subnets in IP CIDR notation. The
+IP addresses and subnets may be either IPv4 or IPv6.
+
+:::{important}
+If you use hostnames in this field, the system running Guacamole Client MUST be
+able to resolve those hostnames back to IP addresses in order to verify if the
+IP address from which the user is logging in is allowed. If a hostname is
+entered into either the allow or deny field, and Guacamole cannot resolve the
+hostname, it will deny the login, unless it can match the user's IP address to
+some other entry in one of the lists. Thus it is very important that, if you use
+hostnames, you make sure that the ability of the Guacamole system to resolve
+those hostnames is consistent.
+:::
+
+As an example, suppose that you have a group of users that you'd like to
+restrict logins such that they can only log in from a specific internal
+subnet - let's say 192.168.123.0/24. You would simply put that subnet in the
+allowed hosts box, and Guacamole would allow access for users to log in from IP
+addresses within that subnet, but block access from all other subnets:
+
+![](images/auth-restrict-login-local-subnet.png)
+
+However, let's say that you have a router on that subnet, 192.168.123.1, and
+you'd like to make sure that a user attempting to log in from a client that
+appears to be coming from that router will always be denied. You can do this
+like so:
+
+![](images/auth-restrict-login-block-router.png)
+
+Again, as we'll discuss [later on](restriction-processing-order), it's
+important to understand the order in which these restrictions are processed.
+
+If a user attempts to log in from a client that is not allowed by the
+host-based restrictions applied to that user, an error will be displayed
+on the login page:
+
+![](images/auth-restrict-login-failed-host.png)
+
+##### Users and User Groups
+
+As has been alluded to a few times, these additional login restrictions can be
+applied either to individual users, or, perhaps more helpfully, to entire
+groups of users. While the
+[processing order of the rules themselves](restriction-processing-order)
+is important, we'll take a moment to note, now, how restrictions work when used
+on users and user groups.
+
+First, if restrictions are applied to both users and a user group of which
+that user is a member, then the restrictions placed on the user will take
+precedence over those on the user group. So, for example, if you deny login at
+a certain time to a user group, but add a rule to a member of that group to
+allow logins at a time that overlaps with the deny time of the group, the login
+will be allowed. Conversely, if you've allowed logins for a group at a
+particular time, but you've denied a login for a specific user who is a member
+of that group at a given time, the login will be denied. Similar logic applies
+to the hosts and/or subnets rules that govern a user's ability to log in.
+
+Second, Guacamole attempts to pull all effective user groups of which a user is
+a member and process the restrictions across all of those groups. This
+includes nested groups, as well. The caution, here, is to be aware of what
+groups you're applying rules on and how those groups relate - if you rely on
+complex group nesting within your Guacamole installation, you can quickly
+create very complex restriction scenarios that make it difficult to sort out
+when a user can log in and when they cannot. Keeping your group nesting as
+simple as possible will help avoid these situations.
+
+#### Connections and Connection Groups
+
+This extension allows for the restriction of use of specific connections and/or
+connection groups (of the balancing variety) based on the same criteria by
+which you can restrict user logins - day/time of week and/or client address.
+
+The examples given above for user logins can be slightly updated to see some
+use-cases for connections. For example, you have an application that you
+provide access to via Guacamole that you'd like to make sure is only available
+during business hours. Or, perhaps, you have a balancing connection group that
+you want to make sure is only used by users who are logging in from inside a
+certain subnet within your firewall, and not from any public Internet clients.
+The user interface for these restrictions for Connections and Connection
+Groups is identical to the interface shown above for Users and User Groups.
+
+If a restriction applies to a Connection or Connection Group that results
+in a user being denied access to a connection, they will receive an error
+indicating that they do not have access to the connection:
+
+![](images/auth-restrict-connection-failed.png)
+
+(restriction-processing-order)=
+
+#### Restriction Processing Order
+
+When dealing with restrictions that add this level of complexity - multiple
+time schedules, user and user groups, and IP addresses and subnets - it's
+important to understand the order in which these restrictions are processed
+and how that ordering may impact how you apply those restrictions.
+
+Here are a few key items to keep in mind in terms of how rules are processed
+and how they may interact with one another:
+
+* System administrators are exempt from login restriction rules. If you apply
+  restrictions to either a specific user or a group, and a user who is a
+  system administrator attempts to log in, the restrictions will be bypassed
+  and a warning will be logged to the Guacamole log file.
+
+  However, restrictions applied to Connection and Connection Group objects
+  will apply to anyone who tries to connect, regardless of their status
+  as an administrator of the system or the individual connection.
+
+* When no additional restrictions are present, the login or connection is
+  implicitly allowed.
+
+* If only "allow" rules are added, the login or connection is implicitly
+  denied if those rules are not met. For example, if a rule is added to a user
+  group allowing logins between 09:00 AM and 05:00 PM, users who are members
+  of that group will be allowed during that time, but denied at any other
+  time, regardless of the fact that a deny rule has not been created.
+
+* If only "deny" rules are added, the login or connection is implicitly
+  allowed if those rules are not met. For example, if you add a rule to a
+  connection to deny access between 06:00 PM and 12:00 AM, access to that
+  connection will be allowed at any time that falls outside of the specified
+  deny rule.
+
+* Deny rules always take precedence over allow rules when there is an overlap.
+  If you create a time-based login restriction that allows logins at a given
+  time, and another restriction that denies logins at a certain time and these
+  times overlap, the login will be denied at any time that the Deny rule
+  applies, regardless of whether or not the allow rule also applies.
+
+  Similarly, when working with the host-based restrictions, if you allow
+  access to a certain IP address, but deny access to a subnet of which that IP
+  address is a member, the login (or connection) will be denied.
+
+* As mentioned above, individual user rules are processed before, and thus take
+  precedence over, user group rules. So, if a user is explicitly allowed or
+  denied, that rule will apply regardless of whether a rule on a group of which
+  that user is a member would apply.
+
+* Time-based restrictions are processed prior to host-based restrictions, but
+  both will be taken into account. If a user is configured to be allowed at a
+  certain time, but denied from a certain host, the login will be allowed if
+  both rules allow it and denied if either the time or host rule denies it.
+  The order, here, is only an issue in noting what error message the user may
+  receive during login or connection attempt - if both a time restriction and
+  a host restriction deny the action, then the error the user receives will
+  note the time restriction.

src/index.md

@@ -50,6 +50,7 @@ saml-auth
 radius-auth
 adhoc-connections
 auth-ban
+auth-restrict
 using-guacamole
 recording-playback
 administration