WEBDOXXDRM

From Drumlin Security Wiki
Revision as of 16:43, 20 August 2022 by MikedeSmith (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Webdoxx provides options for public or private access to documents, with shared/automated service operation, managed service operation, or dedicated service delivery. The principal options are described below with the full user management dashboard shown in the screenshot. With the shared/automated service (Webdoxx PDF2HTML5) the user management facilities enable users to be added and membership of specific USERGROUPS assigned, with optional data expiry and concurrency controls. For managed and dedicated managed Webdoxx services a full range of service management facilities can be provided, including USERGROUP creation and management, activity tracking, service configuration management, direct server access (via FTP) and more. The Weboxx DRM service is essentially a form of membership access control facility, and does not seek to provide per-user permissioning although that is possible. As such it is ideally suited to closed user groups, such as participants in training courses, students accessing courseware, directors or other specific user groups permitted to access Board papers and minutes, etc. It can also be used for access to large, complex documents, such as technical manuals, legal documentation and taxation or other regulatory materials.

User Management Dashboard

DRM for web access control

Public access

With public access documents can be available for display by anyone who is given the relevant URL for a document, or is provided with access via a third party website or portal using an iframe to a Webdoxx server or display a local server. Access control systems on the third party facility may be separately implemented for such 'public' access files. Public access can be with or without access logging and with or without overlaid watermarking (e.g. IPAddress, Date/time etc). Examples of public access with restrictions on copying, downloading, printing include public consultations, standards recommendations, membership rules, distribution of proposals/offer documents (e.g. for Union negotiations) etc.

Private access

With private access documents can only be displayed by users with access permission for that specific document, i.e. the URL for the document is protected against access by the public. Typically access is control via the Webdoxx User Management service, or Javelin/Sitelok system. Details of this service are provided here and fuller User Management documentation is also available.

There are several elements to the security framework: (i) conversion of the source PDF to HTML5 with page separation, text separation and image or scalable vector graphic (SVG) page element rendering; (ii) encryption of the HTML5 access page using industry-standard javascript-based methods and controls on printing, copying, selection and downloading; (iii) provision of session-based secure access to each document using a server-based user management framework with a range of concurrency controls; (iv) overlaid user-specific watermarking; (v) usage tracking by user and document; (vi) https based hosting; (vii) optional iframe-based embedding; (viii) optional pre-watermarking of source PDFs; (ix) controls over direct access to resources; (x) non-retention of uploaded PDF, PPT or EPUB files; (xi) optional IPaddress-based access controls. Media assets such as mp4 audio-visuals, can be hosted in a special folder and linked from the converted PDF - the videos can only be accessed via the link(s) on the converted secured file on the server and not via direct URL links. Alternatively publishers can use a protected video streaming service, such as Vimeo, to provide their media assets

The default setting for user access allows users to login from more than one device at the same time. There are several reasons for this being the default service access setting, including: (i) web-based access by groups of users can be provided without requiring every user to be separately registered - with manual or auto-login facilities; (ii) in general web browser users do not explicitly log out of services, so unless multiple logins are permitted a genuine user could be locked out until the auto-timeout period had expired (session-based and/or inactivity); (iii) a user may wish genuinely to log in simultaneously on different devices with the same username (e.g. all students in a class). However, user access can be restricted to a specific number of browsers/devices on a user-by-user basis - the Concurrency field can have a counter value, e.g. 1, 2 or 3 in it. If there is a value in this field it will restrict the user to a total of that specific number of web browsers/devices (i.e. specific browsers on specific devices). Each time a login occurs on a new device/browser combination the Concurrency field count is reduced by 1. This facility is based on the use of cookies. In addition/as an alternative, the number of concurrent logins from any devices/browsers can be controlled - this does not rely on cookies so is more powerful in many ways. This option is currently only available on our WEBDOXX "managed" service. For more details please contact us to discuss your requirements. see also, IPAddress autologin control below

User-specific (Private) Display

Access control is provided via our Javelin/Sitelok session-based user management facility. In addition to the Public Access control features, each uploaded and converted document can be protected by customer-specific usernames/passwords, IPAddresses or address ranges, and Customer Group membership. See the Webdoxx FEATURES page or contact us for more details. The principal means of providing user access control is by the user of "Usergroups". Users are assigned to USERGROUPS in order to provide additional access control. For free and Public access access is automatically "open" with no user access controls. For Corporate and Enterprise subscribers pre-allocated or definable Groups are provided in order to enable users to be restricted in their access to their own subsets of documents - e.g. course modules, conference proceedings or departmental documents.

The core steps on the Webdoxx automated service (pdf2html5.com) are:

(i) when you upload a PDF file, you should specify the conversion as PRIVATE not PUBLIC, otherwise there will be no login prompt to restrict access. A PUBLIC file is not protected and anyone with the URL can access it

(ii) after creating the converted "private" file, select the FILES menu and you will see your file there and it will say "private" against the item - you will be able to select the EDITGRP button and it will allow you to associate a usergroup (e.g. Usergroup ABC123) with that file. This restricts access further, to only allow users who are members of the ABC123 usergroup to view that file. If you select "view in browser" from this list, it will show you the URL for that file (it is also included in the email the service will have sent you). Copy the URL for the end users

(iii) logout, and then access the URL of the private file - it will ask you for a USERNAME and PASSWORD - use the one you set up for an end user with permission to view that file - this will work because that user is (a) registered by you, and (b) is a member of the ABC123 usergroup

Manual or Auto-login by username/password or IPAddress block

Users wishing to access the secured file can be provided with their own username and password in order to access your secured files, or can be provided with a common (shared) username and password, and/or can be logged in automatically via an augmented URL. This facilitates autologin with the specified username and password and/or IPAddress details, plus on-screen display of the optional name value.

Page controls

The access page for each document can be encrypted and as standard includes basic security controls, including no printing, no right mouse clicking, no downloading, no text copying. For all file formats the source document (i.e. PDF, PPT, EPUB files) are not stored on the server (unless dynamically generated), so cannot be accessed or downloaded by hackers.