关于安全共性服务构件的一点理解

最近一直在讨论安全共性服务构件，但怎么也想不通，如何把安全应用作为一个共性服务对外发布。

（这里的服务是一个比较宽泛的概念，既包括Web Service 这种明确的服务类型，也包括Saas这种概念的服务，即在线软件，类似于google map，google doc，他们是有独立的前台页面，是一个完整的Web应用）

首先谈一下我对共性服务构件的理解，从我们现在看到的一些服务构件的举例，可以发现，现在的服务构件都是一些由第三方提供的，具有独立功能，不依赖于调用者的任何信息（除了要求的功能参数）的应用服务。

比如说天气查询服务，这个服务的提供方它自己维护者自己系统的运行，它可以连接到天气数据库，用户使用这个服务时候，只需要输入地址查询就可以。

再比如goole map，它自已有地图数据库，用户只需要输入查询地址，就可以看到相关地图。

再比如goole doc，它有自己的存储系统，用户可以在自己的帐户内上传文件，查看、编辑文件。

而安全应用和上面这些应用最大的不同点在于，安全应用是为这些应用服务的，它不是一个具有完整的独立功能的应用。以google doc为例，它是一个有独立功能的服务，但它需要一些安全方面的保护，比如对用户身份的认证。你可以把认证模块加入google doc这个服务实现的系统中去，这样这个服务在运行的时候，就首先会对用户进行认证。但是，你可以把认证这个模块作为一个服务单独发布出去吗?

认证，如果从服务的角度来看的话，它需要有用户与应用服务提供方这两个参与者。它的一个核心思想是为应用服务方来提供服务的，也就是由应用服务方来调用它。但同时呢，它还需要有用户的凭证作为参数，因此，就出现了下面两种认证模式的存在：

 

 

 

 

 

 

 

 

 

 

 

图1—直接认证模式

 

 

 

 

 

 

 

 

 

 

图2—代理认证模式

第一种模式，在基于浏览器的访问中比较合适，同时它支持用户的一个帐户访问多个应用服务，另外也适宜做单点登陆。

第二种模式，可以兼容各种访问情况，如客户端的，但在普通的基于浏览器的口令认证模式下，它不支持同一个帐户对应多个应用服务（主要指现在这种直接将口令通过form表单传送到服务器端的口令认证方式，因为服务器端会知道用户口令，如果像银行网站这种需要下载安全插件的，可以支持），但这种模式下似乎没有办法实现单点登陆。

（以上图示中，认证服务器需要身份数据库进行认证，主要是针对口令认证，或指纹认证之类的认证方式，如果采用证书认证，那么身份数据库就不一定是必须的，而应用服务器信任的CA证书就是必须的）

以上就是把认证作为单独的一个模块拿出来后，它所能提供功能的图示。那么，现在我们看，它可以作为一个独立的第三方服务对外提供吗？能或不能，关键在认证服务器需要的用户身份数据库。

无论这个数据库是由认证服务器来维护还是应用服务自己来维护，都需要应用服务器与认证服务器提前有一个前期的交互，完成信任的协商，以及数据库信息的同步，然后它才能够为这个应用服务器提供认证服务。

也就是说，认证服务可以以Saas的方式来提供服务。

首先，应用服务器端如果要用它的认证服务，需要先在认证服务器端注册，注册的时候需要指定，是否由认证服务器完成用户注册，如果不用，就只需要把相关数据库的地址及访问用户名密码告诉该认证服务器，如果用，就需要把相关的注册信息告诉认证服务器。这样就解决了数据库的问题。

然后，当用户要访问应用服务器的时候，它可以任意采用两种认证模式中的一种来调用认证服务器的认证服务。

以上过程相当于实现了认证托管功能。如果把认证服务器再扩展一下，就变为一个完整的身份管理系统了。

以上就是把认证以Saas的方式对外提供服务的一种实现方案吧。

对于访问控制，可以采用类似的思考模式，前提是采用了基于策略的访问控制模式，那么应用服务端只需要把相关的策略交给访问控制服务器端，但这里的难题恐怕在于如何把所有的访问控制行为都用策略表示出来，其中对于客体的描述是最麻烦的。