📄 208005.htm
字号:
<html><body><span id=Layer1><a name=208005><font color=#3e70d7 face=arial size=5><b>安全性服务</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>如</span><span id=Layer3> <a target='_new' href=201.htm#>第一章</span><span id=Layer4></a> 所描述，分散式安全性是由许多不同的服务组成的，最重要的便是验证（authentication）、授权（authorization）、资料完整性，与资料私密性（data privacy）。这些对COM+应用程式来说是很重要的。COM+允许以管理介面来设定元件使用这些服务，因此程式设计师便不需要为它们撰写程式码。</span><span id=Layer5></font></p><font color=#3e72d7 face=arial size=4><b>验证、完整性与私密性</span><span id=Layer6></b></font><p><font size=2 color=#3c3c3c face=arial>COM+ 伺服器应用程式的验证、资料完整性与资料私密性的选择全部都透过同一个设定便可完成。这个设定的可能值与COM的CoInitializeSecurity的验证等级（authentication level）参数相同，描述於</span><span id=Layer7> <a target='_new' href=205.htm#174_1>第五章〈提供安全性〉一节</span><span id=Layer8></a> 。（事实上，COM+应用程式从来就都不应该呼叫CoInitializeSecurity）。预设COM+程式库应用程式在它们载入记忆体时，接受行程的验证设定，因此这个值只可能在COM+伺服器应用程式中设定。</span><span id=Layer9></font></p><p><font size=2 color=#3c3c3c face=arial>COM+伺服器应用程式可以以管理介面设定安全性设定</span><span id=Layer10></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM+伺服器应用程式可以以管理介面设定安全性设定</span><span id=Layer11></font></p><hr><font color=#3e72d7 face=arial size=4><b>授权（Authorization）</span><span id=Layer12></b></font><p><font size=2 color=#3c3c3c face=arial>COM runtime同样提供有趣又有用的授权服务。若要得知如何运作的概念，再度回想QwickBank电话中心的例子。假设这个应用程式允许接电话的银行行员进行转帐的工作，不过需要经理停止支付未偿贷款。同时也假设应用程式提供这些功能，如检查内部效能统计数字，这些功能只能让系统管理者存取。授权服务建置在Windows 2000的COM runtime，让这些规则能够容易地遵循。</span><span id=Layer13></font></p><p><font size=2 color=#3c3c3c face=arial>COM runtime提供授权(au-thorization)服务</span><span id=Layer14></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM runtime提供授权(au-thorization)服务</span><span id=Layer15></font></p><hr><p><font size=2 color=#3c3c3c face=arial>COM+ 授权依赖於角色（role）的概念。角色是一组Windows 2000的使用者或使用者群组，而哪种角色可以用在特定的COM+应用程式上则由它的建立者决定。举例来说，QwickBank电话中心应用程式可能定义叁种角色∶出纳员（Teller）、 经理（Manager），与系统管理者（Administrator）。不过当应用程式的建立者定义了应用程式的角色，但并没有指定哪些使用者与使用者群组属於哪个角色。因为将使用者指定到某个角色的动作将视应用程式的安装方式不同而不同。系统管理者可在应用程式安装时进行设定的动作。</span><span id=Layer16></font></p><p><font size=2 color=#3c3c3c face=arial>角色是一组使用者或使用者群组</span><span id=Layer17></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>角色是一组使用者或使用者群组</span><span id=Layer18></font></p><hr><p><font size=2 color=#3c3c3c face=arial>一旦定义了应用程式的角色，则每个角色的存取权限就可以管理介面详细设定。如图8-22所示，以角色为基础的授权是由COM runtime执行的，而不是由物件自己。假设在COM+应用程式中所有的物件的安全识别码与DBMS中的相同，所有的物件都具备相同的存取权限。这将大幅增加使用</span><span id=Layer19> <a target='_new' href=207.htm#>前章</span><span id=Layer20></a> 描述的连线共用区（connection pooling）特性来共享资料库连线的能力。因为JIT启动的关系，通常物件在每个method call获得这些连线，并释放这些连线如此能够有效地提升执行效能。</span><span id=Layer21></font></p><p><font size=2 color=#3c3c3c face=arial>基於呼叫者的角色来决定authorization</span><span id=Layer22></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>基於呼叫者的角色来决定authorization</span><span id=Layer23></font></p><hr><br><center><a target=_new href=imagesh/8-22.gif><img border=0 src='imagesl/8-22.gif'></a></center></span><span id=Layer24><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-22</span><span id=Layer25> </b></font>以角色为基础的授权是由COM runtime进行的。</span><span id=Layer26></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>Role-base授权可以设定在元件阶层、介面阶层以及method阶层。这也就是说，客户端可以基於套用到元件的角色，然後被授权存取整个元件，或元件的特定介面，或甚至是元件上的特定的method。所有的动作则可透过元件服务管理工具来完成，这些设定并不会出现在元件本身的程式码中。若要在执行时期决定元件是否设定安全组态，元件中的method可以呼叫它的Object Context 的IObjectContext介面所提供的IsSecurityEnabled method。</span><span id=Layer27></font></p><p><font size=2 color=#3c3c3c face=arial>存取的动作可以以元件、特定介面或特殊的method为基准</span><span id=Layer28></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>存取的动作可以以元件、特定介面或特殊的method为基准</span><span id=Layer29></font></p><hr><p><font size=2 color=#3c3c3c face=arial>Method阶层的authorization是COM+的新特性，MTS只允许验证介面阶层或整个元件。</span><span id=Layer30></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>Method阶层的authorization是COM+的新特性，MTS只允许验证介面阶层或整个元件。</span><span id=Layer31></font></p><hr><p><font size=2 color=#3c3c3c face=arial>图8-23 展示运作的情形。如图所示两个客户端，其中一个为Teller角色，另一个则是Manager角色，这叁个物件全都属於同一个COM+应用程式。图中最上方的物件设定为允许Tellers或Managers存取，因此这两个客户端都可以呼叫任一个介面上的任一个method。中间的元件设定为只允许Managers存取，这代表COM runtime将会不让任何Tellers或Administrators的成员存取。最下面的元件可同时让Tellers与Managers存取，在Administrator角色中，客户端唯一可以呼叫的便是其它的介面。因此，从Manager发出的呼叫将不能执行，如图所示。再度强调，虽然图中没有显示，如有必要存取权限可以method为基准来进行授权。</span><span id=Layer32></font></p><p><font size=2 color=#3c3c3c face=arial>COM runtime将不让具有错误角色的客户端进行呼叫的动作</span><span id=Layer33></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>COM runtime将不让具有错误角色的客户端进行呼叫的动作</span><span id=Layer34></font></p><hr><br><center><a target=_new href=imagesh/8-23.gif><img border=0 src='imagesl/8-23.gif'></a></center></span><span id=Layer35><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图8-23</span><span id=Layer36> </b></font>元件、介面与method能基於角色来授予客户端存取权限</span><span id=Layer37></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>这类宣告的role-base授权相当有用。不过有许多的情况显示出它的不足。举例来说，假设应用程式允许接听电话的Teller转帐$100,000，不过需要经理进行转帐的动作。现在很有可能在COM+应用程式的物件上定义了两个个别的method，然後只允许正确的角色进行存取。使用一个单独的method可能很简单。在这个情况下，这个method可能善用所谓的程式化安全性（programmatic security）。这个特性依赖IObjectContext介面提供的另一个method。如名称所暗示，这个method允许你判断呼叫者是不是某个特定角色的成员。在前述的范例中，MoveMoney method的程式码可能会使用它来验证企图转帐超过金额$100,000的人是否是Manager角色的成员，并拒绝其它未经授权的人存取。</span><span id=Layer38></font></p><p><font size=2 color=#3c3c3c face=arial>物件可以自行决定下定role-base授权的决策</span><span id=Layer39></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>物件可以自行决定下定role-base授权的决策</span><span id=Layer40></font></p><hr><font color=#3e72d7 face=arial size=4><b>模拟与代理（Impersonation and Delegation）</span><span id=Layer41></b></font><p><font size=2 color=#3c3c3c face=arial>当你要做的事情是控制哪个客户端可以执行COM+应用程式中特定的程式码时，Role-base授权，会是一个好的解决方案，不管使用的是宣告安全性或程式化安全性。不过这类的授权永远都不够。举例来说，假想一下你想要控制某些特定的资料只能让某些特定的客户端存取，而不是控制客户端可以执行哪些程式码。在这个情况下，你可能较喜爱使用DBMS提供的授权函数来完成这个工作。</span><span id=Layer42></font></p><p><font size=2 color=#3c3c3c face=arial>Role-base授权并非永远都是正确的选择</span><span id=Layer43></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Role-base授权并非永远都是正确的选择</span><span id=Layer44></font></p><hr><p><font size=2 color=#3c3c3c face=arial>下这个决定的其中一个重要理由便是资料库管理者（DBA）。除了DBMS之外，不愿意相信其它东西提供的资料安全性机制。依赖COM+中的role-base授权（它必须同时可使用程式或管理工具进行设定，并能正确运作）可能会让DBA非常的紧张。同样地，使用以角色为基础的安全性对於某些资料的存取，如允许特定的使用者存取特定的资料来说，并非很有效率。类似如此的情况，COM+应用程式需要使用发出要求的客户端之识别码来存取DBMS。换句话说，每个物件需要模拟它的客户端。在某些情况下，一个模拟客户端的物件必须同时跨越机器边界存取其它的行程。若要如此不但需要代理的动作，也需要模拟的动作。</span><span id=Layer45></font></p><p><font size=2 color=#3c3c3c face=arial>如有必要，物件可以模拟它的客户端</span><span id=Layer46></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>如有必要，物件可以模拟它的客户端</span><span id=Layer47></font></p><hr><p><font size=2 color=#3c3c3c face=arial>模拟与代理的基本概念已在</span><span id=Layer48> <a target='_new' href=203.htm#>第叁章</span><span id=Layer49></a> 中描述，这些特性在COM的用法则在</span><span id=Layer50> <a target='_new' href=205.htm#>第五章</span><span id=Layer51></a> 描述。身为COM+应用程式一部份的物件，其method能模拟它的客户端，就如同一个COM物件一样。同时，若伺服器的帐户是在Active Directory中组态设定为信任进行代理的动作，同时客户端也允许这件事，那麽伺服器（server）便可以使用客户端的识别码跨机器进行呼叫的动作。虽然如此，但仍要小心，一般说来模拟代表的意义是每条与资料库建立起来的连线都是使用特定的使用者识别码，若这个连线置入连线共用区（pool），它只能让同一个使用者重复使用。这将使</span><span id=Layer52> <a target='_new' href=206.htm#>第六章</span><span id=Layer53></a> 描述的资料库连线共同区的机制变得不再那麽地有用。</span><span id=Layer54></font></p><font color=#3e72d7 face=arial size=4><b>学习关於物件的呼叫者</span><span id=Layer55></b></font><p><font size=2 color=#3c3c3c face=arial>对於物件中正在执行的method而言，了解呼叫它行程之识别码为何（也就是直接的呼叫者）通常是很有用的。当许多物件一起使用时，一个物件呼叫下个物件的method，了解原始呼叫者也是很有用的。若要得到这个资讯，COM+提供ISecurityCallContext介面，使用它的method，物件能够存取关於呼叫者的资讯。这些资讯包含直接呼叫者（direct caller）的Security ID （SID）、原始呼叫者（original caller）的SID、在呼叫序列中用在任何呼叫上的最小验证等级（authentication level）...等等。ISecurityCallContext介面同样也包含IsCallerInRole method，提供和IObjectContext::IsCallerInRole相同的服务。ISecurityProperty有效地取代前版MTS所提供的介面，ISecurityProperty。事实上，COM+应用程式不应使用这个旧的介面，它的某些method已不能确保可以正常地运作。</span><span id=Layer56></font></p><p><font size=2 color=#3c3c3c face=arial>物件可以使用lSecurityCallContext来得知它的直接呼叫者与原始呼叫者是谁</span><span id=Layer57></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>物件可以使用lSecurityCallContext来得知它的直接呼叫者与原始呼叫者是谁</span><span id=Layer58></font></p><hr><p><font size=2 color=#3c3c3c face=arial>提供分散式应用程式好的安全性本来就不容易了。建构在COM runtime的安全性服务能够提供协助，特别在role-base授权能满足需求时。不过了解要解决的问题，以及可用的服务是没有东西可以替代的，然後思考一下正确的解决方案。</span>
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -