CN112311783A - 一种认证反向代理方法及系统 - Google Patents

一种认证反向代理方法及系统 Download PDF

Info

Publication number
CN112311783A
CN112311783A CN202011150695.3A CN202011150695A CN112311783A CN 112311783 A CN112311783 A CN 112311783A CN 202011150695 A CN202011150695 A CN 202011150695A CN 112311783 A CN112311783 A CN 112311783A
Authority
CN
China
Prior art keywords
authentication
target
code
authorization server
reverse proxy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202011150695.3A
Other languages
English (en)
Other versions
CN112311783B (zh
Inventor
程仁波
黄利明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Scale Finance Beijing Intelligent Technology Co ltd
Original Assignee
Scale Finance Beijing Intelligent Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Scale Finance Beijing Intelligent Technology Co ltd filed Critical Scale Finance Beijing Intelligent Technology Co ltd
Priority to CN202011150695.3A priority Critical patent/CN112311783B/zh
Publication of CN112311783A publication Critical patent/CN112311783A/zh
Application granted granted Critical
Publication of CN112311783B publication Critical patent/CN112311783B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]

Abstract

本申请公开了一种认证反向代理方法及系统，用于消除了不同平台的实现标准的差异化。本申请公开的认证反向代理方法包括：认证反向代理系统接收代理认证请求，将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器；所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端；所述认证反向代理系统接收将所述代理代码转换为访问令牌Acces Token的转换请求，根据所述转换请求确定网关代码，并把网关代码转换为目标授权服务器代码，向所述目标授权服务器请求访问令牌Access Token；所述授权服务器接收到所述授权服务器代码后，验证所述授权服务器代码的合法性，若验证通过，则将访问令牌Access Token反馈给客户端。本申请还提供了一种认证反向代理系统。

Description

一种认证反向代理方法及系统
技术领域
本申请涉及认证领域，尤其涉及一种认证反向代理方法及系统。
背景技术
OAuth(开放授权)是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。OAuth 2.0是OAuth协议的下一版本，OAuth2.0授权框架支持第三方应用获取对HTTP服务的访问权限，或者通过编排审批交互，让第三方应用在资源所有者和HTTP服务之间，代表自己的权限。它常被用于Web第三方认证。但是现有的认证体系标准的实现不统一，不同平台兼容性差，不仅增加开发人员的使用难度和代码量，也间接影响应用系统的稳定性和可维护性。
发明内容
针对上述技术问题，本申请实施例提供了一种认证反向代理方法及系统，用以提供统一的标准接口，消除了不同平台的实现标准的差异化。
一方面，本申请实施例提供的一种认证反向代理方法，包括：
认证反向代理系统接收代理认证请求，将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器；
所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端；
所述认证反向代理系统接收将所述代理代码转换为访问令牌Acces Token的转换请求，根据所述转换请求确定网关代码，并把网关代码转换为目标授权服务器代码，向所述目标授权服务器请求访问令牌Access Token；
所述授权服务器接收到所述授权服务器代码后，验证所述授权服务器代码的合法性，若验证通过，则将访问令牌Access Token反馈给客户端。
优选的，所述认证反向代理系统的统一网关组件接收代理认证请求；
优选的，所述授权服务器的接口安全拦截器对所述代理人认证请求进行判别，若所述认证请求为非法授权的客户端发起的，则拒绝所述代理认证请求。满足以下条件之一则判定为非法授权的客户端：
IP地址超过预设的网段范围；
域名不在预设的域名范围内；
接口范围不在预定的范围内。
作为一种优选示例，所述将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器，包括：
所述统一网关将所述代理认证请求发送到认证调度处器，所述认证调度处理器将所述代理认证请求转换为目标认证请求，并将所述目标认证请求返回给所述统一网关；
所述统一网关将所述目标认证请求通过用户代理User Agent重定向给授权服务器。
所述认证调度处理器将所述代理认证请求转换为目标认证请求，包括：
根据域domain或者路径path规则，获取租户的上下文信息，并从所述上下文信息中提取目标授权服务器的客户号client_id，并标记为新客户号new_client_id；
利用状态state生成器生成新状态new_state；
将所述新状态new_state作为密钥key，将所述认证请求中的参数客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state存储到缓存池中；
将所述认证反向代理系统的重定向地址标记为新重定向地址new_redirect_uri；
将所述新重定向地址new_redirect_uri，新客户号new_client_id，新状态new_state，反馈类型response_type作为参数，通过SPI接口传递给对应的认证适配器。
所述的SPI接口用于由认证反向代理系统代替用户代理User-Agent向目标授权服务器发送认证请求。
作为一种优选示例，所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端，包括：
所述授权服务器验证通过目标认证请求后，将所述目标代码发送到所述认证反向代理系统；
所述认证反向代理系统根据状态State参数，获取新状态new_state；
所述认证反向代理系统通过所述新状态new_state，从所述缓存池中提取原始认证参数，并提取客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state，并将所述目标代码Code作为附加参数，通过用户代理User-Agent重定向给原始客户端或者原始重定向地址。
优选的，所述向所述目标授权服务器请求访问令牌Access Token，包括：
通过SPI的访问令牌接口，由所述认证反向代理系统代替用户代理User-Agent向目标授权服务器请求访问令牌Access Token。通过SPI的用户信息查询接口，由所述认证反向代理系统代替用户代理User-Agent向目标授权服务器或者资源服务器请求第三方提供的授权用户信息。
通过本发明的方法，可通过对不同平台的差异化的接口，进行了二次封装，提供统一的标准接口。消除了不同平台的实现标准的差异化。统一了OAuth2.0标准框架和规范一致的接口。降低了应用开发者的使用门槛，减少开发过程的代码量和判定逻辑，大大提高开发团队的开发效率和开发质量。同时，利用SPI适配器机制，实现了具体实现之间的松耦合，保证开发者在扩展新授权服务器的对接以及升级原授权服务器极大的便利性和稳定性。
另一方面，本申请实施例提供的一种认证反向代理系统，包括：处理器、存储器、网络接口；所述网络接口，用于在处理器的控制下进行数据的接收和发送；所述存储器，用于存储计算机程序；所述处理器用于读取所述存储器中的所述计算机程序，所述处理器执行所述计算机程序时，实现上述认证反向代理方法和步骤。
通过本发明提供的认证反向代理方法和系统，避免了各平台对服务接口的各种资源限制，对外提供统一的、集中的接口入口，因此只需要使用一个域名资源即可供多个应用共用相同的OAuth2.0认证服务。同时，本实施例提供的认证反向代理系统可以在不破坏目标系统安全性的基础上，允许用户在开发环境或者测试环境下，获得认证身份，进行开发调试。
通过本发明提供的认证反向代理方法，可以让OAuth2.0认证统一代理系统同时服务多个不同的客户，可以减少开发团队的交付周期和交付成本。可以实现客户端与目标授权服务器之间的逻辑与安全信息的隔离，从而让实现在安全性上更加可靠。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为OAuth2.0不同角色之间的交互流程示意图；
图2为OAuth2.0标准认证流程示意图；
图3为本申请实施例提供的认证反向代理方法示意图；
图4为本申请实施例提供的认证反向代理不同角色交互流程示意图；
图5为本申请实施例提供的认证反向代理系统示意图一。
图6为本申请实施例提供的认证反向代理系统示意图二。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
下面对文中出现的一些词语进行解释：
1、本发明实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
2、本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。
OAuth(开放授权)是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。OAuth 1.0在2007年的12月底发布并迅速成为工业标准。OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机应用，以及智能网络硬件设备提供专门的认证流程。OAuth2.0授权框架支持第三方应用获取对HTTP服务的访问权限，或者通过编排审批交互，让第三方应用在资源所有者和HTTP服务之间，代表自己的权限。它常被用于Web第三方认证(例如某些网站支持QQ、facebook、微信等第三方认证)。OAuth 2.0为用户和应用定义了如下角色：
1)资源拥有者(Resource Owner)
能够授予对受保护资源的访问权的实体，当资源所有者是一个人时，它被称为最终用户。
2)资源服务器(Resource Server)
托管受保护资源的服务器，能够接受以及使用访问令牌响应受保护的资源请求。
3)客户端应用(Client Application第三方应用)
代表发出受保护资源请求的应用程序资源所有者及其授权。
4)授权服务器(Authorization Server)
向客户端颁发访问令牌的服务器，验证资源所有者并获得授权。
上述四个角色之间的交互如图1所示，交互步骤包括：
S101：客户端从资源所有者处请求授权；
S102：客户端收到资源所有者的授权；
S103：客户端获得授权后，拿着授权向授权服务器申请令牌；
S104：授权服务器验证客户端身份并验证授权许可，若有效则颁发访问令牌；
S105：客户端拿令牌向资源服务器请求获取资源；
S106：资源服务器验证访问令牌，若有效则开放资源访问。
为了更清楚的描述认证流程，结合图2进一步描述，如图2所示，
步骤A，客户端(client)通过用户代理(User-Agent)向授权服务器(Authorization Server)询问认证身份；本步骤可分为两个子步骤：
S201-1：客户端向用户代理询问认证身份；
S201-2：用户代理根据客户端的请求，向授权服务器询问客户端的认证身份。
步骤B，资源拥有者(Resuoure Owner)通过用户终端(User-Agent)向授权服务器进行认证；本步骤可分为两个子步骤：
S202-1：用户代理向资源拥有者请求认证；
S202-2：用户代理向授权服务器请求认证。
步骤C，认证成功后授权服务器通过用户代理把Code重定向回客户端；本步骤可分为两个子步骤：
S203-1：认证成功后授权服务器把Code返回给用户代理；
S203-2：用户代理将Code重定向回客户端。
步骤D，客户端通过Code，向授权服务器请求访问令牌access token；
本步骤，即为图2中的S204，客户端获得Code后，带着获得的Code，向授权服务器请求访问令牌。
步骤E，服务器验证Code后，把正确的访问令牌返回给客户端。
本步骤即为图2中的S205，授权服务器对Code进行验证，验证通过后，把正确的访问令牌返回给客户端。
经过上述步骤后，就完成了客户端的认证过程。客户端拿到访问令牌后，就可以向资源拥有者请求访问资源。
但是现有的认证流程存在以下缺点：
(一)标准的实现不统一，不同平台兼容性差；
尽管早在2012年就成为了正式标准，但各平台的实现并不统一，存在较大差异，甚至某些平台使用了类OAuth2.0的自定义标准。不仅会增加开发人员的使用难度和代码量，也间接影响应用系统的稳定性和可维护性。
(二)易出现代码副本扩散，难以维护；
OAuth2.0协议作为一个重要的工业标准已经大规模的应用。在不同的项目和子系统中，易出现代码副本的扩散。代码副本的扩散会给技术开发团队带来维护工作上的严重负担。随着DevOps发展逐步深入，如何有效避免代码副本的扩散，已经成为技术企业面临的一个重要课题。
(三)部分平台限制多，影响开发效率和实现方案；
一些特殊的限制例如，平台对域名或应用的数量有严格的限制，造成开发人员在开发环境以及测试或者多应用环境下无法正常开发调试，极大限制了开发人员的工作效率。
(四)对跨应用、跨团队的微服务环境不友好。
在实际生产和应用环境中，单服务主体(独立的客户)的场景已经很难满足互联网企业多产品矩阵化的发展需要。同时，随着多租户、服务平台化的快速发展趋势，越来越多的新技术企业逐步倾向采用多租户服务平台解决方案。
针对上述技术问题，本发明实施例提供了一种认证反向代理方法及系统，基于插件式设计，集成不同实现标准的第三方平台授权服务器，对外提供统一的、标准化对外服务接口；通过平台化服务，对OAuth2.0协议的实现进行集中的实现，避免衍生代码副本，减少开发人员的维护半径和维护难度；提供引入平台化、多租户技术架构，实现多租户平台服务，并且合理解决多租户的数据隔离与服务共享；通过统一的反向代理服务，降低对第三方开放平台的资源(域名、请求数限制等)需求，同时，合理利用OAuth2.0协议标准和资源限制机制，巧妙规避本地开发、测试环境必须使用内网穿透技术工具的问题。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。
如图5所示，本申请实施例提供的一种认证反向代理系统组成示意图，该认证反向代理系统包括以下组件：
组件一：OAuth2.0统一网关。
OAuth2.0统一网关是本认证反向代理系统的服务门户，为外部提供统一的HTTPAPI服务。网关除了作为服务门户主要功能之外，核心任务是提供统一的、标准的OAuth2.0API接口。
作为一种优选的示例，OAuth2.0统一网关包含以下三个接口：
authorize接口，用于向授权服务器发起授权请求；
access_token接口，用于从授权服务器获取授权token；
user_info接口，用于通过授权token向资源服务器请求用户认证数据。
需要说明的是，user_info并不是OAuth标准接口，但在第三方认证请求时，是必要的接口。
组件二：接口安全拦截器。
接口安全拦截器，用于提供必要的安全防护，安全防护的规则可根据需要进行设置，本实施例不做限定。对于不满足安全防护要求的访问，不提认证反向代理服务；对于满足安全防护要求的访问，可接受本申请提供的认证反向代理服务。
作为一种优选示例，安全防护规则包括但不限于：
IP白名单，即IP地址不在IP白名单内的访问，不满足安全防护要求；IP地址在IP白名单内的访问，满足安全防护要求；
域名白名单，即域名地址不在域名白名单内的访问，不满足安全防护要求；域名地址在域名白名单内的访问，满足安全防护要求；
access_token接口限制，即接口范围不在设定的范围内的访问，不满足安全防护要求；接口范围在设定的范围内的访问，满足安全防护要求；
IP段限制，即限制访问的IP段范围，IP地址不在IP段内的访问，不满足安全防护要求；IP地址在IP段内的访问，满足安全防护要求。
组件三，基于URL规则的路由过滤器与租户上下文构造器。
本申请实施例中，统一网关对外提供服务是，需要扩展你参数，指定具体的认证类型(例如，认证类型包括：微信wechat、微博weibo、支付宝alipayxxxxxx)，但是如果在统一网关中增加类型参数，则破坏了对外接口的统一性。因此，需要在URL请求路径(例如http://domain/path/authorize)上进行扩展。作为一种优选示例，可扩展的选项包括：基于域domain扩展，基于路径path扩展。
通过上述域domain或者路径path扩展信息，对请求的url进行识别，识别后，调用租户上下文构造器，把租户应用程序账号app_id，租户应用密钥app_secret，请求的认证第三方类型等信息组装到请求的上下文中。
组件四，OAuth2.0认证调度处理器与OAuth2.0 SPI接口。
调度处理器，负责OAuth2.0执行过程的调度、处理请求与返回结果。采用背靠背(back-to-back)方式，实现第三方授权服务器访问的反向代理服务组件。认证调度处理器通过不与具体的认证第三方授权服务器直接通讯，而是通过OAuth2.0 SPI接口与具体的认证适配器来间接访问第三方授权服务器。
需要说明的是，本实施例所述的背靠背(back-to-back)方式，是指即对于用户代理来看，本实施例即为授权服务器；对于第三方授权服务器来看，本实施例即为用户代理。用户代理和第三方授权服务器不需要明确感知本实施例，也不需要针对本实施实例做额外的工作。，。
组件五，OAuth2.0认证适配器。
OAuth2.0认证适配器通过继承SPI接口，以开放的、可插拔组件化的方式，反向代理第三方授权服务器的请求，从而实现可扩展任意第三方OAuth2.0授权服务器，并提供统一OAuth2.0标准接口的目的。
需要说明的是，此处所述的开放的方式，是指通过开发实现SPI接口的程序，允许开发者扩展更多的支持OAuth2.0标准认证协议的其他第三方授权服务器。
需要说明的是，此处所述的可插拔组件化的方式，是指组件化是指针对每一个支持OAuth2.0标准协议的第三方授权服务器都需要开发成一个独立的适配器组件，组件方式可以有效隔离不同的授权服务器实现，避免组件间的依赖和干扰。同时可插拔，允许动态的移除和添加组件，实现第三方授权服务器的动态维护，并且不需要重新开发、编译或者部署本实施例
作为一种优选示例，适配器实现的接口包括：
spi_authorize接口，用于向授权服务器发起授权请求。
spi_access_token接口，用于从授权服务器获取授权token。
spi_userinfo接口，用于通过授权token向资源服务器请求用户认证数据。
需要说明的是，user_info并不是OAuth标准接口，但在第三方认证请求时，是必要的接口。
组件六，缓冲池。
本实施例提供的缓冲池，可包括以下至少一个：State缓存、令牌缓存或者认证信息缓存。
缓冲池用于帮助认证调度处理器完成内外部token映射或者交换。从统一网关传过来的内部token，需要交换为外部token，才能以资源管理者的身份从资源管理器获取需要的信息(例如：user info)，通过token映射，实现内外部token的隔离，并且可以增强系统的安全性和私密性，防止第三方的token外泄。
作为另一种优选示例，为了减少频繁调用OAuth2.0认证，造成第三方平台的资源使用限制，避免资源浪费、提高性能，增加对正确返回的user info进行缓存，当缓存的结果存在时，直接从缓存返回，而不再请求第三方资源服务器。
组件七，输出标准化构造器。
由于第三方资源服务器提供的用户信息，不属于OAuth2.0标准接口，因此各第三方平台的数据结构和格式都不相同，对于使用OAuth2.0统一认证网关的开发者不够友好。为了减少开发者的开发效率，需要提供一个扩展的、统一的输出结构和数据格式。同时为了不干扰第三方结果的完整返回，因此在把第三方资源服务器返回的结果原样返回之外，还需要提供一个统一标准的输出结构。开发者在自己实现OAuth2.0认证适配器时，需要针对这个结构进行输出。
需要说明的是，图5中所示的认证反向代理服务器组件，只是示意性的，还可以有其他划分方法，只要能实现相同的功能即可，本实施例不做限定。其中的组件，也可以进一步的拆分，例如，组件三基于URL规则的路由过滤器与租户上下文构造器，可以分为两个组件：路由过滤器和租户上下文构造器。再例如，组件六缓冲池，可以分为三个缓冲池：状态缓冲池，令牌缓冲池和认证信息缓冲池。再例如，组件四OAuth2.0认证调度处理器与OAuth2.0SPI接口，可以划分为两个组件：OAuth2.0认证调度处理器和OAuth2.0 SPI接口。再例如，组件五OAuth2.0认证适配器，可根据不同的认证目标，分为不同的适配器。
下面结合具体的示例进一步说明。
实施例一
参见图3，本申请实施例提供的一种认证反向代理方法示意图，如图所示，该方法包括：
S301，认证反向代理系统接收代理认证请求，将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器；
作为一种优选示例，代理认证请求是通过统一网关组件接收的，即通过图5中的网关组件接收。统一网关是本认证反向代理系统的服务门户，为外部提供统一的HTTP API服务。
作为一种优选示例，当认证反向代理系统接收到认证请求后，需要对认证请求进行判别，若所述认证请求为非法授权的客户端发起的，则拒绝所述代理认证请求。其中，本步骤所述的判别，可以由图5中的接口安全拦截器进行。判别的规则可以根据需要进行预设，可以包括以下之一或者组合：
IP地址判别，即IP地址不在IP白名单内的访问，不满足安全防护要求；IP地址在IP白名单内的访问，满足安全防护要求；
域名判别，即域名地址不在域名白名单内的访问，不满足安全防护要求；域名地址在域名白名单内的访问，满足安全防护要求；
access_token接口判别，即接口范围不在设定的范围内的访问，不满足安全防护要求；接口范围在设定的范围内的访问，满足安全防护要求；
IP网段判别，即限制访问的IP段范围，IP地址不在IP段内的访问，不满足安全防护要求；IP地址在IP段内的访问，满足安全防护要求。
还可以进行其他类型判别，具体本实施例不做限制。
作为一种优选示例，对认证请求判别为合法的情况下，统一网关将所述代理认证请求发送到认证调度处器，认证调度处理器将代理认证请求转换为目标认证请求，并将目标认证请求返回给统一网关；然后统一网关将目标认证请求通过用户代理User Agent重定向给授权服务器。
上述所述的认证请求，可以通过统一网关的authorize接口进行，请求后，反向认证代理系统内部的处理过程如下：
根据域domain或者路径path规则，获取租户的上下文信息，并从所述上下文信息中提取目标授权服务器的客户号client_id，并标记为新客户号new_client_id；
利用状态state生成器生成新状态new_state；
将所述新状态new_state作为密钥key，将所述认证请求中的参数客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state存储到缓存池中；
将所述认证代理系统的重定向地址标记为新重定向地址new_redirect_uri；
将所述新重定向地址new_redirect_uri，新客户号new_client_id，新状态new_state，反馈类型response_type作为参数，通过SPI接口传递给对应的认证适配器。
在本实施例的上述步骤中，SPI接口用于由认证代理系统代替用户代理User-Agent向目标授权服务器发送认证请求，由此完成了认证请求的反向代理过程。
下面给出SPI接口的接口方法示例：
1)spi_authorize方法
该方法用于由认证反向代理系统代替用户代理User-Agent向实际的目标授权服务器发送认证请求。可包括以下参数：
client_id：目标授权服务器授予终端用户的client_id；
response_type：原始认证请求的response_type；
redirect_uri：本代理系统分配的redirect_uri；
state：本代理系统分配的new_state。
2)spi_access_token方法
该方法用于由认证反向代理系统代替用户代理User-Agent向实际的目标授权服务器请求access token。可包括以下参数：
client_id：目标授权服务器授予终端用户的client_id；
secret：目标授权服务器授予终端用户的secret；
code：authorize请求返回的code。
3)spi_userinfo方法
该方法在本发明实施例中是可选的，即可以没有该方法。
该方法用于由认证反向代理系统代替用户代理User-Agent向实际的目标授权服务器或者资源服务器请求第三方提供的授权用户信息。
需要说明的是，上述SPI接口三个实现方法，仅仅是一种实现举例，本发明的实施例不限于上述实现，还可以有其他SPI接口实现方法。
S302，所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端；
授权服务器收到认证请求后，需要将目标认证请求到代理认证请求的逆向映射转换。可通过以下步骤进行：
所述授权服务器验证通过目标认证请求后，将所述目标代码发送到所述认证代理系统；
所述认证代理系统根据状态State参数，获取新状态new_state；
所述认证代理系统通过所述新状态new_state，从所述缓存池中提取原始认证参数，并提取客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state，并将所述目标代码Code作为附加参数，通过用户代理User-Agent重定向给原始客户端或者原始重定向地址。
S303，所述认证反向代理系统接收将所述代理代码转换为访问令牌Acces Token的转换请求，根据所述转换请求确定网关代码，并把网关代码转换为目标授权服务器代码，向所述目标授权服务器请求访问令牌Access Token；
在本步骤中，通过SPI的访问令牌接口，由所述认证代理系统代替用户代理User-Agent向目标授权服务器请求访问令牌Access Token。作为一种优选示例，可通过上述SPI接口的spi_access_token方法向所述目标授权服务器请求访问令牌Access Token。
S304，所述授权服务器接收到所述授权服务器代码后，验证所述授权服务器代码的合法性，若验证通过，则将访问令牌Access Token反馈给客户端。
本实施例提供的认证反向代理方法，通过对不同平台的差异化的接口，进行了二次封装，提供统一的标准接口。消除了不同平台的实现标准的差异化。统一了OAuth2.0标准框架和规范一致的接口。降低了应用开发者的使用门槛，减少开发过程的代码量和判定逻辑，大大提高开发团队的开发效率和开发质量。同时，利用SPI适配器机制，实现了具体实现之间的松耦合，保证开发者在扩展新授权服务器的对接以及升级原授权服务器极大的便利性和稳定性。
下面结合图4，对认证过程进一步说明。
如图4所示，包括以下角色：
1)资源拥有者(Resource Owner)
能够授予对受保护资源的访问权的实体。
2)用户代理(User-Agent)
接受客户端认证请求的代理。
3)客户端(Client)
请求授权和有资源访问需求的客户端。
4)授权服务器(Authorization Server)
向客户端颁发访问令牌的服务器，验证资源所有者并获得授权。
5)认证反向代理系统
认证交互过程包括以下步骤：
步骤(A*):OAuth2.0认证反向代理系统获取代理认证请求后，将其转变为目标认证请求。把目标认证请求发送给授权服务器；
该步骤(A*)可分为以下几个步骤：
S401-1，客户端向用户代理发送询问身份请求；
S401-2，用户代理向认证反向代理系统发送询问身份认证请求；
S401-3,认证反向代理系统接收到询问身份请求后，将其转变为目标认证请求把目标认证请求发送给授权服务器；需要说明的是，询问身份请求的接收，是通过上述实施例中的统一网关组件进行的，认证请求到目标认证请求的转换过程，见步骤S301，此处不再赘述。
需要说明的是，把目标认证请求发送给授权服务器，不是认证网关直接转发目标认证请求给授权服务器，而是通过User-Agent重定向给授权服务器。
步骤(C*)：授权服务器把目标Code返回给OAuth2.0认证反向代理系统，认证反向代理系统将目标Code转变为代理Code，由认证反向代理系统把代理Code通过用户代理User-Agent返回给客户端Client。
该步骤(C*)可分为以下几个步骤：
S403-0：授权服务器把目标Code返回给认证反向代理系统；
S403-1：认证反向代理系统将目标Code转变为代理Code，并将Code反馈给用户代理。该步骤中目标Code转变为代理Code的过程详见步骤S302，此处不再赘述。
S403-2：用户代理User-Agent将代理Code返回给客户端Client。
步骤(D*)：OAuth2.0认证反向代理系统收到Code换访问令牌Access token的请求，认证反向代理系统把Code转换回目标授权服务器Code，向目标授权服务器请求访问令牌Access token。
该步骤(D*)可分为以下几个步骤：
S404-1：客户端向认证反向代理系统发送Code换访问令牌Access token的请求；
S404-2：认证反向代理系统把Code转换回目标授权服务器Code，向目标授权服务器请求访问令牌Access token。
步骤(E*)：授权服务器验证Code后通过OAuth2.0认证反向代理系统把访问令牌Access token返回给客户端Client。
该步骤(E*)可分为以下几个步骤：
S405-1:授权服务器验证Code后，将访问令牌Access token返回给认证反向代理系统；
S405-2:认证反向代理系统将访问令牌Access token返回给客户端Clint。
通过本实施例提供的认证反向代理方法，避免了各平台对服务接口的各种资源限制，对外提供统一的、集中的接口入口，因此只需要使用一个域名资源即可供多个应用共用相同的OAuth2.0认证服务。同时，本实施例提供的认证反向代理系统可以在不破坏目标系统安全性的基础上，允许用户在开发环境或者测试环境下，获得认证身份，进行开发调试。
本实施例提供的认证反向代理方法，可以让OAuth2认证统一代理系统同时服务多个不同的客户，可以减少开发团队的交付周期和交付成本。可以实现客户端与目标授权服务器之间的逻辑与安全信息的隔离，从而让实现在安全性上更加可靠。
实施例二
基于同一个发明构思，本发明实施例还提供了一种认证反向代理系统，如图6所示，该系统包括：
处理器601和存储器602，所述存储器602用于存储计算机程序，所述处理器601用于读取并执行所述存储器602中的所述计算机程序。
所述认证反向代理系统还可以包括总线接口604和网络接口603，处理器601负责管理总线架构和通常的处理，存储器602可以存储处理器601在执行操作时所使用的数据。网络接口603用于在处理器601的控制下接收和发送数据。
总线架构可以包括任意数量的互联的总线和桥，具体由处理器601代表的一个或多个处理器和存储器602代表的存储器的各种电路链接在一起。这些都是本领域所公知的，因此，本文不再对其进行进一步描述。
本申请实施例揭示的流程，可以应用于处理器601中，或者由处理器601实现。处理器601可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例一中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器601中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器602，处理器601读取存储器602中的信息，结合其硬件完成信号处理流程的步骤。
其中，处理器601，用于读取存储器602中的计算机程序，当所述处理器601执行所述计算机程序，实现实施例一中提供的认证反向代理系统的方法和步骤。
需要说明的是，实施例二提供的系统与实施例一提供的方法属于同一个发明构思，解决相同的技术问题，达到相同的技术效果，实施例二提供的系统能实现实施例一的所有方法，相同之处不再赘述。
需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种认证反向代理方法，其特征在于，包括：
认证反向代理系统接收代理认证请求，将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器；
所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端；
所述认证反向代理系统接收将所述代理代码转换为访问令牌Acces Token的转换请求，根据所述转换请求确定网关代码，并把网关代码转换为目标授权服务器代码，向所述目标授权服务器请求访问令牌Access Token；
所述授权服务器接收到所述授权服务器代码后，验证所述授权服务器代码的合法性，若验证通过，则将访问令牌Access Token反馈给客户端。
2.根据权利要求1所述的方法，其特征在于，所述认证反向代理系统接收代理认证请求包括：
所述认证反向代理系统的统一网关组件接收代理认证请求。
3.根据权利要求2所述的方法，其特征在于，包括：
所述授权服务器的接口安全拦截器对所述代理人认证请求进行判别，若所述认证请求为非法授权的客户端发起的，则拒绝所述代理认证请求，
若满足以下条件之一则判定为非法授权的客户端：
IP地址超过预设的网段范围；
域名不在预设的域名范围内；
接口范围不在预定的范围内。
4.根据权利要求2所述的方法，其特征在于，所述将所述代理认证请求转换为目标认证请求，并将所述目标认证请求发送到授权服务器，包括：
所述统一网关将所述代理认证请求发送到认证调度处器，所述认证调度处理器将所述代理认证请求转换为目标认证请求，并将所述目标认证请求返回给所述统一网关；
所述统一网关将所述目标认证请求通过用户代理User Agent重定向给授权服务器。
5.根据权利要求4所述的方法，其特征在于，所述认证调度处理器将所述代理认证请求转换为目标认证请求，包括：
根据域domain或者路径path规则，获取租户的上下文信息，并从所述上下文信息中提取目标授权服务器的客户号client_id，并标记为新客户号new_client_id；所谓租户，即不同的授权服务账号主体，多租户的支持让不同的企业可以同时入驻同一个服务平台，且相互独立运行，互不干扰，由于不需要开启多个服务，达到降低运行成本和资源占用的目的；
利用状态state生成器生成新状态new_state；
将所述新状态new_state作为密钥key，将所述认证请求中的参数客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state存储到缓存池中；
将所述认证反向代理系统的重定向地址标记为新重定向地址new_redirect_uri；
将所述新重定向地址new_redirect_uri，新客户号new_client_id，新状态new_state，反馈类型response_type作为参数，通过SPI接口传递给对应的认证适配器。
6.根据权利要求5所述的方法，其特征在于，所述包括：
所述SPI接口用于由认证反向代理系统代替用户代理User-Agent向目标授权服务器发送认证请求。
7.根据权利要求5所述的方法，其特征在于，所述授权服务器根据所述目标认证请求确定目标代码Code，将所述目标代码发送到所述认证反向代理系统，所述认证反向代理系统将所述目标代码转换为代理代码，并将所述代理代码通过用户代理反馈给客户端，包括：
所述授权服务器验证通过目标认证请求后，将所述目标代码发送到所述认证反向代理系统；
所述认证反向代理系统根据状态State参数，获取新状态new_state；
所述认证反向代理系统通过所述新状态new_state，从所述缓存池中提取原始认证参数，并提取客户号client_id，反馈类型response_type，重定向地址redirect_uri，状态state，并将所述目标代码Code作为附加参数，通过用户代理User-Agent重定向给原始客户端或者原始重定向地址。
8.根据权利要求1所述的方法，其特征在于，所述向所述目标授权服务器请求访问令牌Access Token，包括：
通过SPI的访问令牌接口，由所述认证反向代理系统代替用户代理User-Agent向目标授权服务器请求访问令牌Access Token。
9.根据权利要求1到9之一所述的方法，其特征在于，还包括：
通过SPI的用户信息查询接口，由所述认证反向代理系统代替用户代理User-Agent向目标授权服务器或者资源服务器请求第三方提供的授权用户信息。
10.一种认证反向代理系统，其特征在于，包括：处理器、存储器、网络接口；所述网络接口，用于在处理器的控制下进行数据的接收和发送；
所述存储器，用于存储计算机程序；
所述处理器用于读取所述存储器中的所述计算机程序，所述处理器执行所述计算机程序时，实现权利要求1到9之一所述的认证反向代理方法。
CN202011150695.3A 2020-10-24 2020-10-24 一种认证反向代理方法及系统 Active CN112311783B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011150695.3A CN112311783B (zh) 2020-10-24 2020-10-24 一种认证反向代理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011150695.3A CN112311783B (zh) 2020-10-24 2020-10-24 一种认证反向代理方法及系统

Publications (2)

Publication Number Publication Date
CN112311783A true CN112311783A (zh) 2021-02-02
CN112311783B CN112311783B (zh) 2023-02-28

Family

ID=74327324

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011150695.3A Active CN112311783B (zh) 2020-10-24 2020-10-24 一种认证反向代理方法及系统

Country Status (1)

Country Link
CN (1) CN112311783B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259323A (zh) * 2021-04-20 2021-08-13 新华三大数据技术有限公司 双重访问权限服务认证方法、装置、系统及存储介质
CN113676336A (zh) * 2021-10-22 2021-11-19 深圳市明源云采购科技有限公司 微服务访问代理方法、设备及存储介质
CN113872929A (zh) * 2021-08-16 2021-12-31 中国人民解放军战略支援部队信息工程大学 基于动态域名的web应用安全防护方法、系统及服务器
CN114900336A (zh) * 2022-04-18 2022-08-12 中国航空工业集团公司沈阳飞机设计研究所 一种应用系统跨单位安全共享方法及系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761537A (zh) * 2012-03-29 2012-10-31 北京奇虎科技有限公司 一种基于客户端插件的授权认证方法及系统
EP2809042A1 (en) * 2013-05-29 2014-12-03 Telefonica Digital España, S.L.U. Method for authenticate a user associated to a user agent implemented over SIP protocol
CN109274579A (zh) * 2018-09-04 2019-01-25 江苏龙虎网信息科技股份有限公司 一种基于微信平台的多应用用户统一认证方法
CN110120946A (zh) * 2019-04-29 2019-08-13 武汉理工大学 一种Web与微服务的统一认证系统及方法
US20200076794A1 (en) * 2018-08-31 2020-03-05 Sap Se Certificate-initiated access to services
CN111181727A (zh) * 2019-12-16 2020-05-19 北京航天智造科技发展有限公司 一种基于微服务的开放api全生命周期管理方法
CN111309374A (zh) * 2020-01-21 2020-06-19 苏州达家迎信息技术有限公司 一种微服务系统和微服务系统中的服务调用方法
CN111541656A (zh) * 2020-04-09 2020-08-14 中央电视台 基于融合媒体云平台的身份认证方法及系统

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761537A (zh) * 2012-03-29 2012-10-31 北京奇虎科技有限公司 一种基于客户端插件的授权认证方法及系统
EP2809042A1 (en) * 2013-05-29 2014-12-03 Telefonica Digital España, S.L.U. Method for authenticate a user associated to a user agent implemented over SIP protocol
US20200076794A1 (en) * 2018-08-31 2020-03-05 Sap Se Certificate-initiated access to services
CN109274579A (zh) * 2018-09-04 2019-01-25 江苏龙虎网信息科技股份有限公司 一种基于微信平台的多应用用户统一认证方法
CN110120946A (zh) * 2019-04-29 2019-08-13 武汉理工大学 一种Web与微服务的统一认证系统及方法
CN111181727A (zh) * 2019-12-16 2020-05-19 北京航天智造科技发展有限公司 一种基于微服务的开放api全生命周期管理方法
CN111309374A (zh) * 2020-01-21 2020-06-19 苏州达家迎信息技术有限公司 一种微服务系统和微服务系统中的服务调用方法
CN111541656A (zh) * 2020-04-09 2020-08-14 中央电视台 基于融合媒体云平台的身份认证方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
吴德等: "基于OAuth2.0的认证授权方案设计与优化", 《软件》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259323A (zh) * 2021-04-20 2021-08-13 新华三大数据技术有限公司 双重访问权限服务认证方法、装置、系统及存储介质
CN113259323B (zh) * 2021-04-20 2022-05-27 新华三大数据技术有限公司 双重访问权限服务认证方法、装置、系统及存储介质
CN113872929A (zh) * 2021-08-16 2021-12-31 中国人民解放军战略支援部队信息工程大学 基于动态域名的web应用安全防护方法、系统及服务器
CN113872929B (zh) * 2021-08-16 2023-08-29 中国人民解放军战略支援部队信息工程大学 基于动态域名的web应用安全防护方法、系统及服务器
CN113676336A (zh) * 2021-10-22 2021-11-19 深圳市明源云采购科技有限公司 微服务访问代理方法、设备及存储介质
CN114900336A (zh) * 2022-04-18 2022-08-12 中国航空工业集团公司沈阳飞机设计研究所 一种应用系统跨单位安全共享方法及系统
CN114900336B (zh) * 2022-04-18 2023-07-07 中国航空工业集团公司沈阳飞机设计研究所 一种应用系统跨单位安全共享方法及系统

Also Published As

Publication number Publication date
CN112311783B (zh) 2023-02-28

Similar Documents

Publication Publication Date Title
CN112311783B (zh) 一种认证反向代理方法及系统
CN111783067B (zh) 多网站间的自动登录方法及装置
WO2017129016A1 (zh) 一种资源访问方法、装置及系统
JP5930847B2 (ja) サーバーシステムおよび制御方法およびプログラム
CN101401390B (zh) 多媒体中间件中的安全管理方法和设备及其存储介质
US20050015340A1 (en) Method and apparatus for supporting service enablers via service request handholding
WO2022022253A1 (zh) 一种服务鉴权方法、装置、设备、系统及存储介质
JP2008015936A (ja) サービスシステムおよびサービスシステム制御方法
CN110839087B (zh) 接口调用方法及装置、电子设备和计算机可读存储介质
Guija et al. Identity and access control for micro-services based 5G NFV platforms
US11245577B2 (en) Template-based onboarding of internet-connectible devices
CN108319827B (zh) 一种基于osgi框架的api权限管理系统及方法
JP2010525426A (ja) ネットワークベースのサービスに対するスクリプト可能なオブジェクトモデル
CN114928460A (zh) 一种基于微服务架构的多租户应用集成框架系统
CN109286620A (zh) 用户权限管理方法、系统、设备和计算机可读存储介质
CN112541828B (zh) 实现开放证券管理及开放证券api接入控制的系统、方法、装置、处理器及其存储介质
US9027155B2 (en) System for governing the disclosure of restricted data
Putz et al. Future-proof web authentication: Bring your own FIDO2 extensions
JP2015133025A (ja) データ管理装置
CN111447273B (zh) 云处理系统及基于云处理系统的数据处理方法
RU2422886C2 (ru) Обеспечение согласованного прохода брандмауэра, имеющего информацию о приложении
CN115412294A (zh) 基于平台服务的访问方法及装置、存储介质、电子设备
KR20150115332A (ko) 개방형 서비스 컴포넌트 접근 제어 관리 장치 및 그 방법
CN113901428A (zh) 多租户系统的登录方法及装置
CN113489695A (zh) 私有云组网方法、装置、系统、计算机设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant