cube/SSAS 数据级权限解决方案----不使用域身份验证

一个多月没更新博客了，不是不想写而是真的没有什么高质量的文章与大家分享，最近在做一个集团公司的BI解决方案，客户提出了一个合理但是又比较棘手的一个问题，就是北京的经理和南京的经理都有权限访问公司内部的报表，但是需要对其进行透明化的权限区分，北京的区域经理不能浏览任何关于南京区域的销售信息。这个需求是很合理的，但是客户方不一定会在一个域中，也就是这个经理可能到美国到非洲（呵呵，当然这是比喻啦）也能正常访问我们的cube。问题是，微软的SSAS只支持windows身份验证不支持基本身份验证，换句话说，如果一个访问者如果与分析服务数据库不在同一个域中，哪么就不能访问，当然，也有例外，就是配置cube为匿名身份验证，如果是匿名，哪么数据就非常不安全了。 微软肯定是预见了这个问题，所以如果你使用了全套的BI解决方案，这个问题就很好解决，典型的微软BI解决方案：Windows Server->IIS SQLServer->SSIS-SSAS-SSRA MOSS->PPS。通过这一系列的解决方案，实现上述的需求就会变得很简单，参考架构： 上述架构每个部分都是无缝衔接的，但是具体到实际项目灵活性和实用性表现就不出色了。特别是ETL流程，使用微软的SSIS做ETL如果数据量小于1000万条、数据格式相对规范，可以考虑使用SSIS作为ETL，但是如果你的数据格式、质量、数据来源（来自各种数据库比如Oracle、MysQl、DB2等）就要考虑自己实现ETL，因为ETL过程其实是整个BI项目的重中之重，没要好的数据可靠性没法保证，哪么分析出来的结果你自己信么？目前我们的团队的ETL就是自己开发的，自己开发ETL是一个不小的工作量，也是整个项目耗时较长的任务。参考开发流程： 所以目前我们的团队只用了微软解决方案中IIS，和SSAS，和少量SSRS，其他的都是自己编写，当然，在增加了灵活性的同时，又增加了开发周期和开发难度（这个世界是公平的，呵呵）。 对于一个企业级的BI解决方案，安全性是必须要考虑的问题，对于一个大型的企业大都是跨区域的多级组织机构，这就需要对使用者的身份进行验证，并且根据其身份分配合理的展现报表信息。 在解决安全性上，团队遇到了鉴权问题，如果用户通过内网，使用域验证，哪么没问题可以解决，如果用户使用外网，通过Web连接数据库，因为外网中用户没有域用户名，所以根本就不能连接，如果将其设定为匿名登录，安全性就没法保证。在网上的一个博客中很多提到了数据集权限的解决方法，基本思路是通过一个拥有完全权限的Role来进行验证，具体方法如下： 请参考博客http://blog.csdn.net/idonot/article/details/7692169 ，这个博客详细的讲解了基于域账户如何实现灵活的数据集权限设定。 但是网上大多数的数据及解决方案都有一个个必要条件，那就是能获得该用户的域用户名，话句话说，访问者必须要有一个域的身份，如果没有，一切就无从谈起。 和其他人一样，我们团队也遇到了这个方法，但是我们很好的解决了这个问题，下面我将详细说明该问题的解决思路。 对不同人使用不同的权限控制，一个基础的条件是，在用户发出请求时能正确获得用户的身份，或者说是用户的登录名，因为只有登录名才是唯一的，当然你可以说用户的Ip，MAC等信息，但是我们要考虑多方面的，通过路由器（当然，是家庭中使用的那种共享上网的路由器，不是那种专业的路由器）哪么IP就会重复，如果多个人公用一个电脑MAC、IP就会相同，所以在每次用户发出请求时获得用户账号是最稳妥的（如果用户私下交换了用户名、密码，哪么我们管不了了，这是公司保密部的问题啦）。所以我们要在中间层添加用户鉴权功能。参考架构： 上面的模型就是我们主要的架构，本次博客我们只关注中间层。中间层也叫业务逻辑层，是客户端与服务端的连接纽带，用户所有的请求与服务端所有的服务都通过中间层解决。你所有做的就是在中间层实现一个访问管道，该管道用来在发出数据访问请求时将当前用户的信息一同发给服务端，服务端通过命名集函数来解析中间层传给的请求信息，然后查找权限表根据权限表将数据发给中间层，中间层根据返回数据中夹带的用户信息将数据发给请求用户。 参考架构： 只要获得了当前用户的登录身份，就可以使用网上博客提供的方法来进行鉴权了，再次就不赘述，读者可以参考之前提供的链接来获得相关信息。