Welcome to the first in a series of posts answering frequently asked questions about Exago BI! Each month, we’ll pick a handful of questions with a common theme and give you clear, straightforward answers to them. This month, we’ll be looking at some security questions we are often asked during product demonstrations.


Q: How do we access Exago BI’s authentication layer?

A: You don’t, because we don’t have one. As an embedded application, Exago BI inherits the authentication protocol of the host application, your product, because Exago sits behind whatever authentication layer you already have in place. From there, Exago BI enforces data security through authorization. All it needs in order to do this is for your host application to pass in any user credentials that will affect what data an individual may access (for example, the user id and company name).


Q: Each of our clients uses a different database. Does Exago BI support security at the database level?

A: To enforce security at the database level, just set set up a connection string to your server and database, then dynamically modify the connection string based on the user so that it is correct prior to launching an Exago Session. This way, you don’t have to store a separate connection string for each client.  Since it’s common for client databases to have similar schemas, this means that Exago only has to maintain a single report for many users across companies.


Q: How does Exago handle security at the object level?

A: There are a couple of common ways to control object-level security. One way is to dynamically load objects via the API based on a user’s login parameters. Alternatively, you could have all objects load for all users as part of the base configuration and then activate a Role in the API that would then restrict access to specific objects.


Q: Several of our clients are using the same database, but each client has a unique id. How does Exago handle this type of setup?

A: Here you would use column tenanting in the database to control which rows an individual is authorized to see, based on his or her credentials. In the sample object below, user Bob from Company A would only have access to the first and third rows of the table once the tenant column (“Tenant Company”) was defined in Exago.



To further restrict what data an individual can access, activate a Role and filter the object using SQL filter string.

Let’s say, for example, that user Bob is only permitted to access sales employee information because he’s in the Sales division of his HR firm. When he logs in to the application, he will supply his division information, which will activate a predefined Role. Let’s call it the “Sales HR Role.” In this role, the Employee table above is filtered to only show records where the Department is equal to “Sales.” Now instead of having access to rows 1 and 3, he only has access to row 3.  

To learn more about security in Exago BI, visit our Knowledge Base