So, I'm trying to figure out how best to go about exposing some reports on a SSRS server that's behind the firewall to users on an extranet site, as discussed here. My DBAs have set a constraint that I pass Windows credentials to the server to gain access, and that the server remain behind the firewall. I'm having trouble conceiving of how to do that and still maintain a secure system in a public-facing DMZ. Here are some of my questions:
How can I allow users to authenticate to AD while preventing brute-force account hacking? In other words, one option is to create an app in the DMZ that accepts a u&p, and attempts to authenticated against AD inside the firewall. However, I need to prevent repeat trying and failing.
Assuming I have an authenticated user, how do I pass that credential to the SSRS server? What languages or mechanisms exist to accomplish that? Does this have to be a .NET app or could I manage it through Java?
How would I accomplish permitting the user to interact with the SSRS server? I don't want to loose all the UI functionality of the reports, and I don't want to rewrite it either. It seems like a hack to write an app that acts as a proxy, but that's all I can think of. Ideas?
TIA
Related
I'm a very new user to SSRS. I learned the basic things and am able to make reports using VS 2008 and BIDS. But I can't move further. I want to use the dynamic data source. My issues are:
First the user should input four credentials: a)Server name b) database name c) user id 4) password. It will help to make the connection with database and make the data source. The credential should be stored in session or cookie.
Now the user will be able to see all the reports without giving the credential because he/she has already given them.
I made a dynamic data source but the credentials are asked for every time I open a report.
Any demo project or an articles will be highly appreciated.
It sounds like SSRS alone will not accomplish what you want. SSRS will not provide a good interface for end users to create new datasources, or change existing datasources. There are some potential workarounds that get some of the functionality you desire, such as a method to change servers found at:
http://blog.softartisans.com/2011/04/19/how-to-create-a-dynamic-reporting-services-shared-data-source-using-linked-servers/
(requires the ability to use linked servers.)
But to manage the user session or cookies, you will need more than SSRS. The easiest way to get at this will be with a .NET web site to manage the credentials. It might be able to use a ReportViewer control, or other method of accessing SSRS, such as URL access, to get reporting functionality.
I have a website online with just HTML and I am not willing to use any other programming language apart from Javascript. All I need to do is connect my Microsoft Access database on my computer to a form hosted online so when information is submitted online it is updated on MS access the next time I open the file up. Is this possible and how can it be done?
Turns out, you can do this with zero code. If you use office 365, and publish an Access web forms.
Any information entered into the Access web form will automatic appear in your local database. The synchronizing of data from the web site and pulling down of the records to a local copy works automatic and without the need to write any code. In fact the sync starts automatic when you launch the client application. (it runs in disconnected mode). And any records you enter in the client application will also sync up and appear on the web site.
So, you can use Access and write zero code, and this two way sync feature is built in.
You need Access 2010, and either SharePoint 2010 (enterprise), or you can use office 365 and the $6 per month p1 plan which also does support Access web publishing.
However, I suspect issues of user logons and security may well be a greater issue here, and thus office 365 might not be correct from a user logon point of view. You can invite up to 50 users to that site for the basic $6 per month, but all users of the site will require a logon (which can be due to being invited to the site).
There are two videos of mine here showing this setup in action here:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
I think what you are trying to do is very impractical. You'll need to use Server Side Javascript to insert your data into a database, preferably SQL Server, and then you'll have to write some kind of code to sync the SQL Server Database to your Access database.
Alternately, you could setup your Access database so it connects to the same instance of SQL Server as your website using ODBC linked tables or ADO. I cannot really recommend this, especially if the data you have in your Access database is anything you wouldn't want to be public. Also, using MS Access to access a database across the WAN/Internet is really not recommended although it can certainly be done, as long as you aren't working with large amounts of data, large quantity of records, etc.
I am not willing to use any other programming language apart from Javascript.
And why aren't you willing to use something else? I don't think you're going to get anywhere if you don't open your mind to using the right tools for the right job.
Here's something that might help you get connected to SQL from Javascript:
How to connect to SQL Server database from JavaScript in the browser?
I've build an asp.net site with a report viewer control that displays reports hosted on our reporting services report server. Everything works great. But now I need to do the same thing with a public facing site, where I'll need to access my report server through the firewall.
My question is: How do I lock this down to make sure that the end user can only access certain reports?
I think that all I need to do is make sure my IIS, in my DMZ, can talk to the report server. But, I think I'll need to impersonate a user that only has access to the reports I want to make available. On the other hand, if my report server is only accessible from the DMZ, then I won't need to worry about the end user directly connecting to the report server. I seems like any report I want to serve to the outside world just needs to be accessible by the default ASPNET account? I hoping someone can confirm my speculation or tell me where I'm wrong.
I had this problem too. What I had to do was make sure that each report takes a parameter from the application. If your authenticated users have an role through a role provider, and public users do not, you could pass the role as a parameter to the report through the application. That way if a user is not authenticated, the parameter will be null, and the report will not execute.
I'm looking to implement SQL Server Reporting Services as our standard reporting platform in our company. We were trialing Crystal Reports, but alas it seems to be plagued by issues.
SQL Server Reporting Services looks to be a great product, but I have a concern or two.
I have some existing web apps in ColdFusion, and the backend is in MySQL. If I move forward with SQL Server Reporting Services, how should I set up my environment? Is there a JDBC connector or is ODBC the only way to talk to this?
How does it integrate for the user? Will I need to re-authenticate the user to view the reports? Will I need to put a link in ColdFusion to link to the Reporting Services system? Is there a way to make it seamless for the user?
Should I port all the backend to SQL Server to fully leverage the SQL Server platform? Should I convert my existing apps to ASP.NET, and make the entire platform SQL Server / ASP.NET?
It's not too bad in the fact that the existing apps / MySQL aren't of a size that is too big to port. So I guess just looking for some best practice advise to see if its okay to use the reporting services component on its own, or if I'm much better to consolidate everything into a Microsoft solution.
I think it'll be easier than you think!
Reporting Services will happily pull reports from any OLEDB or ODBC source, and MySQL has ODBC drivers, so there's no problem getting at your data through an SSRS report.
You can set up the authentication in a number of ways. If your users are already authenticated in your Windows domain, this will be easier:
SSRS needs to know who is viewing the report. It will allow anonymous viewing (if you enable it; it's off by default), but if you're using IE and are logged in to the same domain as the IIS server, it's completely transparent
SSRS can then use this identity to connect to the data source, or it can use another identity. This is configurable per report or per data source.
One thing you could do is embed your reports within iframes in your coldfusion pages. This would make the whole thing seamless. The reports are accessible by sending an appropriately formed URL to the server, so it's quite flexible.
As for changing everything to ASP.NET, you'll really only get benefits from that if you ever need to write (and integrate with) your own code to manage the reporting server, or write custom extensions (data providers, delivery extensions and the like), but in my experience this is so rare as to be not worth considering. Go with what you have for now.
I've got a MS Access database with a table and a form, but I want the user to only see the form. I don't want them to be able to edit any of the data. The user should only be able to use the form to query the table. Any suggestions??
There are a few ways to enforce some control over what users can do.
AutoExec
The most simple way is to use an AutoExec macro to initialise the user interface when the application starts.
That way to can make sure that only the form you want is displayed and hide everything else.
Runtime
A good complement to this approach is to compile your application and force the user to use the Access Runtime to use your application.
In the runtime, users don't have access to all the standard tools unless you explicitly code for it.
A good thing to know is that unlike previous versions, the Access 2007 Runtime is free, and that makes Access a very cheap platform to develop for.
Runtime emulation
With Access 2007, a simple way to ensure that the application will open as if only the runtime was installed is to change the extension of the database to .accdr.
You can also force a full Access installation to open a normal database in Runtime emulation by passing the /runtime command line switch.
Secure data-access
Note that short of encrypting the database (but then you have to manage the password), all you can do is make it hard for the user to open the tables manually.
A determined and knowledgeable user can always circumvent these protective measures and access the data.
If you need a really secure solution though, Access may not be the best choice: implementing fine grained security in Access is a greater challenge than the alternatives, say storing the data into a SQL Server database for instance where security is enforced.
Links to resources
Security Considerations and Guidance for Access 2007 on MSDN
A simple Microsoft Access User-Level Security Tutorial for older versions of Access.
FormSafe, a commercial product that helps enforce security on form controls.
I believe you want to use Access User-Level Security. Here's the documentation at Microsoft.
If you are using Access 2003 or earlier, you can use user level security, as mentioned. If you are using Access 2007 you are out of luck - Microsoft in their wisdom removed this ability. You will basically have to write your own login and set permissions on editing etc. using VBA code.