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>

  

• 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.

1. Sharepoint 2007 with IIS 7.0
   
   • Go to the IIS settings , choose the Sharepoint site you need to configure, and double click on the "Authentication" icon
     
     
   • Enable the "Windows Authentication"
     
   • Click on "Advanced settings" and ensure "Enable Kernel-mode Authentication" option is ticked.
     
     
   
   
2. Sharepoint 2010 with IIS 7.5
   
   • Go to the IIS settings , choose the Sharepoint site you need to configure, and double click on the "Authentication" icon
     
     
   • Enable the "Windows Authentication"
     
   • Click on "Providers..." and ensure that "NTLM" is in the "Enabled Providers" list