Category Archives: Jedox Security

Jedox Security and all things related

Enabling Session Limit per User in Jedox

Leave a reply

images (1)Jedox doesn’t allow you restrict the amount of times a user logs in to the server, and if the amount of concurrent users you have is small; then you will have the need to limit the amount of connections per user.

Luckily it’s quick and easy to do so, by following these simple steps:

  1. Create a new element in the User Dimension: it will define the amount of sessions that the user has.
  2. Change palo.ini: add a new authentication method.
  3. Add a SVS script: php script that will handle the authentication.

Creating the new element in the User Dimension

We need to add an attribute to the _USER_PROPERTIES dimension (which is hidden for the normal user) in the System database, which in this case is going to be called “sessions”.
Since there’s no direct access to that dimension, we need to modify it through an ETL job.

Change the session values

Create a Paste View to modify the values for the users. The rule is that that cell for the user is blank, then the user has unlimited logins, otherwise you need to specify a number (starting from 1).
The Paste View should look like this:

session_paste_view

Add the SVS script to handle the sessions

Look for the current SVS script that is running, if you don’t have anything running then go to <Jedox Installation>\svs\ and save the following file.

Then the sep.inc.php file in <Jedox Installation>\svs\, needs to be changed to include the previously download file:

<?php
include './sep.inc.session_limit.php';
?>

If you already have a SVS script running, then you need to change/complement the OnAuthenticate function, with the one provided.

Change palo.ini

Once the SVS script in place, now it’s time to enable SVS (if not already done) and the authorization login in palo.ini.
For that, we add the following lines (if they didn’t previously exist before) to palo.ini:

workerlogin authentication
worker "<Jedox Installation>\svs\SupervisionServer.exe"

Disadvantages

There’s no information in the login screen that will reflect that the user has reached the number of concurrent sessions. It will say “Incorrect Username/Password”.
However, going to the SVS log file, the information will be stored (in case it’s necessary to identify how many users are trying to create more sessions than allowed).

Jedox 5.1 – a Consultant’s Perspective : Part 2 – Security

1 Reply

Blue Doors LockedSecurity is critical in any Jedox implementation. Efficient ‘lock down’ of your models are just as important to an organisation as the data they contain. There has been a need for an additional layer of security in Jedox’s database architecture for a while now.

Pre-5.1 , you could lock down cubes , dimensional elements, even cells. But you could not actually hide or restrict databases themselves. This is a hugely important step – now you can hide all assortment of databases from certain user groups. A great example that has come up time and time again for me is around Payroll models. Even though Jedox security stops unauthorised access to cubes and dimensions within a Payroll database, the fact that unauthorised users could ‘see’ the database folder name made administrators nervous. This is now a thing of the past with the Jedox developers re-writing the security model to cater for  databases. There is now a separate security object (#_GROUP_DATABASE_DATA) that allows admins to restrict by group access to a database.

This new security development also opens the door potentially to a more multi-tenanted approach to model development. I have updated our security templates for database restriction and made them available :

Web Security Template

Excel Security Template (pw:jedox)

Enjoy!

Introduction to Security in Jedox

6 Replies

Jedox has a robust security model. You can allocate permissions down to cell level if required. All of its security objects are held within cubes and dimensions so it is pretty straightforward to set up and apply security. Its user security is group and role based, which means that users are members of groups and groups have certain characteristics defined for them by their role memberships.

Jedox can be set up for LDAP and Single Sign on, which enables Network Administrators to deploy user security centrally via an Active Directory server.

Moving down from user security, most objects in Jedox can be managed by security as well. This includes elements, dimensions, cubes; as well as reports, folders, web objects (eg Report Manager). For instance, you might have an ETL developer who only requires the ETL Manager. You can easily set up a role which would only give this access.

The only thing that cannot be managed (at the moment) is databases. I am certainly looking forward to this in a future release as this would open up the potential for more powerful multi-tenancy applications.

User Security is managed by System Manager. Here we can add users, roles, groups and manage relationships between them:

security_sysmgr

Unfortunately, you need to create your own reports out of the system database to manage Cube and Dimensional Security. After doing this half a dozen times, I realised that standardisation was required here, so I set up a couple of templates. Here are the ones we use for our clients:

Web Security Template (.wss)

Excel Security Template (.xls)

The Web Template:

security_web_template

The Excel Template (password to open: jedox):

security_excel_template

These templates allow you to easily manipulate and manage security, including doing things like applying like-for-like security to new users, setting dimensional security, and cube permissions.

NOTE: If manipulating/changing these templates, DO NOT use PALO.DATAC formulas when accessing security cubes. You will get instability. You must use PALO.DATA formulas.

Permissions – The Hierarchy of Rights

Without getting too technical at this point, the key part to remember here is that you need to assign to a group certain levels of access to particular objects. By default, a group with no rights assigned or restricted will have access to everything (you can reverse this default if needed from Jedox 5 onwards).

When assigning security to cells, dimensions or cubes you have the following options:

S (splash): Exists only for the rights object “cell data”. It includes writing into consolidated cells and (indirectly) their children down to the lowest level.

D (delete):  Permits the deletion of rights objects.

W (write):  Permits the writing of rights objects.

R (read): Permits the reading of rights objects.

N (none):  No type of access permitted.

A trap for young players here: assigning write access does not give you the right to enter a zero or delete a value. You can only add data. To get full ‘write’ rights, you need to actually assign Deletion (D) rights. The Deletion right also allows you to delete your data, which sometimes comes in handy.