I am building a multi tenant site.
Currently I am using mode="InProc" to store my sessionstate; but now planing to switch to sqlserver sessionstate.
My Question Is;
Can I maintain different database for sql sessionstate separated from my current database?
What will be the standard practice for multi tenant architecture with separate database for each client?
I mean
<connectionStrings>
// Connectionstring for my client data; suppose "DatabaseClient"
</connectionStrings>
//---------------------
// Here connection for sql session dataabse; suppose "DatabaseSession"
<sessionState
mode="SQLServer"
sqlConnectionString="server=127.0.0.1;uid=<user id>;pwd=<password>;" />
Yes you can. Store two connection string in connectionstrings section in config. One for business database and one for session storage database.if membership implement is custom for each tenant (custom profiles , roles ,password police's..etc ) the complexity may high in single session db else you are in correct way
Related
Good afternoon,
I am writing a front-end for a research database that holds sensitive health information. My institution has a policy that user actions be logged by the SQL server so that they can perform audits on the server log files in the event of a breach.
Because of this policy, I cannot connect Django to the db as a system user (otherwise, all users of the front-end actions would be logged by the server as the Django system user instead as the actual user individually).
Is there a way to connect to the DB using per user credentials so that actions performed on the front end will be logged as that user on the db server? I have been able to find a lot of information about using multiple databases, but nothing about per user authentication of those databases.
Thank you in advanced!
I don't think you can do that, the user that connect to the database need to have access to all the tables.
I had a similar issue when I wanted to use Django models outside Django and restrict access to certain models for certain users.
I ended up using SQLAlchemy and its automap feature on the existing Django database. Then you can connect to the database using your SQL users.
However, if you don't mind all the users accessing all the tables and are only concerned about the logs, maybe you can use a different settings.py or at least a different DATABASES configuration for each user?
I was able to accomplish this by giving the SQL user the IMPERSONATE permission and performing EXECUTE AS prior to the DB queries that I needed to have logged in models.py.
cursor = self.connection.cursor()
try:
cursor.execute("EXECUTE AS " + get_current_user()
except DatabaseError as e:
cursor.close()
raise e
We have a requirement that user account can provide username/password for database. This means that after user account is loaded, the user should use his own database connection for persistence.
How do I configure that in Spring Data?
Which database?
Which ORM implementation?
Spring has the AbstractRoutingDataSource, which lets you change the DataSource at runtime.
You could also use a delegation pattern, where the web server connects as a limited user, and then changes role to a different user if their authentication is successful. See How to run SQL SET statements against db at start of connection/session using Hibernate? and Switch role after connecting to database
You'll probably need to disable caching in your ORM too.
I have a WCF web service that should always use a specific AD account, which has been granted access to the database, to execute SQL transactions. I read a couple of articles, but I'm obviously doing/understanding something wrong because I'm not getting it to work the way I want.
I figured that that web service should impersonate the AD user, so I enabled impersonation in the web service web.config:
<identity userName="dmn\wsusr" password="p#55w0rd" impersonate="true"/>
Then, since I'm technically using a Windows user to connect to SQL, I set the connection string as follows ("Integrated security=true;" for Windows authentication, right?):
Data Source=SQLSVR\INSTNC; Failover Partner=SQLSVR\INSTNC2; Initial Catalog=DB; Integrated Security=true;
For testing the connection I insert some values into a table. One of the columns of the table I'm inserting to has the following definition:
[LogUser] VARCHAR(75) NOT NULL DEFAULT USER
So, theoretically, the AD username of the user who opened the connection will automatically be inserted into the column. Unfortunately, however, the column contains my own AD username every time.
I'm testing the web service via a web site that uses Windows authentication, so I'm assuming that this plays a role in the cause of the problem. But the website authentication should be disregarded since this will be an externally accessible web service and SQL transactions should never rely on authentication between the client and the web service.
Thanks!
EDIT
I also tried:
Adding Trusted_connection to the connection string, but it yielded the same result as above.
Using User ID and Password in the connection string, but since the connection string only accepts SQL users, this resulted in a Login failure error
EDIT2
I suggested to my superiors that we should try the approach where you create a separate application pool for the service, set it up to run as the AD user, and allow the AD user to log on as a service (something I read somewhere) but they're not keen on that and reckon it should be a "last resort"
Just had a query that can WSO2 Identity Server be integrated with both LDAP and DB at the same time. To elaborate my query more, say we have a group of users defined in LDAP and another group of users defined in DB and I want Identity Server to act authorization gateway for both of these groups. Is it possible?
Also, while integrating with DB WSO2 adds its own tables in our existing DB. Is there any way we can add custom attributes(claims) support in DB without altering the WSO2 tables?
WSO2 Identity Server supports only one active user realm at a given time. But if your requirement is to use WSO2 IS as an authorization gateway which connects to a LDAP server as well to a DB for populating claims, etc then it is possible to use XACML support in WSO2 IS with a custom PIP(policy information point). In that case, you can connect to the LDAP server as the primary user store and write a custom PIP to connect to the DB to read the required claims.
Following two posts on PIPs will be helpful.
[1] - http://xacmlinfo.com/2011/12/18/understanding-pip/
[2] - http://blog.facilelogin.com/2011/04/xacml-policy-information-point.html
Answering the second query, with the default configuration in the JDBC mode, WSO2 IS uses its own set of tables for maintaining its user store. But if required, you can write your own user store implementation which connects to your database.
So far, after creating DB with all the schema, all I have done so for was accessing them (tables) by reference through ConnectionStrings.
Now, twice, I've read that it's better to create a DB user and access the DB trhough that user by including him in the connectionString.
I'd like to know why so?
Thank for helping
Your question isn't that clear. It seems that you're asking if it is better to use windows security ("Integrated Security=SSPI" in the connection string) or a username/password ("User ID=myUsername;Password=myPassword;").
Its always better to use windows security. Having login information within the connection string is a security risk. Its in cleartext (unless you take some complicated steps to secure that section), and is sent across the wire as cleartext unless you set up a trusted connection between application and server.
Is it better to "create a db user and access the db trhough that user by including him in the connection string?" No. Its better to create a sql server login for user's windows identities and let them use those credentials to access the server.
You do this if you wish to connect as a specific user, rather than (for example) just using the context of the current user which your application is running under. However, if you use SQL Server authentication (i.e. username and password), you'd need to provide that password in the connection string, which is something of a security problem.
If the application has a group of anonymous users (or manages users/passwords itself) then its better to use a Windows login and run the application under a service account (which has minimal required access to the database).
If you're running an interactive application on the desktop, you should let those users connect to SQL server in their own context, by adding them to SQL Server with the required rights (e.g. db read/write , remove any higher functions). Obviously you would use groups to make administration simpler rather than adding individual users.