We are building an hosted application that uses MS SQL Server Analysis Services 2005 for some of the reporting, specifically OLAP cube browsing. Since it is designed to be used by very large global organizations, security is important.
It seems that Microsoft's preferred client tool for browsing OLAP cubes is Excel 2007 and the whole infrastructure is geared around Windows Integrated Authentication. We, however, are trying to build an internet-facing web application and do not want to create Windows Accounts for every user.
It also seems that there are not many nice AJAXy web-based OLAP cube browsing tools (fast, drag-and-drop for dimensions, support for actions, cross-browser etc.) As an aside, we're currently using Dundas OLAP Grid but have also considered RadarCube and other more expensive commercial solutions and are still thinking of taking on CellSetGrid and developing it further - if you know of any other cheap/open solutions please let me know!
We are therefore planning on providing two modes of access to the cube data:
- Through our own Web Application using one of these 3rd party Web-based OLAP browsing tools.
- Direct access from Excel over HTTPS via the msmdpump.dll data pump, for when the web version is too slow/clunky or user needs more powerful analysis.
For the web app access, the connection to the SSAS data source happens from the web server so we can happily pass a CustomData item on the Connection String which indicates which user is connecting. Since we potentially have too many combinations of rights to create individual SSAS roles for, we have implemented dynamic dimension security that uses a "Cube Users" dimension in conjunction with the CustomData item from the connection string and limits the Allowed Set of various other dimension members accordingly (via other Many-to-Many dinemsion relationships with Measure Groups that contain the 'rights mapping')
See Mosha on Dimension Security: http://www.sqljunkies.com/WebLog/mosha/archive/2004/12/16/5605.aspx
This all seems to work fine so far.
For the 'direct connection' from Excel, we set up the data pump for HTTP access (see the MS Technet article) but have enabled anonymous access, relying again on the Connection String to control access since we don't have windows accounts. However, in this case, the connection string is controlled by the user (we push a .odc file from the web app, but a curious user could view & change it), so we cannot rely on users to be good and keep the CustomData=grunt@corp.org from changing to CustomData=superuser@corp.org. As it turns out, this also causes the same problem with Roles, since these are also specified on the connection string if you are not using Windows Integrated Authentication.
The question therefore boils down to this: is there a way of getting basic authentication in IIS working without windows accounts in such a way that it can be used with the SSAS data pump to let SSAS know which user is connecting so that dynamic dimension security can be used successfully?
(This is my first q on StackOverflow and probably the most complicated question I've ever asked: let me know where I haven't explained myself very well and I'll attempt to clarify)
Basic authentication will work with local user accounts (non-domain) and even support passthrough authentication if the local accounts exist on different machines, however you should force SSL as basic authentication sends passwords in plaintext.
You can use non-windows accounts with basic authentication in IIS with add-on such as http://www.codeplex.com/CustomBasicAuth, but SSAS will still need to know who that user is and as far as I know SSAS uses only Windows authentication.
For a (relatively) cheap thin client front-end for SSAS look at RSInteract. For bonus points it will also consume SSRS reports and report models.
Any attempt to use dimension security will require SSAS to be aware of the user and have their access rights available to it. I don't see any way to get around maintaining user permissions.
来源：https://stackoverflow.com/questions/126350/how-to-secure-ms-ssas-2005-for-http-remote-access-via-internet