since LLBL need a table level access ( as opposed to stored procedure level access which does limit the security issue) and considering the fact that having too many connection string for user access to the database would decrease performance for having too many connection in connection pool, do you suggest an alternative solution?

Hooman

Starting from v.2.5 an Authorization model was introduced. Please check the LLBLGen Pro v.2.5 documentation's section "Using the generated code - Setting up and using Authorization"

Thanks for your reply. The only thing is the developer still has to define the connectionstring with the role permission to the table. Although having the authorization in code could still improve the security, the target model doesnt cover the scenarios when an intruder get the control of conncetion string and can have access to the tables. can you please suggest the best security practice in this scenario. I presume I cannot have more than a few user/role due to the connection pooling performance.

Kind Regards, Hooman

the target model doesnt cover the scenarios when an intruder get the control of conncetion string and can have access to the tables. can you please suggest the best security practice in this scenario.

I think the Authorization model has nothing to do with the connection string. You may store the connectionString(s) encrypted somewhere, maybe in a text file, and encrypt it at runtime (in your application).

And of-course you can set the connection string dynamically in code, as follows. For Adapter: You can set the connection string for a DataAccessAdapter object by using its ConnectionString property.

For SelfServicng: you can use the DbUtils.ActualConnectionString which sets the global connection string to use for every connection to the database. This setting overrides the connection string read from the appSettings section in the .config file. Once the setting is set, every connection to the database uses the set connection string.