I researched through Stackoverflow and some tutorials but cannot find an information on whether it is possible to configure the account under which the Reporting Services are running to have the permissions of an application role which is set on the source database? For example, I created a specific application role on the database for the reports and report builder to only being able to query certain schemas. How do I force the Reporting Services to use that role when connecting to that database as its source?
I want to make this work in Reporting Service itself. Because when the client deploys our reports, by default my database is the source for all of those reports. So it makes sense, for security reasons, to make sure that all deployed reports can only access what they should be accessing. And if a client decides to add a new report - they only have access to certain schemas that they can query.
I looked under the Security drop-down option from the data source, but see no way of configuring it to work against the application role.
Because this has proven impossible in a simple way. And the problem that we do not know the account SSRS (deployed data source and the reports) will be deployed under on the client's environment. The specific role will be added as Database Role, and the membership of which will have to be set upon the manual configuration on the client's environment through the application.
Related
I'm looking for a one click system that doesn't require one to delete the Azure database, publish from the local server, and re-create the user info onto the deployment.
What currently works:
Drop existing Azure database.
MSDeploy the database to azure.
Move the database to the app pool
Configure Azure database user/access
I briefly looked into the Azure sync, but that doesn't seem like something one can use "on request". Do correct me with example if I'm wrong on this assumption.
The ideal solution would be a one button click from Azure Data Studio to push any and all changes from the (localdb) database to the live one.
Azure Data Studio doesn't provide any readymade Single Click data transmission feature from local to cloud or vice-versa.
Azure Data Studio offers a modern editor experience with IntelliSense,
code snippets, source control integration, and an integrated terminal.
It's engineered with the data platform user in mind, with the built-in
charting of query result sets and customizable dashboards.
It doesn't provide in-built data push feature. Either you should use any programming language to build a dashboard as per your requirement, or you need to use Store Procedure for it.
I use SQL Server and have a SSO Database that contain application role, and application permissions for several my organization applications. several web service created for this database and each application work with these services. I want to restrict my application to get only and only own data from SSO database. and can't view, insert, delete or change role and permission for another applications.
what's the best practice for this problem.
Can I use App_Name() or Program_Name() for this purpose.
thanks in advance
Don't give the app access to the tables, views etc, just make a well defined API using stored procedures.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
I've got a Python application that connected to Microsoft SQL Server 2000. The application checks for updates on startup and automatically applies them. Soon, it will need to handle database schema changes as well. Based on my research, it seems that creating a baseline script of my current database and then creating a new script for each schema change is the way to go. That way, any version of database can be updated to the newest version.
My question is how do I manage the permissions for these updates? Right now there's about 50 people using my application, most of which have read-only access. Ideally, I'd like any user to be able to perform the necessary changes such as creating or altering tables so that the first person to receive the new update will apply the new schema changes. If that doesn't happen, then he/she might not be able to use the application at all until someone with appropriate permissions updates the database.
I can see a problem occurring if every user can update the schema. What would prevent them from logging into the SQL Server Management Studio and causing issues like dropping tables, etc.?
Right now, this application is only deployed in once place, so it's easy for me to manage schema changes manually. But we do have plans to deploy to more areas and I'd for all this to be handled automatically.
You want to restrict users admin privileges, but at the same time you want them to perform admin activities... Bit of a "chicken and egg" problem :-)
Option 1: Use webapp
Convert your program to run as a web application.
Bit drastic, however, much simpler maintanence. Your users no longer need to install Python, centralized upgrades and a shared connection pool to the database.
This solves your database authentication problem. Users authenticate themselves to the web application, not the database.
I use liquibase to manage my database schemas. It has a servlet listener which can automatically upgrade the database when a new version of my app is deployed. (Liquibase also has a command-line interface for use by alternative technologies like Python).
Option 2: encrypt admin password
You encrypt the admin password and make it available as a text file retrievable from a corporate web server, enabling any users application to download it at startup.
There is a security issue with this solution.... In order to decrypt the admin password, a shared secret needs to be built into your python application.... This is security by obscurity.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.