Is it possible to use our solution's existing authentication mechanism for determining access rights to a MS Analysis services cube?
We already have a system that manages usage policies and we would like to avoid duplicating this on the SQL Server.
Our authentication system is based on NetSqlAzMan and we could expose it as a web service, or a set of managed .NET assemblies (or just about anything if it got us the above functionality)...
If you mean Custom Authentication my answer is No. SSAS uses Windows Autentication and you should use it with its services or options (active directory, other integrated solutions etc).
If you mean Custom Authorization then my answer is Yes. Basically, you should follow the steps below;
Create a .NET assembly that uses your NetSqlAzMan backed web services or whatever you have for integration.
Register the assembly with Analysis Services
Use the registered assembly's functions in the advanced Dimension Security section to restrict the dimension members by users.
Custom assembly in this context must be developed as high performant as possible because every MDX query will consult it for filtering the members.
Related
it might be a simple question but as I couldn't find the best answer on google I would like to know your thoghts.
I'm thinking of changing a software I've made in WPF accessing its data from a local server to a cloud server (maybe Azure).
What's the best way, connect directly to the database or access through a service in the clould (that would have to be developed by me I guess).
Thanks!!!
In general, I would guard against directly accessing a database hosted in the cloud via a client application. You'll be exposing your database endpoint through the public internet providing a significant attack vector.
By using a service, you can limit that attack vector. The service itself is also 'exposed' but can be locked down (typically more effectively/easily) with authentication/authorization protocols like OAuth, AD, etc. AND the service itself would expose only the operations necessary for the client application, versus access to the complete database schema (should someone crack the password when the database is on the open internet).
You didn't mention if you were planning to use Windows Azure SQL Azure or your own database in IaaS. You can, of course, implement your own security via firewall, etc. on VMs hosted in Windows Azure, but that's another infrastructure task you'll need to accommodate, and if your client IPs change, etc., then managing that is not insignificant.
I think the answer to the question would be the same whether you'd be on Azure or not.
A service adds an abstraction layer between the application and the database, which may help with maintenance in the long term, but it does have a cost associated with it (in terms of initial effort) and some potentially performance penalties (although this does not have to be significant) so in the end you'll have to weight it according to the application.
I really do not think there's a one-size-fits-all answer to this.
We have a BI team that have created a wonderful data warehouse that works fine for the internal staff using it through Excel on the internal network. They use windows authentication through the domain controller, and everything works fine, including restricting the access to users and AD Groups.
The issue is that we now want to provide the same access to a wider audience that is not part of our Windows Domain. This is further complicated by the fact that the information on the users that need access to the system is already stored in another location (an application with a SQL database).
The goal is to make it so that they connect (probably using HTTPS) to the cube (using Excel Analysis services integration), and be authenticated using the Username/Password that they had in the main application.
The main application has a WCF Service interface for user authentication, and session management, so all I really need is a way to provide authentication in front of the MSMDpump.dll against that WebService. We can also add in a Role Mapping so that we can define the SSAS roles against the users in the application.
I was thinking that I could create a dll that has the same interface as the MSMDPUMP.dll, and have that translate calls between the client and the main dll, but this seems a bit of overkill.
Are there any pre-built tools to do this? (and yes I know that Sharepoint can do something like this, but that's not an option so please don't suggest it). Does anybody know of any blogs detailing how to do it?
Any pointers in where to start with creating an interface between the 2?
The question is similar to How to secure MS SSAS 2005 for HTTP remote access via Internet? however, I'm looking at providing the authentication mechanism from another datasource, and providing the Roles to SSAS, not the users. We don't want to have to setup a new user in SSAS for every user that is setup in the external application.
UPDATE: To be clear, they external users need to connect to the cube using Excel, and the data returned needs to be filtered by the role they're in and the security applied in the Cube.
We are able to cahnge the cube to use Dynamic Dimension Security and use CustomData attributes if that helps.
The eventual solution ended up being a combination of a Third Party Control and Dynamic Dimension Security.
We found that it's not possible to easily apply a MembershipProvider interface to the MSMDPUMP interface without significant effort, so our solution gave them a Web Interface to use instead.
The Control we used was by DevExpress and is their "PivotGrid" control. It's not free, but is significantly less than the development resource costs of implementing any other custom solution.
Along with the control, we've applied Dynamic Dimension Security to the Cube so each user of the Site will have a dedicated connectionString to the cube with "CustomData" appended to the connectionstring. This allows us to delegate Data Segregation tasks to the Cube and BI team, and let the Web Developers concentrate on the display of the controls.
The solution is working quite well, and doesn't involve heavy weight applications like Sharepoint/Excel Services. It can built directly into your site and branded as you need, providing a sales tool as well as a useful functional tool.
Can you create a limited-access user on the cube db (read-only, only for the relevant cube, etc.) and hard-code that user/password into a connection string on the app db?
We're developing a WPF business application for internal users, but this problem could apply to WinForms easily as well. We want to leverage a business rules engine to make modifying the rules in the future easier as well as to possibly let the business folks to do it themselves at some point.
BizTalk (we're using 2010) exposes its Business Rules Engine and, while complex, this looks to be a potentially worthwhile solution especially if we look to using it for future applications as well. We've loaded up a virtual server with the developer edition to try it out, as well as its own SQL Server instance to run off of.
Everything I've read (example and example) seems to show adding the BRE assemblies to the application project as references and then using the provided classes to call and execute policies. But they also suggest that these assemblies require a license and we can't exactly license BizTalk for each of the dozens of possible end users that will use this WPF app.
Am I wrong about the licensing issue? Is it okay (and normal) to deploy the BRE assemblies with your app to all client machines in order for them to communicate with the BizTalk server where the policies exist? Should I look into exposing the BRE API via a Web Service or something? Are there any implementations out there already for doing that? Exposing the API like that seems like no small undertaking... or is it?
Microsoft says that the BRE is only available for server-side usage, e.g., in BizTalk orchestrations, ASP.NET apps, and Windows Services running on a server. The engine cannot be embedded in client applications.
From their FAQ on licensing:
All technical support and licensing for the BRE is only for
server-side solutions. Note that you need to acquire a BizTalk Server
2010 license to utilize the Rules Engine, as the Rules Engine is
considered server software requiring a valid processor license. The
Rules Engine is not licensed separately from BizTalk Server.
Because of that, it may be worthwhile to look at using the BRE from an ASP.NET service that can be called from your WPF clients. If you want the clients to be able to update the rules, that is within the scope of the licensing agreement:
the Rules Composer is considered a client tool and may be installed on
a separate internal client device to support development and testing
of your BRE server solution
Be sure to check out Tellago's BRE Data Services API (available on CodePlex). They've done a lot of the work for you if you want to query the rules engine via your own service.
I'm wondering what the basic protocol is for storing users in a database, creating accounts, and authenticating them - with ASP.NET MVC 3 framework (using C#), and Azure SQL.
More specifically:
1.) Where in an ASP.NET C# MVC3 Visual Studio project do I write code that only runs on the back-end? Such as logging into my database as an admin, so I can write to and read from the database.
2.) Where should I make database calls from using MVC framework? Do I call a back-end function (e.g. - to create a new account in the database) from the controller?
Thanks for any help!
I'm not 100% sure whether you are talking about SQL Users or Application users.
However, generally, what ASP.Net MVC applications do is:
they use one or two defined users to connect to the database (e.g. they might define a read-write and a readonly connection for different types of queries)
they use the ASP.Net Membership API for application-level user accounts
they use an ORM framework like NHibernate or Entity Framework for other database access
There are lots of tutorials and articles for this sort of information out there - one place to look might be Scott Hanselman's blog - see:
a tutorial on using ASP.Net Membership with SQL Azure
the Mix11 tools walkthrough - including Code First Entity Framework
1) You could use Membership (which I used to use) or simply write your own Authentication code. There are 2 drawbacks with Membership. First, there are a ton of tables and stored procedures that are installed but worse, there's no way to change a user name via the Membership API. Try telling a customer that they cannot change their username (which is usually their email address) and they'll give you weird looks.
2) Forget EF and use your own repository, which simply harnesses SPROCs. Go ahead, make a ton of changes to your EF design canvas, change the db schema, and I can guarantee you will run into issues with the "behind the scene" files at one point or another.
Apologies for the newbie web service question -
I am trying to create a webservice that has a list of methods to perform read/writes to a database. An example function will be of form -
CreateNewEmployee(string username, string employeeid, string deptname)
I created a webservice in .net (asmx) that has the above mentioned webmethod. In that, I open the connection to the data base and do an insert in to the database and then close the connections. Is this the right way to design the web service call?
Should I instead be passing an object instead of multiple parameters?
Any pointers toward best practices when trying to create a webservice that writes data into a database?
To add some more information
We would like to have web services since it might be reused by many different applications within the organization (both web and desktop).
We are also planning to create an environment where users can use these web services to create data mashups.
Thanks,
Nate
Yes - pass objects vs large parameter sets. Also, have you considered WCF if you're in a .Net environment? If you look at how ADO.Net Data Services (formerly Astoria) works, it will put you in the right direction.
Quoting from the winning answer to this SO question:
Web Services are an absolutely horrible choice for data access.
It's a ton of overhead and complexity for almost zero benefit.
You can read the rest of the discussion there.
Edit: One excellent approach to having a common data access functionality that can be shared by multiple applications - web, desktop, service - is to create a Visual Studio project that compiles to a DLL. Each solution that wants to use the data access functionality references the DLL, which can deployed to the GAC or some other central location, or just added to the project's bin folder. Alternately, in order to be able to step through the data access code, the data access project can be added to a solution.
This is a very common practice in large enterprises, where many back office applications share common functionality. It is used not just for data access, but also for other services such as logging and authentication/authorization. Some divisions create a set of these DLLs, which they refer to as their "framework". It ensures that every application will have the same functionality and the same business logic, and that there is a single place for revisions to be made that will affect all of the applications. This is a similar benefit to using web services, but it avoids the overhead and performance hit of web services.