• Time Maps
  

  Create isochrone shapes showing the area around an origin which can be reached in a given time period and using a specified mode of transport.

  
  
  
  
• Routing
  

  Retrieve directions for your journeys. Configurable options include the start or arrival date/time and a mode of transport,

  
  
  
  
• Rank Points
  

  Upload a collection of origin and destination points along with a mode of transport and maximum journey time. Travel Time will return only the destinations which can be reached in the given time period along with the distance and time taken to reach the location.

  
  
  
  

Download

Example

Remote IOK example URL

Remote URL Pattern option value

External URL visited in browser

A note about security

Headless server configuration

1. URL Redirection: redirects incoming client requests to a different host/context
   This technique allows you to make a web address/context available under more than one URL address.
   It can be used for URL shortening, to prevent broken links, to allow multiple domain names to refer to a single Omniscope Mobile. (more info here)
   
   Host redirection
   For instance, the following configuration allows to redirect the client, that was navigating to "alpha.omniscope.me", to the different "https://omniscope.me" host.
   
   e.g. it redirects from "http://alpha.omniscope.me/folder/file.iok" to "https://omniscope.me/folder/file.iok"
   
   Context redirection
   Another example is to redirect requests to a particular context (e.g. link to a particular IOK file)
   Say that your server is serving at "http://server.domain" and you want to redirect "http://server.domain/dashboard" to the full link "http://server.domain/MyDefinitelyBeautifulDashboard.iok". The following configuration allow you to do so.
   
   e.g. it redirects from "http://server.domain/dashboard" to "http://server.domain/MyDefinitelyBeautifulDashboard.iok"
   
   Host and context redirection
   This example combines host and context redirection.
   Say that you server is serving at "http://alpha.omniscope.me" and you want to redirect the "/demo" context to a different host "https://demoserver/" and different context "/MyBeautifulDashboard.iok". Then use the following configuration
   
   It will redirect from "http://alpha.omniscope.me/demo" to "https://demoserver/MyBeautifulDashboard.iok".
   
   To redirect all incoming requests to a particular context regardless your server host/virtualhost name, then leave the VirtualHosts field empty.
   
   N.B. by specifying the Redirect from field you define which context has to be redirected.
   If you leave it blank then the URL redirection will be applied on all the incoming requests. In this case it is better if you perform redirection to a different host by specifying a full URL in the Redirect to field (e.g. "https://differentHost/pathTo/file.iok")
   Be aware that misconfiguration may create redirect loop error.
   
   
2. Redirect HTTP to HTTPS: redirects all incoming HTTP requests to HTTPS.
   If the HTTPS protocol is enabled, this option will configure your server to serve the content only through the HTTPS secured channel.

Tab selection when printing and creating PDFs (Omniscope Mobile)

BOM support for UTF data files such as CSV

Support for "Show no records watermark" option (Omniscope Mobile)

Excessive rounding in Bar/line value labels (Omniscope Mobile)

• Go to this post for instructions on how to enable exporting.
• Go to this post for instructions on how to configure branding.

Setting up branded exports

1. Move your XLSX file into the 'branding.internal/mobile/app' folder related to the relevant IOK.
2. Copy the 'export_view.xml' file to the same location.
3. Edit the contents of the XML file using the instructions below.
4. Run your IOK file using Omniscope Mobile Server and click the export button on any view.
   

Configuring the XML

Admin web server

Mobile web server

App

Omniscope (Desktop/Mobile sharing)

Further information

1. Looks for branding.internal\app in the folder that contains the IOK that it is loading.
2. If found, uses that, otherwise, goes into parent folder and does the same as 1. It does this all the way up to the mobile sharing folder. Note, if the folder that Omniscope is using to display the resource is protected, then the user will be prompted to enter authentication details.
3. If it can’t find it the resource in the mobile sharing folder, it will check installed branding folder (branding folder “branding” installed in the Omniscope installation directory). No authentication is required to access resources from installed branding.
4. If it can’t find the file, it will check if the file is bundled with Omniscope, otherwise throws a File not found error.
Note: This allows you to have a possibly a generic branding inside some folder, which all sub-folders will inherit. One only needs to customise or place specific resources they want to override in the sub-folders.

1. Configure security options as needed
   
2. Enable port forwarding on your external network firewall
   
3. Buy a domain name
   
4. Configure the domain to point to your firewall's external IP address
   
5. If using user logins, you should also buy an SSL certificate and configure HTTPS only access.
   

• Download as PDF, the server will generate and send to client a PDF file containing all the IOK file tabs captured as high quality images page by page.
  
• Print..., the server will generate a printable HTML report, made of all IOK file tabs high-quality images, that will automatically prompt the end-user native browser print dialog.
  

• Ticking Use current browser size will generate a report that follows exactly the same app proportions (e.g. views, filters) as seen by the user in their browser.
  
• Unticking the option will produce a A4 friendly landscape format report, in which the app proportion will be adapted to the A4 ratio.
  

Features always available

• Ability to filter individual devices.
• Ability to change the tab.
• Ability to do selection.
• Ability to use Map view controls.
• Ability to use Data titles (if shown) to change i.e. Split by in Bar view.

Features disabled in Viewer mode

• Ability to show/hide filters.
• Ability to show/hide maximise button.
• Ability to show/hide view menus.
• Ability to edit tab layout (design mode) i.e. for adding/removing views.

How to restrict to Viewer mode

Permissions

• listDirectory : allow users to list existing files and subfolders
  
• downloadFile : allow users to download the IOK files
  
• viewInMobile : allow users to launch the Omniscope Mobile app for the existing IOK files
  
• fileManagement : allow users to upload IOK files, rename and delete resources, create new folders in the folder
  
• getStatic : allow users to get/access static resources from the folder, and to customise default styles (e.g. logo, icons, css files)
  
• viewServerState : allow users to view the server state through a monitoring page
  

User Credentials

• username : in clear text
  
• password : hash encrypted string using MD5 algorythm. As reference you can use this link to generate the hash.
  

folder.xml file structure

• Anonymous section
  The <anonymous> element describes the unauthenticated permissions, and is also used as default values for per-user permissions.
  Unauthenticated public access will be given these permissions. Any false/missing permissions will require authentication.
  
• Users section
  The <user> element describes the credentials and the permissions per user, and is made by the following elements/attributes:
  
  • Enabled : whether or not the user is enabled.
    
  • Credentials : the user username and password
    
  • Permissions: the user permissions that will override the anonymous ones
    
  
  

folder.xml example

Common use cases:

• Anonymous access not allowed, Admin user full permissions, Guest users browse and play IOK files
  <?xml version="1.0" encoding="UTF-8"?>
<mobilefolder>
<anonymous>
<permissions listDirectory="false" downloadFile="false" viewInMobile="false" fileManagement="false" getStatic="false" viewServerState="false"/>
</anonymous>
<users>
<user enabled="true">
<credentials>
<credentials username="admin" password="9aeb94180027a7081352cba05e6a3782" />
</credentials>
<permissions>
<permissions listDirectory="true" downloadFile="true" viewInMobile="true" fileManagement="true" getStatic="true" viewServerState="true" />
</permissions>
</user>
<user enabled="true">
<credentials>
<credentials username="guest" password="4aeb93180027a708186hy4505e6a6465" />
</credentials>
<permissions>
<permissions listDirectory="true" viewInMobile="true" getStatic="true" />
</permissions>
</user>
</users>
</mobilefolder>

  
• Anonymous can browse folders, no Admin user, Guest users browse and play IOK files
  <?xml version="1.0" encoding="UTF-8"?>
<mobilefolder>
<anonymous>
<permissions listDirectory="true" getStatic="true" />
</anonymous>
<users>
<user enabled="true">
<credentials>
<credentials username="guest" password="4aeb93180027a708186hy4505e6a6465" />
</credentials>
<permissions>
<permissions listDirectory="true" viewInMobile="true" getStatic="true" />
</permissions>
</user>
</users>
</mobilefolder>

  

• Both grouped and relational network types are supported.
• Node size, shape and colour.
• Line width and arrows.
• Label font and background.
  
• The "Circle" and "Best fit" layouts.

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    

Group Permissions

Editing tip for folder.xml

Permissions

• listDirectory : allow users to list existing files and subfolders
  
• downloadFile : allow users to download the IOK files
  
• viewInMobile : allow users to launch the Omniscope Mobile app for the existing IOK files
  
• fileManagement : allow users to upload IOK files, rename and delete resources, create new folders in the folder and save. Also used to control if mobile is in "Viewer" mode.
  
• getStatic : allow users to get/access static resources from the folder, and to customise default styles (e.g. logo, icons, css files)
  
• viewServerState : allow users to view the server state through a monitoring page
  
• exportData : allow users to export a view's data as a CSV file.
  

folder.xml file structure

• Anonymous section
  The <anonymous> element describes the unauthenticated permissions, and is also used as default values for per-group permissions.
  Unauthenticated public access will be given these permissions. Any false/missing permissions will require authentication.
  
• Groups section
  The <group> element describes the authentication group and its permissions, and is made by the following elements/attributes:
  
  • Enabled : whether or not the group is enabled. Disabled groups are not considered during authentication
    Note: If the enabled attribute is missing the group will be enabled by default. A group is disabled only if the enabled attribute is present and is set to false
    
  • Name: specifies the group name e.g. Data Analysts, Guests, Administrators, Employees, etc
    
  • Permissions: the group permissions that will override the anonymous ones
    
  • Mechanisms: a list of authentication mechanisms to be used when authenticating users for this group e.g. LDAP Query, List Of Users, SPNEGO (Single-Sign-On)
    
    • ListOfUsers: defining a list of users, e.g. :
      <listOfUsers>
<users>
<credentials username="test" password="098f6b627b4f6" />
<credentials username="visokio" password="72261efef7c41" />
</users>
</listOfUsers>

      Credentials element has two attributes: username and password (the MD5 encrypted password).
      To generate password MD5s, visit this link
      
      
    • ldapQuery: LDAP Query mechanism enables Omniscope Server to query an LDAP/AD server to validate user credentials
      Attributes:
      
      • distinguishedName: LDAP group distinguished name E.g. CN=Users,DC=example,DC=com
      • url: A full URL pointing to your LDAP/AD server
        Example 1: 'LDAP://ldapserver.example.com:389'
        where LDAP is protocol name, ldapserver.example.com is the LDAP/AD server and 389 is the default port for LDAP protocol
        Example 2: 'LDAPS://ldapserver.example.com:636' where LDAPS is LDAP over SSL protocol,
        ldapserver.example.com is the LDAP/AD server and 636 is the default port for LDAPS protocol
        
      • ignoreSslIssues: false most of the time. Set true only if your LDAP/AD server has not been configured to use a trusted certificate and you are using LDAPS protocol
      • securityAuthentication: Security authentication type supported by your LDAP/AD server. By default, LDAP/AD server uses a simple security type. However, you should contact your administrator to check whether you need to use a different type (CRAM-MD5, or DIGEST-MD5, or none)
      • principalNameFormat: can have only one the the following values:
        
        1. {Name} : User's simple name will be used to authenticate. e.g. 'username' and 'password' will be used
        2. DOMAIN\{Name}: User's simple name will be added the DOMAIN name automatically e.g 'EXAMPLE.COM\username' and 'password' will be used to authenticate the user
        3. {Name}@DOMAIN: User's simple name will be appended the DOMAIN name automatically e.g. 'username@EXAMPLE.COM' and 'password' will be used to authenticate the user
        
        
      • principalDomain: must be set only if 'principalNameFormat' contains a domain name, otherwise it will be disregarded. e.g. 'EXAMPLE.COM'
      
      
    • spnegoMechanism: a Single-Sign-On authentication mechanism e.g.:
      <spnegoMechanism>
<userNames>
<userName userName="johnsmith" />
<userName userName="johndoe" />
</userNames>
</spnegoMechanism>

      spnegoMechanism element has a list of user names to be verified once users authenticate successfully on LDAP/AD server and are assigned group permissions (roles).
      WARNING: spnegoMechanism will be disregarded during authentication if SPNEGO global settings are not set in config.xml
      
    
    
  
  

folder.xml example

Common use cases:

• Anonymous access not allowed, Admin user full permissions, Guest users browse and play IOK files
  
  <?xml version="1.0" encoding="UTF-8"?>
<mobilefolder>
<anonymous>
<permissions listDirectory="false" downloadFile="false" viewInMobile="false"
fileManagement="false" getStatic="false" viewServerState="false"
exportData="false" />
</anonymous>
<groups>
<group enabled="true" name="Administrators">
<permissions>
<permissions listDirectory="true" downloadFile="true" viewInMobile="true"
fileManagement="true" getStatic="true" viewServerState="true"
exportData="true" />
</permissions>
<mechanisms>
<listOfUsers>
<users>
<credentials username="admin" password="5d141e04873b9" />
</users>
</listOfUsers>
</mechanisms>
</group>
<group enabled="true" name="Guests">
<permissions>
<permissions listDirectory="true" viewInMobile="true"
getStatic="true" />
</permissions>
<mechanisms>
<listOfUsers>
<users>
<credentials username="guest" password="f5d1ee04873b9" />
<credentials username="visitor" password="43ffge14197e45" />
</users>
</listOfUsers>
</mechanisms>
</group>
</groups>
</mobilefolder>

  
• Anonymous access not allowed, admin users authenticating with their LDAP accounts, employees browse and play IOK files and authenticate with their LDAP accounts, a new employee user authenticating with List Of Users mechanism if an LDAP account is not yet available and a user authenticating with a Single-Sign-On (SPNEGO) mechanism
  
  <?xml version="1.0" encoding="UTF-8"?>
<mobilefolder>
<anonymous>
<permissions listDirectory="false" downloadFile="false" viewInMobile="false"
fileManagement="false" getStatic="false" viewServerState="false"
exportData="false" />
</anonymous>
<groups>
<group enabled="true" name="Administrators">
<permissions>
<permissions listDirectory="true" downloadFile="true" viewInMobile="true"
fileManagement="true" getStatic="true" viewServerState="true"
exportData="true" />
</permissions>
<mechanisms>
<ldapQuery
distinguishedName="CN=Administrators,DC=example,DC=com"
url="ldap://ldapserver.example.com:389"
ignoreSslIssues="false"
securityAuthentication="simple"
principalNameFormat="{Name}@DOMAIN"
principalDomain="example.com">
</ldapQuery>
</mechanisms>
</group>
<group enabled="true" name="Employee">
<permissions>
<permissions listDirectory="true" downloadFile="true" viewInMobile="true"
fileManagement="false" getStatic="true" viewServerState="false"
exportData="false" />
</permissions>
<mechanisms>
<spnegoMechanism>
<userNames>
<!-- User 'john' with password 'SomePassword' is defined on the
LDAP server and logged in the client machine to test SPNEGO -->
<userName userName="john" />
</userNames>
</spnegoMechanism>
<ldapQuery
distinguishedName="CN=Users,DC=example,DC=com"
url="ldap://ldapserver.example.com:389"
ignoreSslIssues="false"
securityAuthentication="simple"
principalNameFormat="{Name}@DOMAIN"
principalDomain="example.com">
</ldapQuery>
<listOfUsers>
<users>
<credentials username="NewEmployee" password="d1274e417e04" />
</users>
</listOfUsers>
</mechanisms>
</group>
</groups>
</mobilefolder>

  

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

SPNEGO Troubleshooting

• Error Java Cryptography Extension (JCE) Unlimited Strength is not enabled.

  LDAP/Active Directory (AD) server may send tickets that have been encrypted using AES 256 bits (or larger) which is not enabled in Java (JRE) by default and therefore SPNEGO authentication may fail

  Java Cryptography Extension (JCE) Unlimited Strength includes two jar files that contain only configuration settings enabling unlimited strength cryptography algorithms in Java.

  To enable JCE unlimited strength download it from http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

  The downloaded file contains three files
  

  • local_policy.jar
  • US_export_policy.jar
  • README.txt
  
  Read and follow the instructions outlined in the README.txt file.

  To install JCE unlimited strength, the client needs to put these two jars in
  - {OMNISCOPE LOCATION}\x86\lib\security
  - {OMNISCOPE LOCATION}\x64\lib\security
  while creating a backup for the existing (default) two files and restart the application
  

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

List Of Users authentication mechanism

Besides Single-Sign-On (SPNEGO) and LDAP Query mechanisms which authenticate users that are stored and managed on other servers like LDAP, Omniscope Mobile server may be configured to validate Omniscope users by manually adding custom users on server. Those users are stored in Omniscope Server configuration files (config.xml, folder.xml).

Configuration steps

1. Open Edit Default folder configuration dialog (Visokio Omniscope Server window -> Mobile Web Server section -> Config button -> Permissions section -> Default folder configuration -> Edit)
2. Make sure to properly edit anonymous permissions first (actions that are allowed for anonymous users will not use authentication).
3. Add a new group (or edit an existing group)
   - Note: Disabled groups are not considered during authentication
   
   

   
   
   

4. Edit group permissions
5. For group mechanisms click the Add button and select List of users.
   
   
   
6. Add users.
   
   

   
   
   

   
   
   

Legacy Omniscope users

Users are grouped automatically based on their permissions and whether users are enabled or disabled.

E.g.
Legacy users:

• User 1 with permissions A, enabled
• User 2 with permissions B, enabled
• User 3 with permissions A, enabled
• User 4 with permissions A, disabled
• User 5 with permissions A, enabled

• Group 1 with permissions A, enabled having User 1, User 3, User 5
• Group 2 with permissions A, disabled having User 4
• Group 3 with permissions B, enabled having User 2

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

LDAP Query Mechanism

• Users are stored and managed by an LDAP/Active Directory (AD) server
• Omniscope Mobile server is configured to query the LDAP/AD server

Prerequisites

• LDAP distinguished name (e.g CN=Users,DC=example,DC=com)
• LDAP URL and port (e.g. LDAP://ldapserver.example.com:389)
• LDAP security authentication type (e.g. simple, or CRAM-MD5, or DIGEST-MD5, or none)
• Local domain name (e.g. example.com)
• Whether your LDAP/AD server has been configured to use your trusted certificate (only if you want to use LDAPS instead of LDAP which does not need that information)

Configuration

1. Start Omniscope Mobile server
   
   
   
   
2. On Mobile Web Server service section click Config, scroll down to Default folder configuration and click Edit
   
   
   
   
3. Either create a new group with new permissions, or edit an existing group
   
   
   
   
   
   
4. Edit LDAP settings
   
   
   
   
   • Type LDAP distinguished name (e.g CN=Users,DC=example,DC=com), it should match the distinguished name configured on your LDAP server
   • Optional: on the LDAP/AD server create a dedicated user to be used only by Omniscope Mobile server to authenticate users and add this user in the LDAP/AD Dedicated User section
     Setting a dedicated user will help authenticate other users by their account name (which may be composed of their first name and last name). By default, users are authenticated using their account id (sAMAccountName) only
     
   • Type LDAP URL
     This is a full URL pointing to your LDAP/AD server
     Example 1: 'LDAP://ldapserver.example.com:389' where LDAP is protocol name, ldapserver.example.com is the LDAP/AD server and 389 is the default port for the LDAP protocol
     Example 2: 'LDAPS://ldapserver.example.com:636' where LDAPS is LDAP over SSL protocol, ldapserver.example.com is the LDAP/AD server and 636 is the default port for the LDAPS protocol
   • Check Ignore Ssl certificate issues only if necessary (your LDAP/AD server has not been configured to use your trusted certificate and you want to use LDAPS protocol instead of LDAP )
   • Select the security authentication type supported by your LDAP/AD server.
     By default, LDAP/AD server uses a 'simple' security type. However, you should contact your administrator to check whether you need to use a different type like CRAM-MD5, or DIGEST-MD5, or none
   • Select principal name format. Choosing DOMAIN\{Name} or {Name}@DOMAIN will enable Omniscope server to prepend/append the domain name automatically if the user did not type it already
   • Type your local domain name to be appended to usernames automatically when authenticating users. This field will be disregarded if you selected {Name} for principal name format field
   
   

LDAP Filter

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting

Single-Sign-On (SPNEGO) Mechanism

• Users are stored and managed by an LDAP/AD server
• Omniscope Mobile server is configured to ask the LDAP/AD server to validate user tokens

Configuration

At least three machines are involved in a Single-Sign-On setup:

1. LDAP/AD server (e.g. computer name ldapserver)
2. A machine running Omniscope server (e.g. computer name omniscopeserver)
3. A client machine having a browser installed (Chrome, Firefox, Internet Explorer, etc) (e.g. computer name browserA)

• The machines must be on the same intranet network,
• on the same domain (e.g. example.com),
• DNS properly setup such that they all can nslookup each other by name (e.g. nslookup omniscopeserver finds the machine running omniscope server)

1. LDAP/AD machine - Windows Server OS (2003, 2008, 2012, etc)
   
   • Create a dedicated LDAP user on the domain, e.g. omniscopeuser@example.com with password YourPassword (choose a stronger password), make sure the password never expires
   • In command prompt execute:
     setspn -A HTTP/omniscopeserver.example.com omniscopeuser
     

     
     
     where example.com is your network domain
     omniscopeserver is the name of the machine running Omniscope server
     omniscopeuser is user logon name of the dedicated LDAP user
     HTTP/omniscopeserver.example.com has never been mapped before with other user. If it has, you need to remove it first:
     setspn -D HTTP/omniscopeserver.example.com otheruser
     

   • In command prompt, execute the second command (make sure to use capital letters exactly as shown in the command):
     ktpass -princ HTTP/omniscopeserver.example.com@EXAMPLE.COM -pass YourPassword -mapuser omniscopeuser@EXAMPLE.COM -out omniscopeuser.HTTP.keytab -crypto RC4-HMAC-NT -kvno 0
     
     • where example.com is your network domain
     • HTTP/omniscopeserver.example.com - Kerberos service principal name for SPNEGO
     • omniscopeuser - the dedicated SPNEGO user that has been created on the LDAP server
     • YourPassword - password of the dedicated SPNEGO user
     • RC4-HMAC-NT - cryptosystem to use when sending SPNEGO tickets
     • kvno - Key version number
     
     
     
   
   Obviously, LDAP/AD needs to have regular users defined, users that are about to use Omniscope at least. For the purpose of this tutorial we will consider that
   there is a user clientA@example.com with password ClientPassword
   
   
2. Omniscope server machine
   
   
   • Start Omniscope server
     
     
     
     
   • On Mobile Web Server service section click Config, scroll down to Default folder configuration and click Edit
     
     
     
     
   • Edit SPNEGO global settings, for principal name type:
     HTTP/omniscopeserver.example.com
     and edit the password for that LDAP account ('YourPassword')
     
     
     
     
     
     
   • Click OK to close editing SPNEGO global settings
     
   • Either create a new group with new permissions, or edit an existing group
     
     
     
     
   • Add a new authentication mechanism and choose SPNEGO mechanism
     
     
     
     
   • Make sure you add all user names for the users that will be allowed to authenticate automatically (e.g. clientA, no domain needs to be included in the name)
     
     
     
     
     
     
   • Click OK to close each dialog and click Save and apply to save the configuration
     
   • Omniscope server does not need to be restarted manually
     
   
   
3. Client Machine - The browser has to be configured to use Single-Sign-On and trust omniscopeserver machine
   
   
   • For Internet Explorer
     
     
     • Open Internet Options
       
       
       
     • In Security tab select Local intranet and click Sites button - make sure all check boxes are selected:
       Automatically detect intranet network,
       
       
       
       • Include all local intranet sites not listed in other zones,
       • Include all sites that bypass the proxy server,
       • Include all network paths
       
       
       Then click Advanced button and add the name of the omniscopeserver or the full name (with domain) as it is going to be used to access the omniscope server from the browser
       Note: The browser cannot use Single-Sign-On when accessing the omniscopeserver by IP instead of name, and the name has to be added to the zone
       
       
       
       
     • Click Close then OK to close the Local intranet dialogs
     • Click Custom Level... button, scroll down to User Authentication and select Automatic logon with current user name and password then click OK to close the dialog
       
       
       
       
     • In the Advanced tab of the Internet Options dialog scroll down to Security section and make sure Enable Integrated Windows Authentication option is selected. (It should be selected by default)
       
       
       
       
     • Click OK to close Internet Options dialog
     • Restart Internet Explorer
     • Test it: open http://omniscopeserver you should be able to use omniscope server if you have the right permissions (group permissions that you set up on Omniscope server)
     
     
   • Google Chrome
     
     • Google’s Chrome browser shares the same configuration with Internet Explorer. Once the trusted URL is added in Internet Explorer, Chrome works with SPNEGO. Chrome does not have a configuration mechanism.
       
     
     
   • Mozilla Firefox
     
     • In the address bar type:
       about:config
       
       
       
       and search for trusted. The required key is a comma separated parameter named network.negotiate-auth.trusted-uris - edit it to include 'omniscopeserver' as well
       
       
     
     
   
   

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

Mobile Web Server Authentication

A realm defines a protection space. Realms allow the protected resources on the server to be partitioned into a set of protection spaces, each with its own authentication and authorization settings.

By default, all protected resources on the server are configured in the config.xml file. This is the (Home) realm. Specific folders may be manually configured to have their own set of permissions and authentication groups. For more information about folder permissions read this post.

Server permissions may be configured for anonymous users and for authentication groups.

A group may have a list of authentication mechanisms and server permissions.

For instance, the server may be configured to have a group named 'Data Analysts' with permissions to:
- List directory
- View in mobile
- Export view data
and authenticate users through LDAP Query and List Of Users.

Authentication mechanisms

List Of Users

List Of Users mechanism let's you define custom Omniscope users that are stored and managed by the Omniscope Mobile server. No third party servers/services are involved. Users are manually added/edited/removed by an administrator of the server.

A user name and a password has to be added for each individual user. Read this post for more information about List Of Users mechanism configuration.

LDAP Query

LDAP Query authentication mechanism let's you configure Omniscope Mobile server to query an LDAP server to validate user credentials.

• Users are stored and managed by an LDAP/AD server
• Omniscope Mobile server is configured to query the LDAP/AD server

To learn how to configure Omniscope server to use LDAP Query read this post.

SPNEGO (Single-Sign-On) Mechanism

SPNEGO (Single-Sign-On) mechanism allows users to authenticate automatically with their LDAP/AD account without asking them for credentials. Having a proper setup, authorized users never type their credentials in any dialog or form. Unauthorized users, however, are either prompted for credentials or are denied server access.

• Users are stored and managed by an LDAP/AD server
• LDAP/AD user password is never sent to Omniscope server
• Omniscope Mobile server is configured to ask the LDAP/AD server to validate user tokens

How does SPNEGO work ?

The browser negotiates with the LDAP/AD server and gets a temporary ticket which is further used to generate temporary unique tokens that are included in every client/browser request sent to Omniscope Mobile server. The tokens contain no information about client user name, password, or any other sensitive data, they are simple strings that can be verified only by the LDAP/AD server. Whenever Omniscope Mobile receives requests having SPNEGO tokens, Omniscope Mobile asks the LDAP/AD for token validation and if the token is valid, LDAP/AD provides only the user name associated with that token. Omniscope server checks whether this user is authorized to be served the requested resource and proceeds accordingly.

To learn how to configure Omniscope server to use SPNEGO mechanism read this post.

Authentication Groups

A group may have multiple authentication mechanisms. Each mechanism will be used during authentication until the user authenticates successfully. If no group authorizes the action that has been requested by the user, the access will be denied.

You may want to temporarily disable groups instead of deleting them and then adding them back later when needed. Disabled groups are disregarded during authentication.

• Users will not need a browser installed on their machine to use Web view, Content view, and Omniscope Mobile interface.
  
• Application stability will improve as Omniscope will no longer suffer from issues caused by the old version of the installed browser (e.g. IE6).
  
• Omniscope user experience will be boosted and improved in terms of look-and-feel, regardless the machine specifications.