0 Replies Latest reply on Dec 1, 2015 10:11 AM by mitchese

    How-To: Setup Coaching with Administrator Approval

    mitchese

      Introduction

       

      This short document will describe how to set up a block page with an approval.  The normal coaching process presents a user with a block-page, and if the user clicks a button an exception is created automatically, and the user is then allowed to visit the site for a specific period of time. This document will describe how to set up a similar process; however an administrator approval is required before the user can access the website. The overall process is as follows:

      1. User visits a site, which is blocked for any reason (ex. category, reputation, file type, etc)
      2. User receives a block site, which asks the user to enter a justification for an exception
      3. After filling in a reason, the user is informed the request is received and will be answered shortly. In the background, an email is generated to an administrator.
      4. The administrator reviews the email, which contains the user, his or her entered reason, the requested URL, the entire domain (which will be granted for 24 hours), and a link to a special mwginternal.com URL to click if this is acceptable.
      5. When the admin clicks the link, the web gateway checks to ensure the admin is allowed to open URLs, and if so, creates a 24 hour exception in the PD Storage for the particular user and domain
      6. The user is then able to visit the entire domain for 24 hours

       

      Setup the relevant block pages

       

      This procedure requires a number of block pages to interact with the user and the admin. The following are required:

      1. Extension of the "Site Blocked" coaching page, that allows the user to enter a reason.
      2. New page "Your request has been received and will be approved shortly".
      3. New page "Admin: Request accepted and user allowed".
      4. New page "Admin: you don't possess the required rights to override URLs for users" (I use the "access denied" default page).

       

      The first block page is the only page that is tricky and requires a few hidden details:

      Selection_122.png

      This page is the default block page, with the following added to it:

      Selection_125.png

      All the details are in the form itself, so technically, a user could modify the form and have the approved domain not match the original URL; this is left up to the admin to check, as both are contained in the approval email.

       

      The entire block page is as follows:

      <table class='titleTable' background='$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.enduserurl"/>$/files/$<propertyInstanc e useMostRecentConfiguration="false" propertyId="com.scur.engine.proxy.message.collection"/>$/img/bg_navbar.jpg'>

        <tr><td class='titleData'>Starting new Coaching Session</td></tr>

      </table>

      <table class="contentTable">

        <tr><td class="contentData">

            If you want to continue to this page, please enter a valid reason below and press "<b>Request 24h Exception</b>".

          </td></tr></table>

      <table class="infoTable">

        <form id="activateform" method="get" action="$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.enduserurl"/>$">

        <tr>

          <td class="confirmData">

            <p>In order to access this resource, an administrator is required to approve your access. Please enter a <b>valid business reason</b> that you need to access this resource.</p>

          </td>

          <td class='formData'>

            <input type="hidden" name="approvalrequest" value="True" />   

            <input type="hidden" name="user" value="$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.stringfilter.base64encode">

        <parameters>

          <entry>

            <string>com.scur.engine.stringfilter.base64encode.param</string>

            <parameter valueTyp="2">

              <value>

                <propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.auth.username"/>

              </value>

            </parameter>

          </entry>

        </parameters>

      </propertyInstance>$" />

            <input type="hidden" name="url" value="$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.stringfilter.base64encode">

        <parameters>

          <entry>

            <string>com.scur.engine.stringfilter.base64encode.param</string>

            <parameter valueTyp="2">

              <value>

                <propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.url"/>

              </value>

            </parameter>

          </entry>

        </parameters>

      </propertyInstance>$" />

            <input type="hidden" name="domain" value="$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.stringfilter.base64encode">

        <parameters>

          <entry>

            <string>com.scur.engine.stringfilter.base64encode.param</string>

            <parameter valueTyp="2">

              <value>

                <propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.url.domain"/>

              </value>

            </parameter>

          </entry>

        </parameters>

      </propertyInstance>$" />

            <input type="text" name="reason" size="66">

            <input class="button" type="submit" id="activatebutton" value="Request 24h Exception">

            <br />

          </td>

        </tr>

      </form>

      </table>

      <table class='infoTable'>

        <tr>

          <td class='infoData'>

            <br />

            <b>URL: </b>

              <script type="text/javascript">

                computeLastQuotaURL("$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.url.raw"/>$","$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.enduserurl"/>$/plugin?target=QuotaPlug in&quotatype=");

              </script>

          </td>

        </tr>

        <tr>

          <td class='infoData'>

            <br />

              <script type="text/javascript">

                writeToDocument("<b>URL Categories: </b>" + "$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.trustedsource.categorylist.tostring">

        <parameters>

          <entry>

            <string>com.scur.engine.trustedsource.categorylist.tostring.categorylist</strin g>

            <parameter valueTyp="2">

              <value>

                <propertyInstance useMostRecentConfiguration="true" propertyId="com.scur.engine.trustedsource.url.categories"/>

              </value>

            </parameter>

          </entry>

        </parameters>

      </propertyInstance>$" );

              </script>

          </td>

        </tr>

        <tr>

          <td class='infoData'>

            <b>Quota Type: </b>Coaching

            <br />

            <br />

          </td>

        </tr>

      </table>

      <!--/Info-->

       

      The remaining block pages can be created as you wish, as they're nothing special. After the user requests an exception, they are presented with something similar to the following page:

      Selection_126.png

      You will also need two administrator block pages, to return to an administrator if the request was successful or they were not authorized. Again these contain no special information other than text explaining the actions performed, and are therefore not included here.

       

      Rule Process

      An XML Export of this rule is included at the end. It consists of the following procedure:

      Selection_127.png

       

      The first ruleset deals with administrator approval links. The second ruleset contains the rules applied to the user.

       

      The users' rules are handled from bottom to top. The image below illustrates a typical request cycle: When a user visits a site in a blocked category [1], he/she is presented with a block page [2].  This is the block page from above, which contains the reason.  After entering a reason for the exception and clicking submit, condition [3] evaluates as true and the user ends up at block page [4], which is the "We are working on your request" page. At the same time in the background, [5] is taking place, which generates an email. In the above example, this is written out to a log file, but the action can be changed to send an email.  Finally, after the administrator clicks an approval link, the user and the host are in the PDStorage, so the user lands on [6] and is allowed to visit the URL.  After 24 hours, the pdstorage expires and the user is again blocked, requiring another exception. To increase or decrease the 24 hour exception, simply change the timeout on the PDStorage.

      Selection_128.png

      The admins' rules are handled from top to bottom. The image below illustrates the flow for the admin approval process. If the connection is to mwginternal.com and the path matches our /addcoach-pdstorage, we ensure the authenticated admin user is in a group of users, who are allowed to add exceptions. If they are, we block with a page stating the exception was successful, and in the background, add the information to the pdstorage.  If the admin was not in our list of accepted user groups, then we block the request with the authorized only page, and do not run any actions.

       

      Selection_130.png

      An example of the text generated is:

      Selection_129.png

       

      Areas for Improvement

      This was done quickly "to see if it could be done purely in Web Gateway". It would be better to do it in a standalone application that could maintain an external list; however, this would have been significantly more effort and blown the time budget. There are a number of limitations/problems, which include the following:

      1. mwginternal.com came afterwards, as authentication with kerberos did not like when we spoke directly with the proxy; the screenshots here don't reflect this as it was done on a test system using internal authentication.
      2. Authentication must be turned on. The key in the pdstorage is the username, which cannot be blank.
      3. Rudimentary sanity checking: the pages always return success. If for some reason the email doesn't send, the user is still informed that "your request has been received". Same problem for the admin: it will always state the PD Storage has been updated, even if there's a problem and it has not updated.
      4. Unaware of performance on large installations.
      5. The admin, when approving, needs to inform the user manually that their request is approved.  A better option may be to include the email address as described here, and automatically send an email to the user when it's approved.