cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practices for Database User Access

mike_mascitti
Cosmonaut

Hello, what is considered the best way to handle logins to the Incorta Postgres database (from a DB tool or from Power BI)?  

We have SSO configured for our online access, and we use generic IDs for people to access the database.  Is there a way to allow an individual user to log in to the DB without a specific login and password?  I'm thinking of how Windows Authentication works with Active Directory.

We can't easily setup a 2nd individual user account for everyone because their emails are already being used by the 'User' setup via the SSO process.  

So far, sharing generic IDs and passwords is our solution, but we'd like a better way that doesn't involve sharing IDs and passwords.

4 REPLIES 4

mnader
Employee
Employee

Mike,

The nature of SSO in Power BI depends on the nature of the deployment model. Live queries, for example, have a set of limitations within Power BI. A link to the documented limitations is provided below:

desktop-directquery-about

There are further considerations when a user connects from the Web Gateway versus the Power BI desktop client. 

Is your goal to have record level security, defined in Incorta, pass over to Power BI or are you looking to simplify the user experience on connection mechanism?

For example, assume a users is connecting from the Power BI Web Gateway. Incorta emulates a PostgreSQL database. When connecting to PostgreSQL Power BI does not pass the credentials down from the user connected at the Web Gateway to the source. PowerBI handles the authentication at the web layer but relies on the underlying Power BI document (that generated the report or data set) to acquire the data from Incorta this example. A record level security would have to then be applied within the Power BI document.

Please provide additional details if you can. I am happy to discus further.  

 

Thanks for replying, 

I'm not concerned with row level security, it's more of a security issue with sharing generic IDs and passwords.  In order for people to use an external database tool (we use DBeaver), we need to have people share a generic ID because their personal ID is already being used with SSO.

Is this normal practice for users with SSO to have those users share an ID for connecting to the database?  

dylanwan
Employee
Employee

Incorta allows you to use LDAP or Active Directory service to authenticate users when users are connecting using their own users (Recommended) to Incorta SQL interface while they may be authenticated using SSO when they login to Incorta Analytics web application.

The option is available from CMC.



Screen Shot 2023-04-24 at 10.13.53 AM.png

Screen Shot 2023-04-24 at 10.15.57 AM.png

This is tenant specific configuration.

dylanwan
Employee
Employee

Typically Incorta SSO sync the user and user group membership from a directory service (LDAP or Active Directory).  If your directory service is holding the SSO password, the password entered will be the same.  The user does not have to remember two passwords or having two accounts.  The username entered, however, will depend on how to define the mapping.  The Directory Sync mapping and the mapping entered in the authentication configuration need to be consistent.  Otherwise, login to Incorta SSO may use a different account name (such as email) from login to SQLi (using the Incorta login name).  In either cases, creating two accounts per user is not required, and sharing a single account in SQL interface is not recommended.