General security options

Create a public knowledge base

To make your knowledge base public and available to anyone with the link:

  1. Go to Settings > Security.
  2. Set the Default Access to Public.
  3. Save your changes.

If your site is public, it can show up in Google and other search engines.

Learn more about search engine optimization in our SEO guide.

Create a public knowledge base with some private content

To make some content private on your public knowledge base, you can create a reader group (or groups), restrict content to the appropriate group, and require readers to log in to get access to the reader group restricted content.

To log in readers to your site to access the restricted content, you can add a reader login/logout button to your website or use one of the other authentication methods like single sign-on or remote authentication to automatically authenticate certain readers.

To add a reader login/logout button to your knowledge base:

  1. Go to Settings > Basic.
  2. In the Website Settings section, check the Top navigation box next to "Add a reader login / logout link".
  3. Save your changes.
  4. Check that the login link appears in your knowledge base by going to Settings > Style.
  5. Below the preview pane, select Custom HTML, then select the dropdown that appears and select Top Navigation.
  6. The login link will be added wherever the [template("login")] appears.

Create a private knowledge base

You can choose to make your knowledge completely private, meaning that no one will be able to access it without some type of login, password, or shared IP.

You can make your knowledge base private by going to Settings > Security and choosing one of our available security options:

  • Restrict by reader logins
    Readers will be required to log in with a username and password. Users with full account admin access can set up readers, reader groups, and reader settings under Your Account > Readers (or Account > Readers for users with admin access to readers). Learn more in our Reader Management guide.
  • Restrict by IP or shared password
    Readers will need to be coming from a specified IP address or enter a shared password to access the site. You can also choose to require both an approved IP address and a password to log in.
  • Remote authentication
    Readers will be required to log in through a 3rd party site, such as your own website or application. You can use this option to automatically log in readers from your software. You'll need to configure remote authentication in Settings > SSO.
  • SAML SSO (single sign-on)
    Readers will be required to log in through your specified identity provider, such as ADFS, Okta, or G Suites (Google Apps for Work). Configure this in Settings > SSO. See Single sign-on (SSO) for more information.
  • Salesforce SSO (single sign-on)
    Readers will only be able to log in through your Salesforce account. Configure this in Settings > SSO. See our Salesforce SSO Configuration guide.

Create a private knowledge base with different content for different readers

To restrict content access in a private knowledge base, create reader groups for the different segment of your audience and restrict your content to the appropriate reader groups. When you create readers in KnowledgeOwl or log them in using single sign-on (SSO) or remote authentication, assign the readers to the appropriate groups.

To learn more about readers, read our Reader Management guide.

Security Setting

The security settings under the Settings tab are mostly centered around the needs of private or internal knowledge bases. By default, your knowledge base will be visible to the public which means anyone can peruse your content. However, under Settings > Security, you have quite a few options.

When would I use the different types of security?

Restrict by reader logins

Readers offer the most power in terms of authentication to your knowledge base. Essentially a reader is an individual login for each person or group whom you want to give access to your knowledge base. With this setting turned on, a person trying to access your knowledge base will be asked for a username and a password which we can then use to identify who they are. Once they log in, they will remain authenticated for 2 hours and can browse normally. If you select this option, you will need to set up readers under Your Account > Readers.

You can also choose remote authentication, Salesforce SSO, or a SAML SSO integration to create readers using existing credentials.

Restrict by IP address

This setting is great for internal office knowledge bases. If you can track down the IP addresses that your office uses, you can paste the comma separated list into the box and ensure that no one trying to access your knowledge base from outside of your office can get in.

You can also use the /24 subnet mask for a range of IP addresses; at this time, we only support the /24 subnet mask.

Restrict by shared password

This one is great if you need to restrict access to your knowledge base but you aren't sure of your office's IP addresses or if your readers are going to be spread out. Creating a single password that you can give to everyone will allow you to control who gets in but will allow for more flexibility.

IP-based Restriction OR Shared Password

You can also use the shared password setting in combination with the IP protection setting for even more flexibility. What this means is that while someone is in your office, on an approved IP address, they won't have to worry about logging in because they are accessing the knowledge base from an approved IP address. If they work from home one day though, they will be asked for the shared password to log in.

IP-based Restriction AND Shared Password

Need more security? You can select to use IP-based restriction as well as a shared password for two-factor authentication.


Restrict Content to Logged In Readers

You can restrict some content so that it is only visible to specific readers. To do so, create a reader group or groups and then restrict the category or individual articles to that group.

Restrictions can be set:

  • At the category level: restrictions set in the Restrict to Groups section will automatically be inherited by all subcategories and articles in the category.
    • Groups inherited from a category are identified in the Inherited Restrictions section of the editor.
    • By default, articles and subcategories are set to "Use Inherited Only" (they will only use the groups they've inherited from the category).
    • You can add additional groups to individual subcategories and articles by using the Add More Restrictions checkboxes within those pages.
  • At the article level: if an article has no inherited restrictions: restrictions set in the Restrict to Groups section apply only to the individual article and don't impact other articles or categories in any way.
    • If an article has inherited restrictions: by default it is set to "Use Inherited Only", but you may Add More Restrictions to require additional group membership to view the article. Add More Restrictions selections don't impact other articles or categories in any way.

Restrict access based on Reader Groups

  1. If you do not have your reader groups set up, you will need to set them up by following these instructions
  2. Create a new category or article (or edit an existing one by clicking on the wrench icon to the right of any content) inside Knowledge Base > Articles.
  3. If the category or article has "None" in the Inherited Restrictions section of the editor:
    • Use the checkboxes under Restrict to Groups in the right-hand column to set which groups can see this content:
      Sample Restrict to Groups section; the groups listed here will vary based on your setup
  4. If the category or article has groups listed in the Inherited Restrictions section of the editor:
    • Use the checkboxes to Add More Restrictions to the the content. Readers will have to belong to at least one of these additional groups AND at least one of the inherited groups (possibly more, depending on your knowledge base logic; see How do reader groups work? for more info).
  5. Click Save

For more information on how reader group work and what happens when you restrict to multiple reader groups, see How do reader groups work?


Requiring login to view files/images

The Security Settings for your knowledge base (Settings > Security) determine the general security requirements for readers to access your knowledge base.

The files you upload to your knowledge base--PDFs, Excel sheets, screenshots, Word documents, etc.--do not automatically use this same security.

By default, even if your knowledge base requires login, the files you've uploaded do not require login. This is by design so that you can give customers the link to specific documents and they can easily download the file by clicking on that link or URL without having to log in to your knowledge base.

However, you can adjust your security settings so that readers have to be logged in to access files and images stored within your knowledge base.  If you make this change, the URLs you'll see will change slightly to a different cloudfront URL.

With authentication required, if you share a hyperlink directly to a file stored in KnowledgeOwl, anyone accessing that link will be prompted to log in to the knowledge base using the default authentication method before they'll be able to view the file.

If you would like to require that someone must log into your knowledge base before accessing these:

  1. Go to Settings > Security.
  2. In the Reader Options section, check the Image / File Resources box next to "Require authentication to view any image or file from your file library."
    Check the box here to require login to view all files and images
  3. You'll receive a warning asking you if you're sure you want to do this. Click Cancel to keep files unauthenticated; click Proceed anyway to continue with requiring login to view files.
    File authentication confirmation screen
  4. Be sure to Save your changes.

Some customers who require file authentication have noticed some issues with their upper left logos not loading properly on initial page load. If you make this change and notice issues with your logo, please contact us and let us know you're having issues. We can move your logo file to unrestricted storage so it will load faster.

HTTP response headers

In order to improve the security of your knowledge base, you enable some additional HTTP response headers that will be returned by our servers that give additionl instructions to the end user's browser. The affects of these headers vary and should only be enabled by someone with a clear understanding of what they do.

You can find these settings under (Security > Settings) under the HTTP Response Headers section. Below we'll provide a brief high level description of what each of these headers is used for.

HTTP Response Header Options


HTTP Strict Transport Security (HSTS)


The HTTP Strict Transport Security header informs the browser that it should never load  a site using HTTP and should automatically convert all attempts to access the site using  HTTP to HTTPS requests instead. MDN Web Docs


X-XSS-Protection: 1


Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts). MDN Web Docs


X-Content-Type-Options: nosniff


The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured. MDN Web Docs


X-Frame-Options: SAMEORIGIN/DENY


The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. MDN Web Docs


Content-Security-Policy


Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware. MDN Web Docs
This header has the most potential to cause unintended consequences for your knowledge base. If you are referencing any remote javascript, fonts, images/files, or css, you will need to make sure you add the remote domains into this policy or they will be blocked.

Defining the script-src or default-src portion of the policy may also prevent the KnolwedgeOwl modern widget from rendering (Widget 2.0 will not be affected).