首页> 中国专利> 业务角色鉴权方法以及相关装置

业务角色鉴权方法以及相关装置

摘要

本申请实施例公开了一种业务角色鉴权方法,用于实现应用软件的角色鉴权统一化,减少应用软件对角色逻辑策略的维护,进而减轻设备计算资源的重复消耗。本申请实施例方法包括:接收业务应用系统的目标业务的业务鉴权请求,所述业务鉴权请求包括用户的用户标识;在数据库中查询所述用户标识对应的业务角色;判断所述业务角色是否具有所述目标业务的使用权限;若所述业务角色具有所述目标业务的使用权限,则向所述业务应用系统发送允许所述用户使用所述目标业务的鉴权成功信息;若所述业务角色不具有所述目标业务的使用权限,则向所述业务应用系统发送不允许所述用户使用所述目标业务的鉴权失败信息。

著录项

  • 公开/公告号CN112287308A

    专利类型发明专利

  • 公开/公告日2021-01-29

    原文格式PDF

  • 申请/专利权人 深圳云之家网络有限公司;

    申请/专利号CN202011148688.X

  • 发明设计人 安庆;李奇丰;黄国华;

    申请日2020-10-23

  • 分类号G06F21/31(20130101);G06F16/903(20190101);

  • 代理机构44285 深圳市深佳知识产权代理事务所(普通合伙);

  • 代理人王兆林

  • 地址 518000 广东省深圳市前海深港合作区前湾一路1号A栋201室(入驻深圳市前海商务秘书有限公司)

  • 入库时间 2023-06-19 09:43:16

说明书

技术领域

本申请实施例涉及数据处理领域,特别涉及一种业务角色鉴权方法以及相关装置。

背景技术

在现有的应用软件管理策略中,应用软件会给不同的用户关联若干不同的预设角色,以便于在用户通过应用软件使用不同的业务时对用户的关联角色进行验证,即用户的关联角色有权限才能使用对应业务。

然而,现有技术中这种业务与预设角色在捆绑一起的应用软件中,当一台设备中运行的应用软件越多,那么每一个应用软件都需要维护与其他应用软件一样或类似的角色,导致设备的计算资源重复消耗越多。

发明内容

本申请实施例提供了一种业务角色鉴权方法以及相关装置,用于实现应用软件的角色鉴权统一化,减少应用软件对角色逻辑策略的维护,进而减轻设备计算资源的重复消耗。

本申请第一方面提供一种业务角色鉴权方法,应用在独立的鉴权系统,包括:

接收业务应用系统的目标业务的业务鉴权请求,所述业务鉴权请求包括用户的用户标识;

在数据库中查询所述用户标识对应的业务角色;

判断所述业务角色是否具有所述目标业务的使用权限;

若所述业务角色具有所述目标业务的使用权限,则向所述业务应用系统发送允许所述用户使用所述目标业务的鉴权成功信息;

若所述业务角色不具有所述目标业务的使用权限,则向所述业务应用系统发送不允许所述用户使用所述目标业务的鉴权失败信息。

可选地,在接收业务应用系统的目标业务的鉴权请求之前,所述方法还包括:

接收业务应用的应用身份注册请求;

根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

通过所述业务应用身份标识接收所述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

可选地,在通过所述业务应用身份标识接收所述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系之后,所述方法还包括:

备份所述述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系,形成备份鉴权数据;

使用所述备份鉴权数据执行鉴权业务;

更新所述业务应用系统预设的若干新业务角色、若干新用户标识、以及每一个所述新用户标识与若干所述新业务角色的关联关系,形成更新鉴权数据;

使用所述更新鉴权数据替换所述备份鉴权数据执行鉴权业务。

可选地,在接收业务应用系统的目标业务的鉴权请求之前,所述方法还包括:

接收业务应用系统的应用身份注册请求;

根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

接收用户对所述业务应用系统的用户身份注册请求;

根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收为所述用户标识关联在所述业务应用系统的若干业务角色;

保存所述业务应用身份标识、所述用户标识、所述用户标识在所述业务应用系统中与若干所述业务角色的关联关系。

本申请第二方面提供一种业务角色鉴权方法,应用在业务应用系统,包括:

接收用户针对目标业务的业务使用请求;

根据所述业务使用请求生成业务鉴权请求,所述业务鉴权请求包含所述用户的用户标识、所述目标业务;

向鉴权系统发送所述业务鉴权请求;

接收所述鉴权系统针对所述业务鉴权请求返回的鉴权结果;

根据所述鉴权结果确定所述用户是否可以使用所述目标业务。

可选地,在接收用户针对目标业务的业务使用请求之前,所述方法还包括:

接收所述用户的用户身份注册请求;

根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收为所述用户标识关联的若干业务角色;

向所述鉴权系统发送应用身份注册请求,所述应用身份注册请求包括预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

本申请第三方面提供一种鉴权系统,包括:

接收单元,用于接收业务应用系统的目标业务的业务鉴权请求,所述业务鉴权请求包括用户的用户标识;

查询单元,用于在数据库中查询所述用户标识对应的业务角色;

判断单元,用于判断所述业务角色是否具有所述目标业务的使用权限;

发送单元,用于若所述业务角色具有所述目标业务的使用权限,则向所述业务应用系统发送允许所述用户使用所述目标业务的鉴权成功信息;

发送单元,还用于若所述业务角色不具有所述目标业务的使用权限,则向所述业务应用系统发送不允许所述用户使用所述目标业务的鉴权失败信息。

可选地,所述系统还包括:

接收单元,还用于接收业务应用系统的应用身份注册请求;

生成单元,用于根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

接收单元,还用于通过所述业务应用身份标识接收所述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

可选地,所述系统还包括:

备份单元,用于备份所述述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系,形成备份鉴权数据;

使用单元,用于使用所述备份鉴权数据执行鉴权业务;

更新单元,用于更新所述业务应用系统预设的若干新业务角色、若干新用户标识、以及每一个所述新用户标识与若干所述新业务角色的关联关系,形成更新鉴权数据;

使用单元,还用于使用所述更新鉴权数据替换所述备份鉴权数据执行鉴权业务。

可选地,所述系统还包括:

接收单元,还用于接收业务应用系统的应用身份注册请求;

生成单元,还用于根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

接收单元,还用于接收用户对所述业务应用系统的用户身份注册请求;

生成单元,还用于根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收单元,还用于接收为所述用户标识关联在所述业务应用系统的若干业务角色;

保存单元,用于保存所述业务应用身份标识、所述用户标识、所述用户标识在所述业务应用系统中与若干所述业务角色的关联关系。

本申请第四方面提供一种业务应用系统,包括:

接收单元,用于接收用户针对目标业务的业务使用请求;

生成单元,用于根据所述业务使用请求生成业务鉴权请求,所述业务鉴权请求包含所述用户的用户标识、所述目标业务;

发送单元,用于向鉴权系统发送所述业务鉴权请求;

接收单元,还用于接收所述鉴权系统针对所述业务鉴权请求返回的鉴权结果;

确定单元,用于根据所述鉴权结果确定所述用户是否可以使用所述目标业务。

可选地,所述系统还包括:

接收单元,还用于接收所述用户的用户身份注册请求;

生成单元,还用于根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收单元,还用于接收为所述用户标识关联的若干业务角色;

发送单元,还用于向所述鉴权系统发送应用身份注册请求,所述应用身份注册请求包括预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

本申请第五方面提供一种计算机设备,包括:

处理器、存储器,所述存储器中存储有程序;

所述处理器运行所述程序时执行如前述第一方面或第二方面中任一项所述的方法。

本申请第六方面提供一种计算机存储介质,所述计算机存储介质中存储有指令,所述指令在计算机上执行时,使得所述计算机执行如前述第一方面或第二方面中任一项所述的方法。

本申请第七方面提供一种计算机程序产品,所述计算机程序产品在计算机上执行时,使得所述计算机执行如前述第一方面或第二方面中任一项所述的方法。

从以上技术方案可以看出,本申请实施例具有以下优点:

本申请中将鉴权工作从业务应用系统中独立出来形成鉴权系统,利用统一的鉴权系统为各个业务应用系统中用户的各种业务使用进行业务鉴权,进而使得业务应用系统不需要维护自身的鉴权策略,相当于将对用户鉴权的工作统一“外包”给了本申请的鉴权系统,实现应用软件的角色鉴权统一由鉴权系统负责,减少应用软件对鉴权工作所需的角色逻辑策略的携带与维护,进而减轻业务应用系统所在的设备的计算资源的重复消耗,也使得业务应用系统更加轻量化。

附图说明

图1为本申请业务角色鉴权方法的一个实施例流程示意图;

图2为本申请业务角色鉴权方法的另一个实施例流程示意图;

图3为本申请业务角色鉴权方法的另一个实施例流程示意图;

图4为本申请鉴权系统的一个实施例结构示意图;

图5为本申请业务应用系统的一个实施例结构示意图;

图6为本申请计算机设备的一个实施例结构示意图。

具体实施方式

本申请实施例提供了一种业务角色鉴权方法以及相关装置,用于实现应用软件的角色鉴权统一化,减少应用软件对角色逻辑策略的携带与维护,进而减轻业务应用系统所在的设备的计算资源的重复消耗。

本申请所称的鉴权系统,也称为鉴权中心、权限中心等,主要用于给在鉴权系统中完成注册的业务应用提供业务权限的鉴定服务,即对用户要使用该业务应用的目标业务时,判断该用户是否有权限使用该目标业务,进而将有无权限使用该目标业务的鉴权结果告诉该业务应用,使得业务应用根据该鉴权结果确定用户的使用权限。

本申请所称的业务应用系统,简称软件应用、业务应用,主要是指在鉴权系统中完成注册的业务应用系统,该业务应用系统不对用户的使用权限进行鉴定,而是通过鉴权系统的鉴权结果确定用户的使用权限。

请参阅图1,本申请业务角色鉴权方法的一个实施例,应用于鉴权系统,包括:

101、接收业务应用系统的目标业务的业务鉴权请求,业务鉴权请求包括用户的用户标识。

本申请实施例中鉴权系统会接收到来自业务应用系统的目标业务的业务鉴权请求,该业务鉴权请求至少包括用户的用户标识,以便鉴权系统可以通过业务鉴权请求得知:要进行权限鉴定的用户对象、以及要进行权限鉴定的业务对象。即鉴权系统鉴定该用户是否对该目标业务具有使用权限。

102、在数据库中查询用户标识对应的业务角色。

需要说明的是,本实施例的鉴权系统需要存在自己的数据库,该数据库存储了在鉴权系统中完成注册的业务应用系统的相关数据,比如步骤101中该业务应用系统的目标业务、该目标业务的使用权限项(查看、添加、删除、更新等)、该业务应用系统的用户、该业务应用系统的业务角色(超级管理员、应用管理员、系统管理员、管理员等)、该用户关联的业务角色、以及业务角色关联的使用权限项等。本步骤对步骤101中的用户通过用户标识在数据库中查询与其关联的所有业务角色。

103、判断业务角色是否具有目标业务的使用权限,若业务角色具有目标业务的使用权限,则执行步骤104;若业务角色不具有目标业务的使用权限,则执行步骤105。

进一步判断步骤102中该用户关联的业务角色是否具有目标业务的使用权限,值得注意的是,一个用户的用户标识可以关联多个业务角色,比如该用户可以关联超级管理员、应用管理员、系统管理员、管理员中的一个或多个,不同的业务角色拥有对业务应用不同业务的使用权限。本步骤则是遍历该用户关联的所有业务角色,综合判断该用户是否拥有对目标业务的使用权限。

104、向业务应用系统发送允许用户使用目标业务的鉴权成功信息。

若步骤103中确定该用户所关联的业务角色中具有对目标业务的使用权限,比如该用户关联的业务角色是超级管理员,超级管理员拥有目标业务的最高权限,可以对目标业务执行所有操作,那么此时则向业务应用系统发送允许用户使用目标业务的鉴权成功信息,以使的业务应用系统允许用户对目标业务的使用。

105、向业务应用系统发送不允许用户使用目标业务的鉴权失败信息。

若步骤103中确定用户所关联的业务角色中金不具有对目标业务的使用权限,比如该用户关联的业务角色是管理员,管理员仅拥有对目标业务的查看权限,而该用户对目标业务的使用操作是删除,则向业务应用系统发送不允许用户删除该目标业务的鉴权失败信息,以使得业务应用系统拒绝该用户对目标业务的使用。

本申请中将鉴权工作从业务应用系统中独立出来形成鉴权系统,利用统一的鉴权系统为各个业务应用系统中用户的各种业务使用进行业务鉴权,进而使得业务应用系统不需要维护自身的鉴权策略,相当于将对用户鉴权的工作统一“外包”给了本申请的鉴权系统,实现应用软件的角色鉴权统一由鉴权系统负责,减少应用软件对鉴权工作所需的角色逻辑策略的携带与维护,进而减轻业务应用系统所在的设备的计算资源的重复消耗,也使得业务应用系统更加轻量化。

请参阅图2,本申请业务角色鉴权方法的另一个实施例,应用于业务应用系统,包括:

201、接收用户针对目标业务的业务使用请求。

本申请实施例的业务应用是面向用户的交互软件,在于用户进行交互过程中会接收到用户针对业务应用中某一个具体的目标业务的业务使用请求。比如对目标业务的查看、添加、删除、或者更新等业务使用请求。

202、根据业务使用请求生成业务鉴权请求,业务鉴权请求包含用户的用户标识、目标业务。

由于本申请的业务应用不进行对用户的权限鉴定过程,所以业务应用需要根据业务使用请求生成对应的业务鉴权请求,进而可以向鉴权系统确定该用户是否有对目标业务的使用权限,值得注意的是,该业务鉴权请求至少应包含用户的用户标识、以及目标业务。以便鉴权系统可以通过业务鉴权请求得知:要进行权限鉴定的用户对象、以及要进行权限鉴定的业务对象。即鉴权系统鉴定该用户是否对该目标业务具有使用权限。

203、向鉴权系统发送业务鉴权请求。

向鉴权系统发送步骤202中形成的业务鉴权请求,以触发图1实施例中鉴权系统的鉴权过程,即鉴权系统判断用户标识是否对目标业务具有使用权限。

204、接收鉴权系统针对业务鉴权请求返回的鉴权结果。

鉴权系统经过图1实施例的鉴权过程后,业务应用会接收到鉴权系统针对步骤203的业务鉴权请求返回的鉴权结果,该鉴权结果会是:允许用户使用目标业务的鉴权成功信息,或,不允许用户使用目标业务的鉴权失败信息。

205、根据鉴权结果确定用户是否可以使用目标业务。

业务应用系统根据步骤204中接收到的鉴权结果确定该用户是否可以使用该目标业务。即当步骤204中确定的鉴权结果是允许用户使用目标业务的鉴权成功信息,则允许该用户使用该目标业务;当步骤204中确定的鉴权结果是不允许用户使用目标业务的鉴权失败信息,则不允许该用户使用该目标业务。

可见,本申请实施例的业务应用不参与对用户的鉴权过程,业务应用仅需根据鉴权系统的鉴权结果对应确定用户的使用权限,减少应用软件对鉴权工作所需的角色逻辑策略的携带与维护,进而减轻业务应用所在的设备的计算资源的重复消耗,也使得业务应用更加轻量化。

上述实施例分别对本申请的技术方案应用于鉴权系统、业务应用系统进行了实施例说明,下面就本申请的技术方案应用于鉴权系统、业务应用系统一起进行实施例说明,请参阅图3,包括:

301、业务应用系统接收用户的用户身份注册请求。

本申请实施例的业务应用系统是面向用户的交互软件,为了实现对用户的权限鉴定,可以在用户进行用户身份注册的时候对用户进行业务角色的关联。需要说明的是,本实施例中的业务应用系统也可以有着对应的数据库,该数据库存储该业务应用系统的各种业务、每一个业务的使用权限项(查看、添加、删除、更新等)、该业务应用系统的各种业务角色(超级管理员、应用管理员、系统管理员、管理员等)、用户、该用户关联的业务角色、以及业务角色关联的使用权限项等。为此,业务应用系统可以随时接收用户的用户身份注册请求。

302、业务应用系统根据用户身份注册请求为用户生成唯一的用户标识。

对步骤301中提出用户身份注册请求的用户标记唯一的用户标识,以便于业务应用系统和鉴权系统共享该用户的身份信息,可以用该用户标识识别出该用户,以便于后续步骤对该用户的权限鉴定。

303、业务应用系统接收为用户标识关联的若干业务角色。

在步骤302中形成用户的用户标识之后,进一步接收给该用户标识指定关联的若干业务角色,这些业务角色可以是业务应用系统的数据库中存在的一个或多个(超级管理员、应用管理员、系统管理员、管理员等),以便于快速地给用户赋予对业务应用系统的相应权限。

304、业务应用系统向鉴权系统发送业务应用系统的应用身份注册请求。

可以理解的是业务应用系统是需要向鉴权系统进行应用身份注册的,以便让鉴权系统对该业务应用系统进行了解并存储有该业务应用系统的相关信息,以便于鉴权系统后续步骤可以为业务应用系统提供鉴权服务。若业务应用系统在向鉴权系统进行身份注册请求时,业务应用系统中的数据库就保存有预设的若干业务角色、若干用户标识、以及每一个用户标识与若干业务角色的关联关系、每一个业务角色对应的权限项等信息,也应向鉴权系统进行发送,以便鉴权系统接收并保存。

305、鉴权系统根据应用身份注册请求为业务应用系统生成唯一的业务应用身份标识。

需要说明的是,鉴权系统同时为若干个业务应用系统提供鉴权服务,为了区分每一个业务应用系统,鉴权系统会在业务应用系统进行应用身份注册的时候给该业务应用系统生成一个唯一的业务应用身份标识,该业务应用身份标识作为识别该业务应用系统的唯一标识。

306、鉴权系统接收业务应用系统预设的若干业务角色、若干用户标识、以及每一个用户标识与若干业务角色的关联关系。

鉴权系统在步骤305中给业务应用系统生成唯一的业务应用身份标识之后,可以接收业务应用系统发送的预设的若干业务角色、若干用户标识、以及每一个用户标识与若干业务角色的关联关系、每一个业务角色对应的权限项等信息,并将这些信息与该业务应用系统的业务应用身份标识进行关联存储。

307、业务应用系统接收用户对目标业务的业务使用请求。

本步骤的执行与前述图2实施例中步骤201的操作类似,重复部分在此不再进行赘述。

308、业务应用系统根据业务使用请求生成业务鉴权请求。

本步骤的执行与前述图2实施例中步骤202的操作类似,重复部分在此不再进行赘述。

309、业务应用系统向鉴权系统发送业务鉴权请求。

本步骤的执行与前述图2实施例中步骤203的操作类似,重复部分在此不再进行赘述。

310、鉴权系统在数据库中查询用户标识对应的业务角色。

本步骤的执行与前述图1实施例中步骤102的操作类似,重复部分在此不再进行赘述。

311、鉴权系统判断业务角色是否具有目标业务的使用权限。

本步骤的执行与前述图1实施例中步骤103的操作类似,重复部分在此不再进行赘述。

312、鉴权系统向业务应用系统返回鉴权结果。

本步骤的执行与前述图1实施例中步骤104、或步骤105的操作类似,重复部分在此不再进行赘述。

313、业务应用系统根据鉴权结果确定用户是否可以使用目标业务。

本步骤的执行与前述图2实施例中步骤205的操作类似,重复部分在此不再进行赘述。

进一步的,本申请实施例还提供了一种鉴权系统针对某一个业务应用系统的鉴权策略发生改变时,需要更新鉴权系统中的鉴权逻辑时的方法,请参阅图3的步骤314至步骤317,包括:

314、鉴权系统备份业务应用系统的鉴权数据。

将鉴权系统中需要进行鉴权策略更新的业务应用系统的鉴权数据进行备份,即通过该业务应用系统的应用身份标识把在鉴权系统中相关的鉴权数据全部复制一份,形成备份鉴权数据。

315、鉴权系统使用备份鉴权数据执行鉴权业务。

鉴权系统使用步骤314中的备份鉴权数据继续为该业务应用系统进行鉴权服务。即鉴权系统暂停了使用原来的鉴权数据为业务应用系统进行鉴权服务,使得鉴权系统解除对这一份原来的鉴权数据的占用。

316、鉴权系统更新业务应用的鉴权数据。

鉴权系统用获取到的该业务应用系统对应的新鉴权数据,并用这部分新鉴权数据更新步骤315中那一份原来的鉴权数据,以完成更新鉴权系统中该业务应用系统的鉴权逻辑,得到该业务应用系统新的鉴权策略。

317、鉴权系统使用更新鉴权数据替换备份鉴权数据执行鉴权业务。

在步骤316中完成对该业务应用的鉴权策略更新之后,鉴权系统既可以暂停使用该业务应用的备份鉴权数据为该业务应用进行鉴权服务,转而使用更新后的更新鉴权数据为该业务应用系统执行鉴权业务。

可见,本申请实施例的鉴权系统在给每个业务应用系统的鉴权数据进行更新的过程中不需要将像传统的业务应用系统那样暂停对用户使用业务应用的服务,而是实现了不停机更新,用户使用体验更好。

本申请实施例的步骤301至步骤303描述了用户通过业务应用系统注册的一个实施例,而在另一个实施例中,请参阅图3实施例的步骤308至步骤320,用户针对业务应用系统的注册方式还可以是:

318、鉴权系统接收用户对业务应用系统的用户身份注册请求。

以业务应用系统在鉴权系统中完成注册,并生成业务应用身份标识为基础,用户可以直接向鉴权系统提交针对某一个完成注册业务应用的用户身份注册请求,鉴权系统则会接收到该用户对业务应用的用户身份注册请求,并为该用户在该业务应用中形成唯一的用户标识。

319、鉴权系统接收为用户标识关联在业务应用系统的若干业务角色。

在步骤318中形成用户的用户标识之后,鉴权系统可以进一步接收给该用户标识指定关联该业务应用系统的若干业务角色,这些业务角色可以是业务应用系统的数据库中存在的一个或多个(超级管理员、应用管理员、系统管理员、管理员等),以便于快速地给用户赋予对业务应用系统的相应权限。这些业务角色也可以是鉴权系统的数据库存在的一个或多个(超级管理员、应用管理员、系统管理员、管理员等),以便于快速地给用户赋予对业务应用的相应权限。

320、鉴权系统保存业务应用身份标识,用户标识、用户标识在业务应用系统中与若干业务角色的关联关系。

鉴权系统直接对步骤319中该用户在业务应用关联的若干业务角色、每一个业务角色对应的权限项等信息,并将这些信息与该业务应用的业务应用身份标识进行关联存储。

可见,本实施例由鉴权系统用于对业务应用的用户的注册,那么业务应用即可以不用部署用户注册相关的逻辑策略,使得业务应用更加轻量化。

上面对本申请业务角色鉴权方法的实施例进行了描述,下面对本申请业务角色鉴权装置的实施例进行说明,请参阅图4,本申请鉴权系统的一个实施例,包括:

接收单元401,用于接收业务应用系统的目标业务的业务鉴权请求,所述业务鉴权请求包括用户的用户标识;

查询单元402,用于在数据库中查询所述用户标识对应的业务角色;

判断单元403,用于判断所述业务角色是否具有所述目标业务的使用权限;

发送单元404,用于若所述业务角色具有所述目标业务的使用权限,则向所述业务应用系统发送允许所述用户使用所述目标业务的鉴权成功信息;

发送单元404,还用于若所述业务角色不具有所述目标业务的使用权限,则向所述业务应用系统发送不允许所述用户使用所述目标业务的鉴权失败信息。

可选地,所述系统还包括:

接收单元401,还用于接收业务应用系统的应用身份注册请求;

生成单元405,用于根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

接收单元401,还用于通过所述业务应用身份标识接收所述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

可选地,所述系统还包括:

备份单元406,用于备份所述述业务应用系统预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系,形成备份鉴权数据;

使用单元,用于使用所述备份鉴权数据执行鉴权业务;

更新单元407,用于更新所述业务应用系统预设的若干新业务角色、若干新用户标识、以及每一个所述新用户标识与若干所述新业务角色的关联关系,形成更新鉴权数据;

使用单元407,还用于使用所述更新鉴权数据替换所述备份鉴权数据执行鉴权业务。

可选地,所述系统还包括:

接收单元401,还用于接收业务应用系统的应用身份注册请求;

生成单元405,还用于根据所述应用身份注册请求为所述业务应用系统生成唯一的业务应用身份标识;

接收单元401,还用于接收用户对所述业务应用系统的用户身份注册请求;

生成单元405,还用于根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收单元401,还用于接收为所述用户标识关联在所述业务应用系统的若干业务角色;

保存单元409,用于保存所述业务应用身份标识、所述用户标识、所述用户标识在所述业务应用系统中与若干所述业务角色的关联关系。

本实施例所执行的操作与前述图1或图3中鉴权系统所执行的操作类似,在此不再进行赘述。

本申请中将鉴权工作从业务应用系统中独立出来形成鉴权系统,利用统一的鉴权系统为各个业务应用系统中用户的各种业务使用进行业务鉴权,进而使得业务应用系统不需要维护自身的鉴权策略,相当于将对用户鉴权的工作统一“外包”给了本申请的鉴权系统,实现应用软件的角色鉴权统一由鉴权系统负责,减少应用软件对鉴权工作所需的角色逻辑策略的携带与维护,进而减轻业务应用系统所在的设备的计算资源的重复消耗,也使得业务应用系统更加轻量化。

请参阅图5,本申请业务应用系统的一个实施例,包括:

接收单元501,用于接收用户针对目标业务的业务使用请求;

生成单元502,用于根据所述业务使用请求生成业务鉴权请求,所述业务鉴权请求包含所述用户的用户标识、所述目标业务;

发送单元503,用于向鉴权系统发送所述业务鉴权请求;

接收单元501,还用于接收所述鉴权系统针对所述业务鉴权请求返回的鉴权结果;

确定单元504,用于根据所述鉴权结果确定所述用户是否可以使用所述目标业务。

可选地,所述系统还包括:

接收单元501,还用于接收所述用户的用户身份注册请求;

生成单元502,还用于根据所述用户身份注册请求为所述用户生成唯一的用户标识;

接收单元501,还用于接收为所述用户标识关联的若干业务角色;

发送单元503,还用于向所述鉴权系统发送应用身份注册请求,所述应用身份注册请求包括预设的若干业务角色、若干用户标识、以及每一个所述用户标识与若干所述业务角色的关联关系。

本实施例所执行的操作与前述图2或图3中业务应用系统所执行的操作类似,在此不再进行赘述。

本申请中将鉴权工作从业务应用系统中独立出来形成鉴权系统,利用统一的鉴权系统为各个业务应用系统中用户的各种业务使用进行业务鉴权,进而使得业务应用系统不需要维护自身的鉴权策略,相当于将对用户鉴权的工作统一“外包”给了本申请的鉴权系统,实现应用软件的角色鉴权统一由鉴权系统负责,减少应用软件对鉴权工作所需的角色逻辑策略的携带与维护,进而减轻业务应用系统所在的设备的计算资源的重复消耗,也使得业务应用系统更加轻量化。

下面对本申请计算机设备的一个实施例进行描述,请参考图6,包括:

该计算机设备600可以包括一个或一个以上中央处理器(central processingunits,CPU)601和存储器602,该存储器602中存储有一个或一个以上的应用程序或数据。其中,存储器602可以是易失性存储或持久存储。存储在存储器602的程序可以包括一个或一个以上模块,每个模块可以包括对计算机设备的一系列指令操作。更进一步地,中央处理器601可以设置为与存储器602通信,在计算机设备600上执行存储器602中的一系列指令操作。该中央处理器601可以执行前述图1、图2或图3所示实施例中鉴权系统或业务应用系统的操作,具体此处不再赘述。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,read-onlymemory)、随机存取存储器(RAM,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号