Web URL Patterns

The Web URL Patterns window is used to configure domains or regular expressions that you wish to track with KeyServer. After specifying patterns in this window, “usage” (i.e. access) of those URLs will be tracked by clients in supported browsers Supported Browsers
Windows: Firefox, Chrome, Edge, Opera
Mac: Firefox, Chrome, Safari, Edge, Opera
Linux: Firefox and reported to KeyServer. Note that MacOS has special considerations. The URLs will appear as entries in the Programs window - which can then be added to products and policies much like traditional executable based programs. Once a policy has been made, KeyServer will record usage, which can then be reported in the same way as traditional program usage - looking at where URLs are accessed, how often, and for how long. As it becomes more common for software to have purely web-based components, this unified view of usage is important.

Adding Entries

You can create these patterns either in the dedicated window, or by way of making a new web-based product. For the latter, see New Product Wizard. It is generally considered easier to create the Pattern in the process of making the Web Product, which makes the Program entry in the background.

Config Window

Open this from KeyConfigure - Config - Web URL Patterns. You will see this same interface when stepping through the new Product wizard. First you will need to click the + button at the bottom left to add a new pattern. You will be prompted to choose between a domain or a pattern. If you want to track a single domain all as a single object, use the Domain choice and enter something like example.net. Then any URLs within example.net will all be reported as the same entry in the programs window. Note that when using this option, matching URLs (i.e. "hits" by the client) must start with http:// or https:// - “ftp://ftp.example.net/” will not match and won't be recorded. You can also enter the exact Identifier you would like to use for this domain - or if you leave it blank an Identifier will be generated for you, e.g. “@example.net”.

     

If you need more flexibility than this, you should use a Pattern instead. Using a pattern allows you to target a specific URL or set of URLs within a single domain, e.g. “mysite.org/private/”. You can also use a regexp pattern, e.g. “^https?://[-a-zA-Z0-9_.]+\.ly/”. When specifying a pattern, you must explicitly choose an Identifier, you can not click Add with the field blank. For consistency and simplicity we recommend Identifiers start with the @ symbol and contain no spaces or special characters other than dash.

     

After you have added new Domains or Patterns, clients will learn about it, but a client computer reboot may be needed. Additionally, any running browser when a pattern is created or changed will absolutely need to be quit and relaunched for the new pattern to be recognized. Once a client learns a new pattern, it will notice when that pattern is accessed in any major browser, and report this to KeyServer. The first time KeyServer learns of a new Identifier an entry will appear in the Programs window and it can then be used in a product. It is important, whether you add a Domain or a Pattern of your own, that you test to see that it is working as expected - identifying the expected URLs and not identifying additional URLs. To do so you will first need a Product and Policy to begin gather usage (access to) the URLs.

You can also add new Domains or Patterns within the Product Wizard. When added via the Product Wizard, a program entry will be created with the identifier, which is added to the new Product.

Additional Details

Creating a Pattern requires knowledge of regular expressions. While there are plenty of resources for these, frequent confusion has indicated some common use cases and examples are prudent.

• A period is a special character in regex. As such it needs to be escaped with \ to be literally interpreted as opposed to being a wildcard.
• A question mark indicates the prior character or grouping is optional in the string. As such if this was important in a URL it would need to be escaped or the pattern would not work as expected.
• You can specify a grouping to account for sub domains or the optional www prefix.
• URLs may or may not end with a trailing slash so it is best to not include this otherwise it is required to trigger the pattern.
• All patterns start with ^

Putting all these items together you may have a pattern like ^https?://([-a-zA-Z0-9_]+\.)?somedomain\.com/account. This indicates (as we read through it) the pattern starts with http and might include an s but does not have to, with normal :// url syntax. Then we allow for the possible presense of any alphanumeric characters in any order or quantity possibly existing as a sub domain. This means anything.somedomain.com will trigger the pattern, but more generally www.somedomain.com or just somedomain.com will both trigger it as well. We then escape the . in .com and end the pattern with /account. This means the base url of somedomain.com will not actually trigger the pattern as it does not end with /account, but /login would not trigger the pattern. If we removed the ()? grouping then sub domains would not trigger the pattern. It is advised you make a paterns as specific and simple as possible to avoid possible unexpected results in matching.

Note that you can Edit an existing pattern, but if you change the Identifier you will need to allow a new Program to be created on first access which can then be updated in the Product. In other words, it's often easier to delete a pattern and related Product and make a new Web Product instead.

Note the blue bars on the left of the pattern list. This indicates the order the patterns were added to the server, as well as the order they will be processed in. These can not be altered, so the priority is set by order of creation. This means if you need to target a more specific pattern before a more general one (or domain), you must create them in the order of most specific to most general. If they are in the reverse order, the general pattern will catch the specific URL, and your specific pattern will never be triggered.

Limitations

Note that KeyAccess 7.5 or higher is required to be able to track URLs. Also, while URLs can be tracked (as well as do things like display grant messages), KeyAccess cannot prevent any pages from loading. A supported browser Supported Browsers
Windows: Firefox, Chrome, Edge, Opera
Mac: Firefox, Chrome, Safari, Edge, Opera
Linux: Firefox must also be used, the agent will not see use by other browsers. Due to technical limitations, in some browsers despite the site being accessed it may not be seen as in use if the tab in question is not the active tab. This does mean that usage data will be somewhat incongruous with the actual authenticated use of a SaaS site for example.

Since URL access cannot be blocked, we recommend policies for products that contain URLs be configured in such a way that they will not try to prevent usage. Specifically, they should be Observe policies, Manage policies with the Site metric, or Manage policies with other metrics but with an Enforcement option of “None”. Finally, any options such as Background Warning, Queue & Notify, etc should be avoided as they could result in KeyAccess presenting confusing messages to the end user.