DACS_NOTICES(8)             DACS Web Services Manual             DACS_NOTICES(8)

       dacs_notices - DACS notice presentation and acknowledgement handler

       dacs_notices [dacsoptions[1]]

       This web service is part of the DACS suite.

       Some web service providers have a requirement that users must acknowledge
       a notice of some sort before access can be granted to an associated
       resource. A user attempting to access such a resource is shown a web page
       containing the notice and asked to acknowledge it or accept its
       conditions, typically by pressing an "I Accept" button on the web page.
       These notices are commonly legal notices, such as copyright notices,
       licensing notices, restricted access notices, and terms-of-use notices.
       This can also be applied to alert users to news (a warning about upcoming
       system maintenance, for example).

       dacs_acs(8)[2] (the DACS access control service, or ACS) can be
       configured to invoke dacs_notices when access control processing
       determines that one or more notices have not been acknowledged.
       dacs_notices acts as both a generic notice presentation handler (it
       retrieves notices, presents them to the user, and requests the user to
       acknowledge the notices) and a matching notice acknowledgement handler
       (executed to process the user's response and take appropriate action).
       The presentation aspect of the program can be customized. It takes steps
       to defeat attempts to bypass notice presentation.

       In the DACS implementation, a notice (N) is usually some text, identified
       by a URL. A notice is associated with one or more resources (R) such that
       an attempt to access any of these resources requires the user to first
       explicitly acknowledge the textual material. A DACS event handler (H) is
       responsible for presenting the notice to the user. The basic flow of
       control is roughly as follows:

                   USER                  |  Apache/DACS

             a)    --- Request for R --->|---> (DACS Access Control Service)
             b)    <--- Redirect to H ---|<--

             c)    --- Request for H --->|---> (a notice presentation handler)
             d)        <--- Return N ----|<---

             e)     --- Submit Ack N --->|-->  (a notice acknowledgement handler)
             f)    <--- Redirect to R ---|<--

             g)    --- Request for R --->|---> (DACS access control service)
             h)                <--- R ---|<--

       More than one notice can be associated with a resource, in which case
       they are effectively concatenated for presentation purposes and
       collectively acknowledged (so N may be N1, N2, ..., Nn and Ack N
       acknowledges all of them).

       Having already acknowledged N in a session, a user should not need to do
       so again.  dacs_notices uses a purely client-side approach; cookies are
       issued to remember that resources have been acknowledged. These cookies
       are called notice acknowledgement tokens or NATs. The implementation
       handles both authenticated and unauthenticated (anonymous) users. The
       cookie name consists of a prefix, the federation name, the jurisdiction
       name, and a unique component; see dacs.conf(5)[3] for a description of
       configuration directives used by this program, including the
       NOTICES_NAT_NAME_PREFIX[4] directive.

       The program accepts the standard FORMAT argument (see dacs(1)[5]) to
       select between generation of an HTML presentation page intended for
       display by a browser (the default) or XML output intended for middleware.
       Output customization applies only to the former. When generating HTML
       output, dacs_notices emits instructions, the content of the notices, and
       an HTML form by which the user submits a response.

           Of course, apart from answering a skill-testing question or the like,
           there's no way of knowing that a user has actually read and
           understood the notices. It is unclear to what extent it is necessary
           to go in this regard with respect to providing support.  DACS cannot
           guarantee that a human user has actually read these notices and
           indicated acceptance of them, but it can guarantee (optionally, using
           secure mode[6]) that a NAT cannot be obtained by a client without the
           client having received a copy of the notices. If the client wants to
           "trick the system" by not actually presenting the notices to the user
           or soliciting a response it can, and in this event the service
           provider might consider legal recourse.

       In future versions of DACS, the idea of notice/acknowledgement processing
       may be generalized so that an arbitrary condition can be tested for by
       access control rules, remembered through client-side state (for example),
       and made available via a seamless workflow.

       Configuring notice acknowledgement processing involves:

       •   Configuring an ACS_ERROR_HANDLER[7] directive to catch ACK_NEEDED
           (error code 905) events and invoke dacs_notices;

       •   Calling the ack[8] predicate from an access control rule to specify
           the notices that must be acknowledged; and

       •   Configuring dacs_notices.

       The following configuration directives are examined by dacs_notices. All
       of these directives are optional. Refer to the individual directives for
       additional details.

       •   NOTICES_ACK_HANDLER[9]: the URL of the notice acknowledgement
           handler, if not dacs_notices.

       •   NOTICES_ACCEPT_HANDLER[10]: the URL (absolute or relative) to which a
           user agent will be redirected after a positive acknowledgement to a
           notice has been received (i.e., the notice or notices were
           "accepted"), if it is not possible to redirect the user agent to the
           request that initiated notice acknowledgement processing (e.g., if
           that request used the POST method).

       •   NOTICES_DECLINE_HANDLER[11]: the URL (absolute or relative) to which
           a user agent will be redirected after a negative acknowledgement to a
           notice has been received (i.e., the notice or notices were

           When determining whether a resource has already been acknowledged,
           the query component of a resource URI is not considered.

       When emitting HTML, the web page generated by dacs_notices can be
       customized through the notices VFS item type. The following items are
       emitted if they exist:

       •   header: Initial HTML to emit.

       •   prologue: HTML to emit immediately after the header.

       •   instructions: HTML to emit immediately after the prologue and before
           the notices.

       •   epilogue: HTML to emit immediately after the form that follows the

       •   trailer: Final HTML to emit.

       For example, given the configuration directives:

           VFS "[notices]dacs-fs:${Conf::DACS_HOME}/notices"

       files named header and trailer in the directory
       ${Conf::DACS_HOME}/notices would be expected to contain the initial and
       final HTML content, respectively. Note that these consist of text and
       HTML markup but are not complete HTML documents.

       Customization of the form is possible using configuration variables:

       •   notices_prompt_text: This label appears immediately before the HTML
           form. The default is something like "Your response to the preceding
           notices is requested:<p>".

       •   notices_accept_label: This label appears next to the radio button
           corresponding to the "accepted" response. The default is something
           like "I Accept".

       •   notices_decline_label: This label appears next to the radio button
           corresponding to the "declined" response. The default is something
           like "I Decline".

       •   notices_submit_label: This label appears in the submit button. The
           default is something like "Send".

       Here are some examples of how these variables might be set to customize
       the form:

           EVAL ${Conf::notices_prompt_text} = "My &lt;b&gt;custom&lt;/b&gt; prompt:"
           EVAL ${Conf::notices_accept_label} = "I really do accept&lt;br&gt;"
           EVAL ${Conf::notices_submit_label} = "Submit me!"

   Web Service Arguments
       In addition to the standard CGI arguments[12], dacs_notices understands
       the following CGI arguments:

           The value of this optional parameter is used by the notice
           presentation handler and overrides the value of the
           ${Conf::notices_accept_label} variable, if any.

           The value of this optional parameter is used by the notice
           presentation handler and overrides the value of the
           ${Conf::notices_decline_label} variable, if any.

           This value is a secure keyed hash. It is computed by dacs_acs for use
           by the notice presentation handler. A hash is also computed (over
           different material) by the presentation handler and passed to the
           notice acknowledgement handler with the user's response and other
           information. Its purpose is to make it difficult to obtain a notice
           acknowledgement token directly by side-stepping notice
           acknowledgement processing. The federation-wide HMAC key is used.
           Please refer to the description of Secure Mode[6].

           Neither this argument nor the TIME[13] argument are used or required
           if the NOTICES_SECURE_HANDLER[14] configuration directive has the
           value "no".

           The value of this argument is a space-separated list of URIs, each of
           which is invoked using the GET method and is expected to return a
           notice document.

               The notices are expected to be fragments of HTML text, not
               complete HTML documents; each notice is "pasted" into the
               presentation page exactly as obtained from its URI.

           This is the Unix time at which dacs_acs invoked the notice
           presentation handler for this workflow. It is used to limit the
           lifetime of the workflow so that it cannot easily be rerun to obtain
           notice acknowledgement tokens at will.

           The value of this argument is a space-separated list of URIs, each of
           which is associated with the notice(s).

           Passed to the notice acknowledgement handler, this argument is the
           user's response and must either be accepted or declined.

   Middleware Support
       dacs_notices can be asked to emit various flavours of XML in support of
       middleware or thick clients. This is useful when middleware would prefer
       to prompt the user itself (acting as a notice presentation handler) and
       then invoke a acknowledgement handler (such as dacs_notices) to obtain a
       NAT. Any customizations specified for HTML output are ignored when XML is
       being produced and are not passed to middleware.

       The XML emitted by dacs_notices conforms to the DTD dacs_notices.dtd[15].
       When acting as a notice presentation handler, it returns a
       presentation_reply element and when acting as a notice acknowledgement
       handler, it returns a ack_reply element; in either mode of operation an
       error reply is possible (via the common_status element).

       In conjunction with dacs_acs(8)[2], dacs_notices can optionally operate
       in a "secure" mode, where a particular control flow is enforced.

       The simple (non-secure) mode will be described first.

       Simple Mode
           The presentation_reply element lists one or more notices that must be
           acknowledged by the user. It includes a space-separated list of the
           URIs of the notices and a space-separated list of the URIs of
           resources that require these notices to be acknowledged. The text of
           the notices are base-64 encoded within the notice element, as
           specified by RFC 2045[16] (Section 6.8). The notice's URI is included
           as an attribute.

           The ack_reply element returns the user's response and, optionally, a
           URI to which the user can be redirected (depending on the context,
           this may be the URI of the request that required notices to be
           acknowledged, the value of the NOTICES_ACCEPT_HANDLER[10] directive,
           or the value of the NOTICES_DECLINE_HANDLER[11] directive). If a NAT
           is issued, it is returned (as an HTTP cookie) by the notice
           presentation handler.

       Secure Mode
           The secure mode of operation, which may not be necessary in some
           environments, serves two main purposes:

            1. a NAT can be cryptographically protected against forgery and
               alteration. Refer to dacs.nat(5)[17].

            2. DACS can enforce a flow of control so that a client cannot obtain
               a NAT without having received a copy of the notice(s); this is
               the purpose of the hmac and time attributes. That is, DACS can
               make it necessary for the client to first call dacs_acs(8)[2]
               with -check_only or -check_fail, then call the notice
               presentation handler to get the text of the notices, and then
               call the notice acknowledgement handler to request the NAT. No
               other control flow is possible (ignoring errors).

           When combined, these protections make it difficult for an attacker or
           unfriendly user to bypass having to acknowledge notices by
           manufacturing NATs or having DACS simply issue arbitrary NATs.

           The value of the NOTICES_SECURE_HANDLER[14] configuration directive
           determines whether the secure mode is disabled; it is enabled by
           default (see dacs.conf(5)[3]).

           In secure mode, the total duration of the work flow is limited to 120
           seconds by default. This limit can be set using the
           NOTICES_WORKFLOW_LIFETIME_SECS[18] directive.

           Regardless of the selected output format, the required flow of
           control is:

            1. dacs_acs receives a service request

               Access to the requested resource will not be granted by
               dacs_acs(8)[2] until one or more notices have been acknowledged
               by the user.  dacs_acs either redirects the client to the notice
               presentation handler or returns an XML document
               (dacs_acs.dtd[19]) that describes which notices must be displayed
               and acknowledged; the behaviour depends on the service request.
               The notice presentation handler must be invoked and will expect
               to be passed the HMAC[20] and TIME[13] arguments.

               Provided they are in the same federation, the notice presentation
               handler may be in a different jurisdiction from dacs_acs.

            2. Notice presentation handler is invoked

               The user is expected to be presented with the notices and asked
               to accept or decline them. The handler either returns a web page
               containing an HTML form or an XML document
               (dacs_notices.dtd[15]). In either case, the handler will verify
               that dacs_acs had been called "recently" (the security-related
               arguments expire after a set amount of time and cannot be
               reused). Its output will include HMAC[20] and TIME[13] arguments,
               either of which may differ from the values passed into the
               program; the notice acknowledgement handler expects to be passed
               these arguments.

            3. Notice acknowledgement handler is invoked

               The user's response is directed to the notice acknowledgement
               handler, which verifies that the notice presentation handler has
               been called. The handler either redirects the user appropriately
               or returns an XML document (dacs_notices.dtd[15]). If no error
               has occurred and the user has accepted the notices, a NAT will
               also be returned.

               In secure mode, presentation handling and acknowledgement
               handling are "matched". If dacs_notices provides the latter
               functionality but not the former, presentation handling must
               behave as dacs_notices expects (in its acknowledgement handling
               mode) with respect to security. When secure mode is used with
               middleware that performs its own presentation handling, for
               example, middleware will likely need to invoke dacs_notices in
               its presentation handling mode solely to obtain security
               parameters to pass to dacs_notices in its acknowledgement
               handling mode.

               When dacs_notices acts as a notice presentation handler, it will
               validate its arguments (which originate from dacs_acs) and emit
               values that may be validated by the notice acknowledgement
               handler. When dacs_notices acts as a notice acknowledgement
               handler, it will validate its arguments. Therefore, if the notice
               acknowledgement handler runs in secure mode, the notice
               presentation handler must also run in secure mode.

               The presentation handling mode and the acknowledgement handling
               mode of dacs_notices must agree on the URL of the acknowledgement
               handler. This means that either the identical URL must be used
               for both modes or both modes must find the NOTICES_ACK_HANDLER
               directive configured to the same value (as when two different
               jurisdictions are involved).

       The program exits 0 if everything was fine, 1 if an error occurred.

       A client-side approach is used to note that resources have been
       acknowledged. While this is probably the simplest approach that works
       with both authenticated and unauthenticated users, it does not offer much
       support if one wants acknowledgements by authenticated users to be
       remembered across sessions (i.e., permanently). One possible solution is
       to allow persistent notice acknowledgements to be enabled for
       authenticated users, suppressing NAT cookies and causing a record to be
       written to a configured VFS item type when an authenticated user has
       accepted a notice. The ack() predicate would be extended so that the
       existence of persistent acknowledgement records could be checked, and
       some means of maintaining the persistent records might be added.

       The method used for generation of custom web pages is clunky and should
       be reconsidered.

       dacs.nat(5)[17], dacs_acs(8)[2]

       Distributed Systems Software (www.dss.ca[21])

       Copyright © 2003-2012 Distributed Systems Software. See the LICENSE[22]
       file that accompanies the distribution for licensing information.

        1. dacsoptions

        2. dacs_acs(8)

        3. dacs.conf(5)


        5. dacs(1)

        6. secure mode


        8. ack




       12. standard CGI arguments

       13. TIME


       15. dacs_notices.dtd

       16. RFC 2045

       17. dacs.nat(5)


       19. dacs_acs.dtd

       20. HMAC

       21. www.dss.ca

       22. LICENSE

DACS 1.4.40                        02/19/2019                    DACS_NOTICES(8)