用户属性查询的方法、提供服务的方法及设备的制作方法

文档序号:7691593阅读:110来源:国知局

专利名称::用户属性查询的方法、提供服务的方法及设备的制作方法
技术领域
:本发明涉及通信领域,具体涉及用户属性查询的方法、提供服务的方法及设备。
背景技术
:Web服务网络(OMAWebService,OWSER)l.l介定如何以WebService技术公开、发现和使用OMA应用程序。OMAWebService1.1列出有关存取、认证和授权的参数,使开发商得以确保数据完整和保密保密资料的传输。此外,用户也可以不通过OMAWebServicel.l发现已登记的原码及服务说明。Web服务网络身份(OMAWebServiceNetworkIdentify,OWSERNI)1,O提供各种协议与服务,令OMA的服务和应用程序在Ligerty网络服务环境中具有联合身份。WebService体系结构基于三种角色(服务提供者、服务注册中心和服务请求者)之间的交互。交互涉及发布、查找和绑定操作。这些角色和操作一起作用于Web服务构件Web服务软件模块及其描述。在典型情况下,服务提供者托管可通过网络访问的软件模块(Web服务的一个实现)。服务提供者定义Web服务的服务描述并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作来从本地或服务注册中心检索服务描述,然后使用服务描述与服务提供者进行绑定,并调用Web服务实现或同它交互。服务提供者和服务请求者角色是逻辑结构,因而服务可以表现两种特性。下图显示了这些操作,以及提供这些操作的组件及它们之间的交互。对于利用Web服务的应用程序,必须发生以下三个^f亍为发布月l务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。这些操作具体为发布为了使服务可访问,需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化。查找在查找操作中,服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型。对于服务请求者,可能会在两个不同的生命周期阶段中牵涉到查找操作在设计时为了程序开发而检索服务的接口描述,而在运行时为了调用而检索服务的绑定和位置描述。绑定最后需要调用服务。在绑定操作中,服务请求者使用服务描述中的绑定细节来定位、联系和调用服务,从而在运行时调用或启动与服务的交互。现有技术方案中,一个用户使用某个SP完成某项业务的时候,需要通过Idp的身份认证,以及完成用户属性的查询。在对现有技术的研究和实践过程中,发明人发现现有技术存在以下问题在一个用户通过SP完成某项服务的时候,是需要向属性提供商查询查询,查询的内容是该登陆用户本人的相关信息;因为当前提供的服务只能查询本人的相关属性信息,无法查询其他用户的属性信息。而在实际上,一个用户代替另一个用户订购某项业务或者产品的需求是存在的,例如用户A代替用户B在网络上订购一张电影票等情况,但是因为本次订购无法查询到用户B的相关信息,将无法完成订购。
发明内容本发明实施例解决的技术问题是提供用户属性查询的方法、提供Web服务的方法及设备,可以实现对用户对其他用户属性信息的查询。本发明实施例提供一种用户属性查询的方法,包括接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。本发明实施例提供一种提供服务的方法,其特征在于,包括接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第一用户的用户身份信息和第二用户的用户身份信息;接收当属性提供商设备判断所述第一用户有权限查询所述第二用户的属性时返回的第二用户的属性信息;才艮据所述第二用户属性信息为所述第二用户^t是供服务。本发明实施例提供一种属性提供商设备,包括查询请求接收单元、判断单元、属性查询单元和反馈单元;查询请求接收单元,用于接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;判断单元,用于判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则通知属性查询单元查询查询所述第二用户的属性;属性查询单元,用于根据所述判断单元的通知进行属性查询;反馈单元,用于将将所述属性查询单元查询到的第二用户的属性信息返回给所述服务提供商设备。本发明实施例提供一种身份鉴别提供商设备,包括身份鉴别单元、存储单元和信息反馈单元;身份鉴别单元,用于对用户的身份进行认证,并接收通过认证的用户的请求;将至少两个用户的身份信息进行联合,并保存联合信息到存储单元;所述存储单元,用于保存联合信息;信息反馈单元,用于在收到服务提供商设备对用户的身份鉴别请求时,在所述存储单元中查找所述用户是否存在联合信息,若存在,则将所述用户联合信息返回给所述服务提供商设备。本发明实施例提供一种Web服务提供系统,包括服务提供商设备和属性提供商设备;所述服务提供商设备用于接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;并向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第一用户的用户身份信息和第二用户的用户身份信息;所述服务提供商设备还用于在获得属性提供商设备返回的所述第二用户的属性信息后,根据所述第二用户端额属性信息为所述第二用户进行服务;所述属性提供商设备用于判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则进行属性查询并将查询的第二用户的属性信息返回给所述服务提供商设备。采用上述技术方案,本发明实施例有益的技术效果在于本发明实施例中,属性提供商设备接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。通过本发明实施例的技术方案,可以实现对用户对其他用户属性信息的查询,进而一个用户可以帮助其他用户完成相应的服务,增加了SP为用户提供业务的多样性,增强了用户体验,提高了服务效率。图1为本发明实施例一用户属性查询的方法的流程图;图2为本发明实施例二用户属性查询的方法的流程图;图3为本发明实施例三提供Web服务的方法的流程图;图4为本发明实施例四属性提供商设备的逻辑结构示意图;图5为本发明实施例四判断单元一种逻辑结构示意图;图6为本发明实施例四判断单元另一种逻辑结构示意图;图7为本发明实施例四实施例四判断单元再一种逻辑结构示意图;图8为本发明实施例五一种身份鉴別提供商设备的逻辑结构示意图;图9为本发明实施例六一种服务提供系统的逻辑结构示意图;图10为本发明实施例七用户属性查询的方法的实体间的信令图;图11为本发明实施例八用户属性查询的方法的实体间的信令图;图12为本发明实施例九用户属性查询的方法的实体间的信令图。具体实施例方式本发明实施例提供了用户属性查询的方法、提供服务的方法及设备,可以实现对用户对其他用户属性信息的查询。下面对本发明提供的用户属性查询方法、提供服务的方法及设备进行详细描述。实施例一,一种用户属性查询的方法,流程图如图l所示,包括Bl,属性提供商设备接收服务提供商设备发送的对笫二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;B2,属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若是,则继续步骤B3;若否,则继续步骤B4。B3,属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。B4,通知所述服务提供商设备没有权限,无法查询。本发明实施例一技术方案可以实现对用户对其他用户属性信息的查询,进而一个用户可以在登录SP后,可帮助其他用户完成相应的服务为其他用户提供相应的业务,增加了SP为用户提供业务的多样性,增强了用户体验,提高了服务效率。实施例二,一种用户属性查询的方法,流程图如图2所示,包括Cl,服务提供商设备接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第二用户身份信息;C2,所述服务提供商设备与身份鉴别提供商设备进行交互,对所述第一用户的身份信息进行认证,若认证通过,则继续步骤C4,若认证失败,则继续步骤C3;本发明实施例中,所述对所述第一用户的身份信息进行认证的过程包括向服务提供商设备向用户身份鉴别提供商设备发送用户认证请求;用户身份鉴别提供商设备对该所述第一用户进行身份认证,并返回认证结果。C3,向通知所述第一用户认证失败,拒绝提供业务。C4,服务提供商设备向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第二用户的身〗分信息;可以理解的是,服务提供商可以与发现服务器交互获得属性提供商设备的地址。本发明强调的是,现有的服务提供商设备有能力获得属性提供商设备的地址,并与之进行通信,具体如何获取到属性提供商的方式可以采用常规方式实现,此处不做赘述。C5,属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若是,则继续步骤C6;若否,则继续步骤C7。本发明实施例中,所述判断所述第一用户是否有权限可以采取多种方式下面列举几种可行的方式,具体的方式不构成对本发明的限制。方式一所述属性提供商设备向所述第二用户发送鉴权请求;所述鉴权请求包含所述第一用户的用户身份信息;所述第二用户判断所述第一用户设备是否有权限查询属性;并将判断的结果返回给所述属性提供商设备。上述方式一中,属性提供商设备向所述第二用户确认第一用户的查询权限,属性提供商设备和所述第二用户设备之间,可以通过交互服务器进行信令转换进行通信。方式二属性提供商设备将所述第一用户的身份信息与所述第二用户的相关属性访问权限列表进行比较;若所述第一用户的身份信息属于所述相关属性访问权限列表,则判断所述第一用户有权限查询。可以理解的是,对于所述相关属性访问权限列表保存在属性提供商设备,用户可以与属性提供商设备交互对所述相关属性访问权限列表进行配置,具体包括所述第一用户与所述第二用户进行协商iU正,通过协商iU正后,所述第二用户为所述第一用户配置相关属性访问权限列表;所述相关属性访问列表保存在属性提供商设备。这里的配置可以是生成对相关属性访问列表或对已有的相关属性访问列表进行添加、修改等操作。更详细的相关属性访问列表的表现方式可以参见实施例九。方式三所述属性提供商设备判断所述服务提供商设备发送的对第二用户的属性查询请求中是否包含所述第一用户与所述第二用户进行联合的联合信息;若包含,则判断所述第一用户有权限。可以理解的是,所述第一用户与所述第二用户的联合信息可以是用户通过特定的渠道预先配置,例如所述服务提供商设备接收第一用户发送的为第二用户进行的业务请求之前包括所述身份鉴别提供商设备将所述第一用户的身份信息和所述第二用户和的身份信息建立联合并保存联合信息;这里的联合信息可以用于证明所述第二用户与第一用户之间的信任关系;联合信息中可以包括第一用户的身份信息和第二用户的身份信息的绑定关系;还可以包括所述第二用户对所述第一用户开;^文的属性信息的类型等。所述步骤C2服务提供商设备与身份鉴别提供商设备进行交互,对所述第一用户进行认证的过程中可以进一步包括所述身份鉴别提供商设备查找所述第一用户是否存在联合信息;若存在则将联合信息返回给所述服务提供商设备;所述接收服务提供商设备发送的对第二用户的属性查询请求中包含所述联合信息。C6,属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。C7,通知所述服务提供商设备没有权限,无法查询。本发明实施例中,用户在对某个用户的属性进行查询的同时如果查阅的属性是需要用户同意才可以查阅的内容,充分考虑到用户间的信任确认问题。如果用户在查阅其他用户属性信息的过程中,给出了三种具体的优选实现方式对用户的查询权限,用户间的信任关系的约束进行了说明。更好的实现了本发明技术方案。实施例三,一种提供服务的方法,流程图如图3所示,包括Dl,服务提供商设备接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;可以理解的是,所述接收第一用户发送的为第二用户进行的业务请求后进一步包括服务提供商设备对所述第一用户的身份信息进行认证,若认证通过,继续所述步骤D2。具体对第一用户进行认证的过程可以包括向用户身份鉴别提供商设备发送用户认证请求;用户身份鉴别提供商设备对该所述第一用户进行身份认证,并返回认证结果。可以理解的是,所述向用户身份鉴别提供商设备发送用户认证请求后,本发明实施例可以进一步包括接收所述当身份鉴别提供商查找所述第一用户存在联合信息时返回的给所述第一用户与所述第二用户的进行联合的联合信息;向属性提供商设备发送对第二用户的属性查询请求中包含所述联合信息。一般情况下,所述联合信息可以随对所述第一用户的认证结果一起返回。D2,服务提供商设备向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第一用户的用户身份信息和第二用户的用户身份信息;D3,属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若是,则继续步骤D5,若否则继续步骤D4;D4,向通知所述第一用户认证失败,拒绝提供业务。D5,属性提供商设备进行属性查询并将查询的第二用户的属性信息返回给所述服务提供商设备;D6,所述服务提供商设备获得所述第二用户的属性信息后,根据所述第二用户端额属性信息为所述第二用户进行服务。可以理解的是,所述步骤D6之后可以包括所述属性提供商设备向所述第一用户返回服务的结果。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括如下步骤属性提供商设备接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。上述提到的存储介质可以是只读存储器,磁盘或光盘等。实施例四,一种属性提供商设备500,逻辑结构示意图如图4所示,包括查询请求接收单元510、判断单元520、属性查询单元530和反馈单元540;查询请求接收单元510,用于接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;判断单元520,用于根据所述判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则通知属性查询单元530查询查询所述第二用户的属性;属性查询单元530,用于根据所述判断单元的通知进行属性查询;反^St单元540,用于将将所述属性查询单元530查询到的第二用户的属性信息返回给所述服务提供商设备。本实施例中,所述判断单元520可以采取不同的判断方式。一并参阅图5,为所述判断单元520—种逻辑结构示意所述判断单元520可以包括列表保存单元521和比较单元522;所述列表保存单元521,用于保存所述第二用户的相关属性访问权限列表;所述比较单元522,用于将所述第一用户的身份信息与所述列表保存单元521保存的第二用户的相关属性访问权限列表进行比较,若所述第一用户的身份信息属于所述相关属性访问权限列表,则判断所述第一用户有权限查询。一并参阅图6,为所述判断单元的内部另一种逻辑结构示意所述判断单元包括520:鉴权请求单元523和鉴权响应接收单元524;所述鉴权请求单元523,用于向所述第二用户发送鉴权请求;所述筌权请求包含所述第一用户的用户身份信息;所述鉴权请求响应单元524,用于接收第二用户设备返回的鉴权结果;所述鉴权结果指示所述第一用户是否有权限查询所述第二用户的属性。一并参阅图7,为所述判断单元的内部再一种逻辑结构示意所述判断单元包括520:联合信息检查单元525和决策单元526;所述联合信息检查单元525,用于检查所述查询请求接收单元接收的对第二用户的属性查询请求中是否包含所述第一用户与所述第二用户进行联合的联合信息;并将检查结果发送给决策单元;所述决策单元526,用于在所述检查单元的检查结果为存在联合信息时,通知所述查询单元进行第二用户的属性查询。实施例五,一种身份鉴别提供商设备900,结构示意图如图8所示,包括身份鉴别单元910、存储单元920和信息反馈单元930;身份鉴別单元910,用于对用户的身份进行认证,并接收通过认证的用户的请求;将至少两个用户的身份信息进行联合,并保存联合信息到存储单元920;所述存储单元920,用于保存联合信息;信息反馈单元930,用于在收到服务提供商设备对用户的身份鉴别请求时,在所述存储单元920中查找所述用户是否存在联合信息,若存在,则将所述用户联合信息返回给所述服务提供商设备。实施例六,一种服务提供系统,逻辑结构示意图如图9所示,包括服务提供商设备1010和属性提供商设备1020;所述服务提供商设备1010,用于接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;并向属性提供商设备1020发送对第二用户的属性查询请求;所述属性查询请求包含所迷第一用户的用户身份信息和第二用户的用户身份信息;所述服务提供商设备还用于在获得属性提供商设备1020返回的所述第二用户的属性信息后,根据所述第二用户端额属性信息为所述第二用户进行服务;所述属性提供商设备1020,用于判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则进行属性查询并将查询的第二用户的属性信息返回给所述服务提供商设备1010。下面结合具体的应用场景对本发明技术方案进行详细描述,以下实施例中,均实现在OWSERNI网络中。实施例七,一种用户属性查询的方法,通过本方案,用户A可以在SP登陆,然后通过Idp的认证,再由发现服务给出所需要查阅用户B的属性服务商地址,通过用户B的认证,用户A可以通过SP获取用户B允许查阅的某些属性。本实施例方案的主要思想在于,用户A可以通过SP为用户B进行服务。通常意义上的OWSERNI都是用户为自身通过SP查询属性来提供服务,但是当出现需要通过某用户终端为其他用户服务的情况时就需要在发生服务的时候查询所需服务的用户属性。通常我们所说的属性,都是保存在一个叫做属性服务商的逻辑地址中。例如用户的位置信息就是一种属性,那么提供这种属性的服务商就可能会去查找家庭用户服务(HSS)等设备,来确定用户的位置信息。考虑到隐私方面的问题,用户的某些属性是不能够直接提供给其他人的,因此在查阅某些属性的时候就需要该用户同意。本实施例的前提条件是用户A和B都已经通过了Idp的认证。本实施例中用户A/B与服务提供商SP和交互服务之间的交互属于现有技术,为了能够更完整的将过程表现出来,这里还是在图中表示出来,分别用a/b/c/d来区别。实体间的信令图如图10所示,包括Fl,用户A登陆服务提供商SP;服务提供商SP向属性提供商提出属性查找的请求;服务提供商可以使用LibertyDataServiceTemplate(DST)定义的机制来向属性提供商发起查询。在这种情况下,一个服务提供商必须使用〈Query〉元素,且属性提供商在对服务提供者的响应中必须使用<QueryResponse〉元素。下面是一个〈Query〉的例子,其资源以资源IDhttp:〃OWSER-attributeprovider.com/u6gh8jlx90bt8hlo作为标识.,对名字和家庭住址作为查询<ResourceID>http:〃OWSER-attribute-provider.com/u6gh8jlx90bt8hlo</ResourceID〉<QueryItemitemID="name"><Select>/pp:PP/pp:CommonName</Select></QueryItem><QueryItemitemID="home"〉<Select>/pp:PP/pp:AddressCard[pp:AddressType="urn:liberty:id-sis-pp:addrType:home"]〈/Select〉〈/Queryltem〉</Query〉F2,属性服务提供商为了获取其它用户的认证,需要通过交互服务向其他用户发送请求;属性服务提供商通过发送〈InteractionRequest〉元素到交互服务。下面是一个〈InteractionRequest〉的侈'J子<InteractionRequest"><ResourceID〉http:〃OWSER-attribute-provider.com/u6gh8jlx90bt8hlo</ResourceID><Inquirytitle="attribute-providerquestion"〉<HelpmoreLink="http:〃pip.example.com/help/attribute/read/consent">example.comisrequestingyouraddress.Wedonothavearulethatinstructsushowyouwantustoprocessthisrequest.Pleasepickoneofthegivenoptions.Notethatthelasttwooptionsdopreventyoufrombeingpromptedthisquestionwhenexample.comasksforyouraddressagain.</Help>〈Selectname="addresschoice"><Label〉Doyouwanttoshareyouraddresswithattribute-provider.com</Label><Value〉no</Value><Itemlabel="Notthistime"value="no"/><Itemlabel="Yes,once"value="yes'V><Itemlabel="No,never"value="never"><Hint>Wewon'tgiveoutyouraddressandwon'taskyouagain</Hint></Item><Itemlabel="Yes,always"value="always"><Hint>Wewillshareyouraddressnowandinthefuturewith-641service-provider.com</Hint></Item></Select〉</Inquiry〉</InteractionRequest〉上面的例子就是属性服务提供商向交互服务所提出的查询用户B地址属性的请求。F4,交互服务向用户B发送消息,询问是否同意属性被查询;交互服务可以通过HTTP将询问消息发送到用户B,询问B是否允许查询用户属性。例如,本例中查找的是用户名字和住址。F5,用户向反馈交互服务器反馈查询响应;如果用户同意对名字和住址的查询,则,用户可以通过HTTPPOST方法反馈给交互服务。F6,交互服务将对用户B的查询响应结果反馈给属性服务^t是供商;交互服务通过交互后发送含有〈InteractionResponse〉元素的响应消息到属性服务提供商。<InteractionResponse>〈Statuscode="is:success"/><InteractionStatement>〈Inquirytitle="ProfileProviderQuestion"id="inquiry-3d4e2f8a37213b">〈Selectname="addresschoice"〉<Label>Doyouwanttoshareyouraddresswith-753service-provider.com</Label><Value>always</Value></Select〉</Inquiry〉<ds:Signature><ds:Reference>#inquiry-3d4e2f8a37213b</ds:Reference〉....</ds:Signature〉</InteractionStatement></InteractionResponse〉F7,属性服务器根据交互服务器的查询结果,对SP反馈查询的结果;若所述用户B同意用户A查询用户B的属性,则本步骤属性服务器返回查询到的用户B的属性。下面是一个用于响应上面〈Query〉i青求的〈QueryResponse〉的例子。;斧源的7>共名字返回值为Dr.GenieWunderkid,另一个可选的7>共名字为Dr.GenieWunder。资源地址也已给出。<QueryResponse〉<Statuscode="OK7><DataitemIDRef="name"><GommonNam6><CN>GenieWunderkid</CN><AnalyzedNamenameScheme="firstlast"〉<FN>Genie</FN〉<SN>Wunderkid</SN><PersonalTitle>Dr.</PersonalTitle></AnalyzedName〉<AltCN>GenieWunder</AltCN></CommonName></Data〉<DataitemIDRef="home"〉<AddressCardid=,9812,><AddressType〉urn:liberty:id-sis-pp:addrType:home<AddressType〉<Address〉<PostalAddress>c/oSenthilSengodan$12278ScrippsSummitDrive</PostalAddress><PostalCode>92131-2341</PostalCode〉<L>SanDiego</L><ST>ca</ST><C〉us</C></Address〉</AddressCard〉</Data></QueryResponse〉F8,SP对用户A反々贵响应;本实施例中属性服务器对用户B的属性确认访问可以通过其它常规实现方式完成,具体的方式不构成对本发明的限制。实施例八,一种用户属性查询的方法,本实施例中用户A通过SP为用户B提供服务的方案。通过该方案,用户A在登陆SP后为用户B提供服务。用户A在查询用户B的某些属性之前和用户B进行了认证,结果是用户B同意用户A查阅自己的某些属性。该方案的主要思想在于,当用户A需要通过SP为用户B提供服务的时候,需要用户A先通过用户B的认证,这样,用户A就可以使用用户B的某些属性了。接下来用户A通过登陆SP然后再认证,获取属性服务提供商4是供的用户B的相关属性的时候就可以不再需要认证过程,而只需要像用户B自己操作一样方便了。下图本实施例中实体之间的信令流程如图11所示本实施例中对鉴权部分都通过虚线表示,实线部分为提供服务部分。Gl.用户A向Idp发送鉴^L;用户A要为用户B提供服务,那么用户A就首先需要通过Idp的认证。通过Idp的认证后用户A就表明在该信任圏内是一个合法的用户。G2.Idp对用户A进行鉴^又i人证;Idp是一种特殊的服务提供商角色,它生成、维护和管理用户的身份信息,并且能够为认证域(甚至一个信任圏)中的其他服务提供商提供认证声明。通过Idp的认证后,主题用户A就是该信任圈内的可信任用户。G3.用户Aj^起向用户B的请求鉴斗又;用户嫂送请求B的鉴权的同时,需要将自身的ID等表明身份的信息一并发送到用户B。需要将Idp对用户A的鉴权结果发送到用户B,以告诉用户B,用户A是通过信任圏认证的合法用户。G4.用户B向Idp进行身份认证。该认证过程可以包含连个过程;首先,用户B向Idp进行身份的认证,经过认证后,B的认证信息会保存在Idp上供后续服务时使用;其次,用户B会将受到的用户A的身份信息联合自己的身份信息发送到Idp。通过这个步骤,Idp会纪录A与B是需要联合。这里只是一个举例,具体的联合方法可以是多种方式的,但是其思想是一致的。用户A和用户B的身4分在Idp联合登记可以是用户B在进行认证过程中的一个附带过程。G5.Idp对用户B进^S人i正,并且对用户A和用户B耳关合纪录;经过Idp的认证后,B用户确认为该信任圏合法的用户,并且在Idp中会将A与B的信息进行帮定,以告诉以后的服务这两个用户通过了Idp的认证,并且他们之间是帮定关系。G6.用户B向用户嫂送键权消息;用户A在向用户B发送鉴权消息后,用户B反馈一个鉴权消息。经过这样的鉴权,用户B可以决定到底是不是需要A帮助自己来完成某些服务。G7.用户A登陆SP,获取服务;登陆SP属于现有技术范畴。可以通过HTTP等方式来完成。这里不过多的描述。需要注意的一点是,用户A在登陆SP需要将与B的联合信息一并带入到SP中,以通知SP是用户A要协助B获取服务。G8.SP对A进行认证;SP查阅Idp,获取A与B联合的纪录。G9.Idp反馈A与B的认证纪录以及联合纪录;G10.SP根据A所需服务查询相关属性;SP所查询的属性可能是用户B的属性,因此需要在属性服务提供商那里找B的属性。这一步骤省略了SP向发现服务获取AP信息的过程。SP会将A与B的联合信息一并发送到AP。Gl1.AP根据A所查的用户B属性反馈给用户A相关信息;AP根据Idp确认的联合信息,确认A是通过B的认证的合法用户,因此用户B的属性服务器可以为A提供这样的属性查询。G12.SP获取属性信息后,处理,并将最终服务结果发送给用户A。结果的发送可以通过多种方式,例如通过PS域或CS域的方式都可以。这里不作详细的说明。本实施例中对用户A与用户B的联合只是举例说明,如果有其他的方式,例如通过电话号码/邮件地址/userlD等方式都可以达到这样的目的,其它方式也可以达到相同的目的,原理是一致的。实施例九,一种用户属性查询的方法,本实施例中本用户A通过SP为用户B提供服务的方案。通过该方案,用户B在Ap上可以设置一个相关属性访问权限列表,表中所列的用户可以获得某些B属性的访问权限。通过这个方式,用户A可以获得表中某些属性的访问权限。该方案的主要思想在于,用户A在为用户B通过SP获取某些服务前,可以与B进行协商认证,通过这样的认证,B可以为A生成一个相关属性访问权限的列表,同时用户B可以将这个列表发送到属性服务器保存,以供后续服务使用。实体间的信令流程如图12所示,包括本实施例的前提是用户B已经通过了Idp的认证。Hl,用户A为了实现登陆SP为用户B完成服务首先需要得到用户B的认证;这一认证过程可以通过多种方式完成。例如可以通过发送请求信息,使用户B知道请求者是用户A;H2,用户B登陆SP1;登陆的方式可以使用HTTP等方式,这里不作详细的说明;H3,SPl通过Idp核对用户B的认证状态;H4,Idp回复请求,包括一个描述用户认证状态的认证断言;H5,SP1提供修改属性服务;SP1提出修改AP中关于用户B的可信任对象列表,该列表在属性提供商处维护,可以由SP提出修改。服务提供商必须使用〈Modify〉元素,且属性提供商在对服务提供者的响应中必须使用〈ModifyResponse〉元素。用户B的可以信任对象列表可能具有以下表1类似的形式表l<table>tableseeoriginaldocumentpage26</column></row><table>上面的可信任对象列表仅仅是一个举例,如果有其他形式可以表示,其原理也是一致的。H6,属性提供商反馈可信任对象列表修改结果;修改后的结果可能为表2的形式。表2<table>tableseeoriginaldocumentpage27</column></row><table>其中增加了对用户A关于访问用户B位置属性的获取权限。H7,SP1将修改的结果反馈给用户B,反馈的方式可以是多种的;H8,用户B反々赍用户A认证应答;用户B经过增加用户A的某些属性使用权限后,反馈给用户A结果。H9,用户A发起Idp认证;H10,Idp反々赍iU正结果给用户A;Hll,用户A登陆服务提供商SP2;用户A登陆SP2后的结果是希望能够为用户B完成某些服务;、H12,SP2核对用户A的认证状态;H13,Idp反馈给SP2用户A的认证状态,返回一个认证断言;H14,为了完成对用户B的服务需要某些用户B的属性,因此SP2在AP上查找用户B的某些属性;由于用户B已经将用户A力口入到某些属性的可获取权限中,所以用户A可以获取那些用户B提供的属性。这一过程需要AP将属性获取对象与可相关属性访问权限列表进行比较。H15,如果AP查找到用户A可以获得用户B的地址信息,那么AP就会将结果反馈给SP2;H16,SP2将最终的服务结果反馈给用户A,反馈的结果可以是多种形式的,例如通过HTTP的方式。本实施例中的相关属性访问权限列表与AP上对可以相关属性访问权限列表的维护都是举例说明,如果有类似的方式,其原理也使一致的。可以立即的是,本是实施例中,用户B可以将自己的某些属性公开,这样就可以让其他用户对自己进行某些操作或服务。该方案的主要思想在于,用户B事先就将自己的某些常用信息公开在属性服务商那里,这样,其他用户可以不需要经过用户B的认证就能够对用户B完成某些操作或服务。本实施例作为实施例三的补充,不同之处在于把某些属性设置为对所有人公开。只是在属性的保存信息上进行一些修改。修改可能集中在属性提供商AP上维护的属性信息。例如可以具有如下表3的形式<table>tableseeoriginaldocumentpage28</column></row><table>AP上维护多个这样的用户属性列表,这个表可以被用户B修改的,但是需要通过Idp认证,以及通过服务提供商完成。从上面的表可以看到对于用户B的姓名可以让任何人看到,并且是只读的,对于地址信息则显示可以让任何人查阅。因此如果属性服务商维护这样一个表以后,其他的用户如果需要查阅用户B的某些属性,那么只需要在访问属性提供商的时候查阅这样的列表,找出是否用户同意授权就可以了。用户B对该列表的维护或修改与上一个实施例完全相同。本实施例中所列出的属性服务商的用户属性列表仅是一个举例说明,如果有其他的方式可以保存属性信息,或者完成类似的属性操作,其原理是一致的,都在保护范围内。以上对本发明所提供的用户属性查询的方法、提供服务的方法及设备。进行了详细介绍,其中本发明一实施例中,属性提供商设备接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。通过本发明实施例的技术方案,可以实现对用户对其他用户属性信息的查询,进而一个用户可以在登录SP后,可帮助其他用户完成相应的服务为其他用户提供相应的业务,增加了SP为用户提供业务的多样性,增强了用户体验,提高了服务效率。并且本发明其他实施例中,用户在对某个用户的属性进行查询的同时如果查阅的属性是需要用户同意才可以查阅的内容,充分考虑到用户间的信任确认问题。如果用户在查阅其他用户属性信息的过程中,给出了三种具体的优选实现方式对用户的查询权限,用户间的信任关系的约束进行了说明。更好的实现了本发明技术方案。对于本领域的一般技术人员,依据本发明实施例的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。权利要求1、一种用户属性查询的方法,其特征在于,包括接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。2、如权利要求1所述的用户属性查询的方法,其特征在于,所述判断所述第一用户是否有权限查询所述第二用户的属性的步骤包括向所述第二用户发送鉴权请求;所述鉴权请求包含所述第一用户的用户身份信息;所述第二用户判断所述第一用户设备是否有权限查询属性;并将判断的结果返回。3、如权利要求1所述的用户属性查询的方法,其特征在于,判断所述第一用户是否有权限查询所述第二用户的属性的步骤包括将所述第一用户的身份信息与所述第二用户的相关属性访问权限列表进行比较;若所述第一用户的身份信息属于所述相关属性访问权限列表,则判断所述第一用户有权限查询。4、如权利要求3所述的用户属性查询的方法,其特征在于,还包括所述第一用户与所述第二用户进行协商认证,通过协商认证后,所述第二用户为所述第一用户配置相关属性访问权限列表;所述相关属性访问列表保存在属性提供商设备。5、如权利要求4所述的用户属性查询的方法,其特征在于,还包括所述第一用户与所述第二用户进行协商认证,通过协商认证后,所述第二用户为所述第一用户配置相关属性访问权限列表;所述相关属性访问列表保存在属性提供商设备。6、如权利要求1所述的用户属性查询的方法,其特征在于,所述判断所述第一用户是否有权限查询所述第二用户的属性的步骤包括判断所述服务提供商设备发送的对第二用户的属性查询请求中是否包含所述第一用户与所述第二用户进行联合的联合信息;若包含,则判断所述第一用户有*1限。7、如权利要求1至5任意一项所述的的用户属性查询的方法,其特征在于,所述将查询到的第二用户的属性信息返回给所述服务提供商设备之后包括所述服务提供商设备将所述第二用户的属性信息发送给所述第一用户。8、一种4是供服务的方法,其特征在于,包括接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第一用户的用户身份信息和第二用户的用户身份信息;接收当属性提供商设备判断所述第一用户有权限查询所述第二用户的属性时返回的第二用户的属性信息;根据所述第二用户属性信息为所述第二用户提供服务。9、如权利要求8所述的提供服务的方法,其特征在于,所述接收第一用户发送的为第二用户进行的业务请求后进一步包括所述对所述第一用户的身份信息进行认证,若认证通过,继续所述向属性提供商设备发送对第二用户的属性查询请求的步骤。10、如权利要求9所述的提供服务的方法,其特征在于,对所述第一用户的身份信息进行认证的步骤包括向用户身份鉴别提供商设备发送用户认证请求;用户身份鉴别提供商设备对该所述第一用户进行身份认证,并返回认证结果。11、如权利要求9所述用户属性查询的方法,其特征于,向用户身份鉴别提供商设备发送用户认证请求之后进一步包括接收所述当身份鉴别提供商查找所述第一用户存在联合信息时返回的给所述第一用户与所述第二用户的进行联合的联合信息;向属性提供商设备发送对第二用户的属性查询请求中包含所述联合信息。12、如权利要求8至11任意一项所述的提供Web服务的方法,其特征在于,所述根据所述第二用户属性信息为所述第二用户提供服务之后包括所述属性提供商设备向所述第一用户返回服务的结果。13、一种属性提供商设备,其特征在于,包括查询请求接收单元、判断单元、属性查询单元和反馈单元;查询请求接收单元,用于接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;判断单元,用于判断所述第一用户是否有权限查询所迷第二用户的属性;若所述判断的结果为有权限,则通知属性查询单元查询查询所述第二用户的属性;属性查询单元,用于才艮据所述判断单元的通知进行属性查询;反馈单元,用于将将所述属性查询单元查询到的第二用户的属性信息返回给所述服务提供商设备。14、如权利要求13所述的属性提供商设备,其特征在于,所述判断单元包括列表保存单元和比较单元;所述列表保存单元,用于保存所述第二用户的相关属性访问权限列表;所述比较单元,用于将所述第一用户的身份信息与所述列表保存单元保存的第二用户的相关属性访问权限列表进行比较,若所述第一用户的身份信息属于所述相关属性访问权限列表,则判断所述第一用户有权限查询。15、如权利要求13所述的属性提供商设备,其特征在于,所述判断单元包括鉴权请求单元和鉴权响应接收单元;所述鉴权请求单元,用于向所述第二用户发送鉴权请求;所述鉴权请求包含所述第一用户的用户身份信息;所述鉴权请求响应单元,用于接收第二用户设备返回的鉴权结果;所述鉴权结果指示所述第一用户是否有权限查询所述第二用户的属性。16、如权利要求13所述的属性提供商设备,其特征在于,所述判断单元包括联合信息检查单元和决策单元;所述联合信息检查单元,用于检查所述查询请求接收单元接收的对第二用户的属性查询请求中是否包含所述第一用户与所述第二用户进行联合的联合信息;并将检查结果发送给决策单元;所述决策单元,用于在所述检查单元的检查结果为存在联合信息时,通知所述查询单元进行第二用户的属性查询。17、一种身份筌别提供商设备,其特征在于,包括身份鉴别单元、存储单元和信息反馈单元;身份鉴别单元,用于对用户的身份进行认证,并接收通过认证的用户的请求;将至少两个用户的身份信息进行联合,并保存联合信息到存储单元;所述存储单元,用于保存联合信息;信息反馈单元,用于在收到服务提供商设备对用户的身份鉴别请求时,在所述存储单元中查找所述用户是否存在联合信息,若存在,则将所述用户联合信息返回给所述服务提供商设备。18、一种服务提供系统,其特征在于,包括服务提供商设备和属性提供商设备;所述服务提供商设备用于接收第一用户发送的为第二用户进行的业务请求;所述业务请求中包含第一用户的用户身份信息和第二用户的用户身份信息;并向属性提供商设备发送对第二用户的属性查询请求;所述属性查询请求包含所述第一用户的用户身份信息和第二用户的用户身份信息;所述服务提供商设备还用于在获得属性提供商设备返回的所述第二用户的属性信息后,才艮据所述第二用户端额属性信息为所述第二用户进行服务;所述属性提供商设备用于判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则进行属性查询并将查询的第二用户的属性信息返回给所述服务提供商设备。全文摘要本发明公开了一种用户属性查询的方法、提供服务的方法及设备,本发明实施例中属性提供商设备接收服务提供商设备发送的对第二用户的属性查询请求;所述属性查询请求包含第一用户的用户身份信息和第二用户的用户身份信息;属性提供商设备判断所述第一用户是否有权限查询所述第二用户的属性;若所述判断的结果为有权限,则属性提供商设备进行属性查询并将查询到的第二用户的属性信息返回给所述服务提供商设备。通过本发明实施例的技术方案,可以实现对用户对其他用户属性信息的查询,进而一个用户可帮助其他用户完成相应的服务,增加了SP为用户提供业务的多样性,增强了用户体验,提高了服务效率。文档编号H04L29/08GK101562627SQ200810093789公开日2009年10月21日申请日期2008年4月18日优先权日2008年4月18日发明者健杨,雷王,挺董申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1