阿里软件平台之个人剖析

    阿里软件平台作为一种新的SAAS架构在基于阿里平台和淘宝平台庞大用户的基础上在这一年的时间里得到了极大的关注，越来越多的软件开发者开发出自己的软件来服务于用户，体现了SAAS的价值。相信也有很多后来者想了解和熟悉这个平台并开发自己的应用，本人在阿里平台推出之初就开始关注，只是一直没有时间真正的来研究它，最近好好的研究了番，决定把自己的心得写出来给后来者或有经验者参考，理解或说错的地方还请大家见谅和指正(以下说明均是针对REST风格的请求而言，对于WEBSERVICE等其他方式则不在讨论之列)。

 

    首先得理解阿里平台里的几个概念：
SIP:service integration platform，即服务集成平台，作为中心处理各个服务请求，这里指的就是阿里软件平台；
ISV:independency software vendor，独立软件厂商，是提供最终给用户使用的软件的开发者；
ISP:internet service provider，互联网服务提供商，是提供开放API的厂商或开发者，如淘宝；

 

    整个平台运行由这三个部分参与，ISV对SIP发起服务请求，SIP经过一系列判断后将请求转发给ISP对应的服务，然后获取结果并返回给ISV，从而完成一次服务请求过程。SIP作为中心处理器负责维护ISV和ISP的相关信息，对于ISV就是软件的APPKEY和CERTCODE(相当于访问SIP的用户名和密码)；对于ISP就是维护API的相关信息，如名称和请求URL的对应关系，授权信息等(个人揣测)；SIP本身则负责基本校验(签名校验)、订购/购买、付费、授权/鉴权等操作。

 

    下面说说应用阿里平台中几个需要理解和注意的地方，有些是根据个人的经验进行的揣测。

 

一、免登陆

    免登陆主要是用来让终端用户通过阿里平台来免登陆到ISV的系统，仅此而已，没有其他用处。这样的好处就是用户在进入你的系统时不需要再次使用你提供的用户名和密码进行二次登陆了，简化了ISV系统的应用接入；从ISV的系统角度来讲，系统内部的东西是需要用户登陆后才能够进行的，相信很少或基本没有ISV的应用是可以直接进入的吧，而进入在WEB系统而言就是创建SESSION来识别用户，所以免登陆的用处还在于帮助ISV的系统进行用户的SESSION创建和授权操作。

 

我们来看下免登陆的操作流程：

 

1.终端用户登陆阿里平台，通过软件列表中的“进入使用”操作向阿里平台请求使用该ISV的软件；

 

2.SIP获取当前用户的ID、ISV软件的信息、用户订购的信息和自动生成的令牌TOKEN向ISV软件的入口发起登陆请求；

 

3.ISV软件获取对应的参数并马上回调SIP的免登陆接口进行确认，只有当SIP返回确认该请求是由SIP自身发起的，ISV的软件才应该认为该用户是正常的软件用户(包括订购者和使用者)。在确认成功后ISV的软件即可以为该用户创建SESSION并进行自己的业务授权了，从而完成用户对ISV软件的登录过程。

 

    通过这3个过程我们就可以避免非法用户对ISV软件的登录接口就行假登陆操作，因为在第3步中我们总是对SIP的网站发出请求进行验证，因而我们也总是相信该返回值的合法性，除非发生了域名劫持现象，呵呵。

 

二、开放API的调用

    阿里平台上的开放API有三种类型，apiType=1，只需要签名即可;apiType=2，需要签名同时需要终端用户对ISV软件进行人工授权操作；apiType=3，需要签名，用户授权可选，如果授权了可能从该API获取的数据信息就更多，否则只能够获取基本信息；

 

1.对于apiType=1的API调用

    对该类型的API调用就很方便了，只需要对请求参数进行签名后直接HTTP POST到SIP上去即可获得结果，终端用户在整个过程中无需干预，比如淘宝的商品搜索服务就是该类型的API。

 

2.对于apiType=2的API调用

    该类型的API调用需要终端用户手工授权，授权的意思就是当前终端用户允许当前这个应用可以调用该ISP中需要授权的开放API，其实也就是通过用户授权来绑定当前应用与ISP的API。授权首先需要终端用户登陆到ISP的系统中(比如淘宝ISP就需要终端用户使用淘宝的账号登陆淘宝系统)进行授权，授权和鉴权的过程由于隐藏在阿里平台的后端，我们无法得知，但根据相关的信息我揣测的过程如下(假设鉴权过程发生在SIP平台中)：

 

    首先看下ISV和SIP的交互过程：

    1)ISV软件向SIP发起一个API调用请求；

    2)SIP检查该API并确认为apiType=2的情况下进行鉴权操作；

    3)如果请求的参数中没有携带sip_sessionid参数则返回1012错误，必须指定sip_sessionid；

    4)根据sip_appkey和sip_sessionid在SIP平台中查找授权信息，没有找到或授权超时则返回1004错误，同时返回登录URL让ISV引导用户到该登陆地址进行登陆；如果鉴权成功则附带SIP和ISP之间的TOKEN后向ISP发起请求并获知结果返回给ISV；

    5)鉴权过程结束；

 

    然后看下在鉴权失败时SIP和ISP的交互过程，此时SIP已经返回1004错误给ISV了，ISV将引导用户进入给定的URL地址：

    1)ISV引导用户进入SIP返回的URL地址(错误1004返回的)，此时的URL还是SIP的地址；

    2)SIP根据sip_apiname参数查找对应的ISP的登录验证地址并重定向到ISP的登录页面，同时传递根据sip_appkey和sip_sessionid等参数按照一定规则生成的TOKEN，并在SIP平台中保存这种对应关系；

    3)用户使用该ISP的账号进行登陆，比如淘宝作为一个ISP就需要用户使用淘宝账号进行登陆；

    4)登陆成功后，用户选择授权时间(1小时、30分钟、10分钟、5分钟等)提交；

    5)ISP将用户的授权时间、SIP在第2步中传递给ISP的TOKEN等信息传递给SIP的特定URL，这个过程中ISP只能够通过特定IP的服务器发起该请求才会被SIP受理(根据阿里平台的1019错误推测)，否则将被SIP拒绝；

    6)SIP接到ISP的授权请求后，根据TOKEN将授权信息与sip_appkey、sip_sessionid进行绑定，从而完成授权过程；同时ISP将当前用户信息和SIP传递过来的sip_appkey、sip_sessionId也在自己的平台中进行绑定；

 

    整个鉴权/授权过程是一个连续的过程，授权需要用户的干预是为了保证信息的安全，我看到有人在论坛问为什么不能够通过API进行自动授权，如果这样其实就没有授权的必要了，我觉得这个设计非常好，恰如其分的联合了SIP、ISV、ISP和用户。另外，对于需要授权的API都需要传递sip_sessionid是为了绑定用户进行鉴权，让SIP知道当前来自ISV的请求是某一个特定用户的，同时也是为了让ISP根据sip_sessionid知道当前请求的是系统中的哪个用户，因为在上面的SIP和ISP的交互过程中的第6步中ISP已经绑定了用户信息和sip_appkey、sip_sessionId的对应关系，因此通过sip_appkey、sip_sessionId就可以唯一确定一个用户了。

    如果鉴权过程发生在ISP平台上的话，那么SIP就不需要绑定用户和授权信息了，而是通过ISP注册时的鉴权URL进行鉴权操作，当然这过程中为了保证数据的安全性也会进行加密/签名等步骤。基本过程估计都差不多，不过本人更倾向于前面的方案。

 

    授权完成后(也可称为用户和SIP的绑定)，在授权的时间里ISV发起对该ISP的API调用就不需要再进行授权操作了，从而也就是完成了用户对ISP的登录。以上过程是根据个人经验推测得到，如果不对还请大家指正。

 

 

三、ISV系统的权限分级

    对于ISV开发的系统如果功能很多，终端用户也有可能有权限划分的需求，因为用户在订购了ISV的软件后，他还可以设置使用该订购实例的用户，即一个订购实例可以被多个人同时使用，因此提供权限分级管理对于大型软件也是有必要的。进行权限设计要考虑到以下问题：

 

1.如何获取所有订购了该软件的用户；

  对于这个问题可以有2种解决方案：

  1)每个ISV的软件都有一个通知URL设置，这个是用户在软件超市中订购了软件后，阿里平台回调ISV系统的一个接口。该接口向通知URL传递用户的ID、软件实例的ID等信息。通过阿里平台的介绍，我们可以把实例ID(appInstanceId)当成一个组织或公司，拥有同样appInstanceId的用户都是同一个软件实例的使用者。在这里平台中将软件的用户分成2种类型，一是软件的订购者，可以认为是管理员；再一个就是软件的使用者，是由订购者邀请一起使用软件的其他用户，可以认为是一般用户。

  2)再一种方式就是用户在进行免登陆时通过alisoft.getUsingUse接口来获取当前用户所代表的实例的所有用户，然后存入ISV自己的数据库中。该接口只返回了用户ID和用户名称，然后我们可以通过alisoft.validateAppUser接口来获知用户在这个实例中代表的类型，可以查到谁是软件的订购者，谁是使用者。这种方式可以用来通知URL中处理异常时的有效补充。

 

2.如何区分用户所属的公司或组织；

    在1中已经介绍了，每一个appInstanceId都可以认为是一个组织或公司，而该实例的订购者则是该组织或公司的管理员，其他的则是普通的用户。

 

    解决了以上的问题后，我们权限系统的用户和组织、组织的管理员和一般用户等基本信息就都有了，然后在系统内部就是管理员按照权限来划分功能菜单给指定的用户了，这就是一般权限系统的设计过程了，就不多说了。

    以上几点是针对开发者需要注意的几点问题对阿里平台的一点剖析，希望对大家更深入的理解这个平台起到帮助作用，希望和大家一起交流：[e-mail]