WO2014173278A1 - 基于PaaS平台的身份认证方法以及身份认证设备 - Google Patents

基于PaaS平台的身份认证方法以及身份认证设备 Download PDF

Info

Publication number
WO2014173278A1
WO2014173278A1 PCT/CN2014/075883 CN2014075883W WO2014173278A1 WO 2014173278 A1 WO2014173278 A1 WO 2014173278A1 CN 2014075883 W CN2014075883 W CN 2014075883W WO 2014173278 A1 WO2014173278 A1 WO 2014173278A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
ticket
identity authentication
identity
license
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.)
Ceased
Application number
PCT/CN2014/075883
Other languages
English (en)
French (fr)
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.)
China Unionpay Co Ltd
Original Assignee
China Unionpay 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 China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Publication of WO2014173278A1 publication Critical patent/WO2014173278A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the present invention relates to the field of cloud computing security, and in particular, to an identity authentication method based on the PaaS platform and an identity authentication device. Background technique
  • PaaS is an abbreviation of Platform-as-a-Service, which means platform-as-a-service, which uses the server platform as a service provider.
  • the service provided by the program through the network is called SaaS (Software as a Service), and the corresponding server platform or development environment in the cloud computing era is provided as a service to become PaaS.
  • PaaS Identity and Polic Management as a Service
  • IPMaaS Identity and Polic Management as a Service
  • the current status of certification services provided by PaaS is not satisfactory.
  • the authentication services they provide are currently not compatible with multiple user identities, such as local identities (ie, identities registered on the PaaS platform) and OpenlD identities.
  • users need to perform authentication multiple times, and the authentication cooperation between different applications of the same developer is insufficient. Summary of the invention
  • a method for authenticating an identity based on a PaaS platform including: receiving an authentication request from a user using the PaaS platform; determining a protocol to which the identity of the user belongs; The verification mode of the user is determined according to the protocol.
  • the above identity authentication method may further include: sending the first permission ticket to the user after the verification is successful.
  • the foregoing identity authentication method may further include: receiving, from the user, a ticket request for a first application in a PaaS platform, the ticket request including the first license ticket; and transmitting, to the user, the first application a second license ticket, such that the user can obtain the service of the first application by means of the second license ticket; receive a ticket request for the second application in the PaaS platform from the user, The bill request includes the first license ticket; and transmitting a third license ticket for the second application to the user, such that the user can obtain the service of the second application by virtue of the third license ticket .
  • the first license ticket is a ticket license ticket TGT
  • the second license ticket and the third license ticket are service license tickets.
  • the protocol to which the identity of the user belongs may be a Kerberos protocol or an OpenID protocol.
  • the authentication server, the 0penID provider, and the user in the PaaS platform authenticate according to the OpenID protocol standard.
  • the user and the authentication server use a Diffie-Hellman algorithm to calculate a shared key.
  • an identity authentication device is provided on a PaaS platform, and the identity authentication device is configured to perform identity authentication on a user who is ready to access an application on the PaaS platform, where the identity authentication device includes: a key distribution center, configured to authenticate a user and distribute a ticket according to an access policy formulated by a developer of an application on the PaaS platform, wherein the key distribution center includes an authentication server, and the authentication server is configured to receive the source Determining a verification request of the user; determining a protocol to which the identity of the user belongs; determining a verification mode of the user according to the protocol, and sending the first license ticket to the user after the verification is successful.
  • the identity authentication device includes: a key distribution center, configured to authenticate a user and distribute a ticket according to an access policy formulated by a developer of an application on the PaaS platform, wherein the key distribution center includes an authentication server, and the authentication server is configured to receive the source Determining a verification request of the user; determining a protocol to which the identity of the
  • the key distribution center further includes: a ticket license server configured to receive a ticket request for the first application in the PaaS platform from the user, the ticket request including The first license ticket; transmitting a second license ticket for the first application to the user, such that the user can obtain the service of the first application by virtue of the second license ticket.
  • the ticket license server may be further configured to receive a ticket request for the second application in the PaaS platform from the user, the ticket request including the first license ticket; and transmitting to the user for the first
  • the third license ticket of the second application enables the user to obtain the service of the second application by means of the third license ticket.
  • the first license ticket is a ticket license ticket TGT
  • the second license ticket and the third license ticket are service license tickets.
  • the protocol to which the identity of the user belongs may be the Kerberos protocol or the OpenlD protocol.
  • the authentication server determines that the identity of the user belongs to the OpenlD protocol
  • the authentication server, the OpenlD provider, and the user are authenticated according to the OpenlD protocol standard.
  • the user and the authentication server utilize a Diffie-Hel lman algorithm to calculate a shared key.
  • the above-mentioned PaaS platform-based identity authentication method and identity authentication device enable the PaaS service provider to provide an efficient and flexible identity authentication service for the application on the PaaS service provider.
  • the authentication method and device can meet the same developer's need to develop multiple relatively independent but identical/similar authentications at a low cost.
  • the identity authentication method and device are compatible with local identity and OpenlD identity representing a federated identity trend, and are well scalable to accommodate more categories of identities. The entire authentication process can achieve a low number of authentication times similar to the Kerberos protocol.
  • FIG. 1 is a schematic diagram of an identity authentication service model in accordance with one embodiment of the present invention.
  • FIG. 2 is a schematic diagram of a method of identity authentication based on the PaaS platform, in accordance with one embodiment of the present invention. detailed description
  • PaaS which only supports local identity
  • the most representative joint authentication protocol is OpenID. For example, logging in to a website that supports OpenID is as simple as entering a pre-registered OpenID username, and then logging in to the OpenID service website. After entering the password (or other information that needs to be filled in) on the OpenID service website, the user will be redirected back to the logged-in website and the login is successful.
  • OpenID can be applied to all areas where authentication is required, both for single sign-on systems and for identity authentication when sharing sensitive data. Thus PaaS compatible with local identity and OpenID identity (or other identity) is desirable.
  • App For application (App) developers, they developed their own applications on the PaaS cloud platform, such as Appl and App2. Applications are relatively functionally independent and are developed in different languages, but often their authentication requirements are similar. As the number of identities increases, the issue of identity authentication becomes more complex. Developers often want the PaaS platform to provide authentication services so that developers can authenticate users by simply calling the API. As an example, developers can configure access policies for their applications, for example: For Appl, developers want only local identities to access; for App2, developers want local identities and OpenID identities to be accessible.
  • a reduction in the number of authentications means a decrease in the frequency of key usage, which in addition to improving system efficiency can also significantly improve security.
  • this paper provides identity authentication devices on the PaaS platform and identity authentication methods based on the PaaS platform.
  • Cloud computing service providers that provide PaaS services can use this authentication device and method to provide efficient, flexible, and scalable authentication services for their applications.
  • FIG 1 shows a schematic diagram of an identity authentication model based on a PaaS environment.
  • the identity authentication model consists of three main parts: users, developers, and PaaS platforms. The following is a brief introduction.
  • users include local users, OpenID users, and other users.
  • the local user refers to the user registered on the PaaS platform
  • the OpenID user refers to the OpenID protocol.
  • An identity registered at an OpenID provider, while other users refer to extended users of multiple identities.
  • Developers are people who use the cloud platform to develop application applications, which can develop access policies for their developed applications to the PaaS platform.
  • the PaaS cloud platform provides developers with PaaS services to deploy applications and, on the other hand, to authenticate users accessing applications on the platform.
  • the PaaS cloud platform can include a program pool and a key distribution center.
  • the program pool in Figure 1 shows only two applications: the first application (app l) and the second application (app2), but those skilled in the art should understand that the program pool can contain more or less.
  • the program not just two.
  • the identity authentication device described herein can be implemented via a key distribution center on the PaaS platform.
  • the key distribution center is used to authenticate users and distribute tickets based on the developer's access policy.
  • the key distribution center may include an Authentication Server (AS) for authenticating the identity of the user and distributing a Ticket Granting Ticket (TGT).
  • AS Authentication Server
  • TGT Ticket Granting Ticket
  • the authentication server is configurable to receive an authentication request from the user, determine a protocol to which the identity of the user belongs, determine the authentication mode of the user based on the protocol, and send the ticket license ticket to the user after the verification is successful. It is important to point out that the identity of the user's identity can be the Kerberos protocol, the OpenID protocol, or other extended protocols.
  • the Key Distribution Center may also include a Ticket Granting Server (TGS) for verifying ticket license tickets (TGTs) and for distributing service license tickets for accessing the App.
  • the ticket license server is configurable to receive a ticket request for a first application (appl) in the PaaS platform from the user, the ticket request including a ticket license ticket; sending the user a first application
  • the service license ticket enables the user to obtain the service of the first application by means of the service license ticket.
  • the ticket license server may be further configured to receive a ticket request for a second application (app2) in the PaaS platform from the user, the ticket request also including a ticket license ticket; and transmitting a service license ticket for the second application to the user , enabling the user to obtain the service of the second application by means of the service license ticket.
  • a second application app2
  • the ticket license server may be further configured to receive a ticket request for a second application (app2) in the PaaS platform from the user, the ticket request also including a ticket license ticket; and transmitting a service license ticket for the second application to the user , enabling the user to obtain the service of the second application by means of the service license ticket.
  • Table 1 shows the important interactions in the identity authentication model.
  • User authentication is a core part of the identity authentication model. According to one embodiment of the invention, the user accesses the application primarily through three major steps.
  • the authentication access exchange the user accesses the authentication server of the key distribution center to verify the identity and obtain the ticket license ticket, and the manner of verification varies according to the protocol to which the identity belongs.
  • the ticket licensing service exchange The user accesses the ticket distribution server of the key distribution center, and exchanges the ticket license ticket for the service license ticket.
  • client/server authentication exchange Access the application's services with a service license ticket.
  • the user can log in either as a local identity or as an OpenlD identity, and can use more other identity logins as the system expands. If the local identity is used, the user registers with the PaaS service provider in a similar manner to the traditional way. Thereafter, the user and the AS authenticate according to the authentication access protocol of Kerber OS V5 according to the shared password created at the time of registration. If the OpenlD identity is used, the authentication of the user and the cloud platform needs to be done by the OpenlD provider.
  • the premise of the authentication access exchange of the Kerberos V5 protocol is that the user and the authentication server have shared the key, but in the OpenlD protocol, it is another scenario.
  • the user registers the OpenlD identity with the OpenlD provider, so that only the OpenlD provider has the ability to authenticate the user.
  • the user accesses the PaaS service provider as an RP (Relying Party), and the RP does not share the key with the user.
  • the RP authenticates the user and must be assisted by the OpenlD provider in accordance with the OpenlD protocol. Based on the above considerations, the authentication access exchange of Kerberos needs to be modified.
  • the specific authentication process is as follows:
  • the user calculates the public-private key pair by using the Diffie-Hel lman protocol
  • the user sends a request to the authentication server, which includes the user ID identifier and the ticket licensing service. Identification, client clock, and user-side public key;
  • the authentication server, the OpenID provider, and the user are authenticated according to the OpenID protocol standard. After successful authentication, the authentication server trusts the user to conform to its claimed identity;
  • the authentication server uses the Diffie-Hel lman protocol to calculate a public-private key pair and a key shared between it and the user;
  • the authentication server sends a ticket license ticket to the user, which includes the authentication server side public key, and the content encrypted by the key shared between the authentication server and the user, the content including the key and the ticket shared by the user with the ticket license server.
  • the ticket used by the user to access the ticket license server may further include the second content encrypted with the permanent key shared between the ticket license server and the authentication server.
  • the second content includes a shared key temporarily generated by the user and the ticket license server, a user ID identifier, a ticket license server identifier, a time of issue of the ticket, and an expiration date of the ticket.
  • Kerberos is a multi-application authentication solution, but its limitation is that before Kerberos authentication, each user's password is stored on the authentication server, and the authentication of both parties is based on the pre-shared password. Limits the application of Kerberos. It is necessary to point out that in the embodiment of the present invention, the shared key temporarily generated between the user and the authentication server can effectively compensate for the problem that the user and the authentication server do not share the key before the request is delivered, and the confidentiality is realized.
  • the user gets the ticket license ticket.
  • the client sends a request to the ticket license server for accessing a program V, the request including the identifier of the application V, and the ticket used by the user to access the ticket license server (for example, the ticket can be exchanged from the fifth access of the authentication access)
  • the ticket license server returns a ticket for accessing the program V to the user, the ticket including the use
  • the shared key temporarily generated by the user and the ticket license server to encrypt the shared key between the user and the application, the identifier of the program V, the time the ticket was issued, and the ticket that the user used to access the application V.
  • the ticket used by the user to access the application V may further include content that encrypts the shared key between the user and the application V by the key of the application V, the user identifier, the application V identifier, and the time of issuance of the ticket. .
  • the ticket licensing service exchange is independent of the authentication process of the authentication server.
  • the developer of the application defines the policy for access in advance, and the ticket license server stores the authorization policy.
  • the ticket licensing server distributes the service license tickets for a particular application based on the developer-defined authorization information.
  • the user uses the service license ticket to access the application. Specifically, the user sends an access request to the application, including the service license ticket and the content that encrypts the user identification with the shared key between the user and the application.
  • the PaaS platform-based identity authentication method shown in FIG. 2 is a good example of the above three steps.
  • the request TGT, identity authentication, and return TGT shown in FIG. 2 schematically illustrate the previously described authentication access phase, and the request ticket and the return ticket shown in FIG. 2 schematically illustrate the ticket licensing service exchange phase.
  • the access application step shown in Figure 2 belongs to the user/server authentication exchange phase.
  • the PaaS platform-based identity authentication method and the identity authentication device according to the present invention can achieve the following advantages:
  • the PaaS identity authentication service designed by the present invention enables application developers to free themselves from more complex identity authentication problems and to focus on application development.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种平台即服务(PaaS)平台上的身份认证设备,所述身份认证设备用于对准备访问所述PaaS平台上的应用的用户进行身份认证,所述身份认证设备包括:密钥分发中心,用于根据PaaS平台上的应用的开发者所制定的访问策略对用户进行认证并分发票据,其中所述密钥分发中心包括鉴别服务器,所述鉴别服务器配置成接收来自所述用户的验证请求;确定所述用户的身份所属的协议;根据所述协议来确定所述用户的验证方式以及在验证成功后向所述用户发送第一许可票据。本发明还公开了一种基于PaaS平台的身份认证方法。

Description

基于 PaaS平台的身份认证方法以及身份认证设备 技术领域
本发明涉及云计算安全领域, 特别涉及一种基于 PaaS平台的身份认证方 法以及身份认证设备。 背景技术
PaaS是 Platform-as-a-Service的缩写, 意思是平台即服务, 把服务器 平台作为一种服务提供的模式。 通过网络进行程序提供的服务称之为 SaaS (Software as a Service) , 而云计算时代相应的服务器平台或者开发环 境作为服务进行提供就成为了 PaaS。
开发者在利用 PaaS进行开发、部署其应用时,往往希望调用 PaaS来提供 接口, 以便对用户进行身份认证, 即提供类似 IPMaaS (Identity and Pol icy Management as a Service)服务。 但是, PaaS 提供的认证服务的现状却不尽 如人意。 对于 PaaS服务提供商而言, 其提供的认证服务目前还不能同时兼容 用户的多种身份, 例如本地身份(即在 PaaS 平台上注册的身份)以及 OpenlD 身份。 除此之外, 还存在着用户需多次进行认证, 同一开发者的不同应用之间 认证协同度不够的问题。 发明内容
为解决上述问题, 根据本发明的一个方面, 提供了一种基于 PaaS平台的 身份认证方法, 包括: 接收来自使用所述 PaaS平台的用户的验证请求; 确定 所述用户的身份所属的协议; 以及根据所述协议来确定所述用户的验证方式。
上述身份认证方法还可包括: 在验证成功后向所述用户发送第一许可票 据。
上述身份认证方法还可包括: 从所述用户接收针对 PaaS平台中的第一应 用的票据请求,所述票据请求中包含所述第一许可票据; 向所述用户发送针对 所述第一应用的第二许可票据,使得所述用户凭借此第二许可票据可获得所述 第一应用的服务; 从所述用户接收针对 PaaS平台中的第二应用的票据请求, 所述票据请求中包含所述第一许可票据;以及向所述用户发送针对所述第二应 用的第三许可票据,使得所述用户凭借此第三许可票据可获得所述第二应用的 服务。
在上述身份认证方法中, 所述第一许可票据为票据许可票据 TGT, 所述第 二许可票据和所述第三许可票据为服务许可票据。
在上述身份认证方法中, 所述用户的身份所属的协议可以是 Kerberos协 议或 OpenID协议。
在上述身份认证方法中, 当确定所述用户的身份所属的协议是 OpenID协 议时, PaaS平台中的鉴别服务器、0penID提供商以及所述用户三方依据 OpenID 的协议标准进行认证。
在上述身份认证方法中, 所述用户和所述鉴别服务器利用 Diffie-Hellman算法来计算共享的密钥。
根据本发明的另一个方面, 提供了一种 PaaS平台上的身份认证设备, 所 述身份认证设备用于对准备访问所述 PaaS 平台上的应用的用户进行身份认 证, 所述身份认证设备包括: 密钥分发中心, 用于根据 PaaS平台上的应用的 开发者所制定的访问策略对用户进行认证并分发票据, 其中,所述密钥分发中 心包括鉴别服务器,所述鉴别服务器配置成接收来自所述用户的验证请求; 确 定所述用户的身份所属的协议;根据所述协议来确定所述用户的验证方式以及 在验证成功后向所述用户发送第一许可票据。
在上述身份认证设备中, 所述密钥分发中心还包括: 票据许可服务器, 所 述票据许可服务器配置成从所述用户接收针对 PaaS平台中的第一应用的票据 请求,所述票据请求中包含所述第一许可票据; 向所述用户发送针对所述第一 应用的第二许可票据,使得所述用户凭借此第二许可票据可获得所述第一应用 的服务。 所述票据许可服务器可进一歩配置成从所述用户接收针对 PaaS平台 中的第二应用的票据请求, 所述票据请求中包含所述第一许可票据; 以及向所 述用户发送针对所述第二应用的第三许可票据,使得所述用户凭借此第三许可 票据可获得所述第二应用的服务。
在上述身份认证设备中, 所述第一许可票据为票据许可票据 TGT, 所述第 二许可票据和所述第三许可票据为服务许可票据。 在上述身份认证设备中, 所述用户的身份所属的协议可以是 Kerberos协 议或 OpenlD协议。
在上述身份认证设备中,当所述鉴别服务器确定所述用户的身份所属的协 议是 OpenlD协议时, 所述鉴别服务器、 OpenlD提供商以及所述用户三方依据 OpenlD的协议标准进行认证。
在上述身份认证设备中, 所述用户和所述鉴别服务器利用 Diffie-Hel lman算法来计算共享的密钥。
上述基于 PaaS平台的身份认证方法和身份认证设备使 PaaS服务提供商为 其上的应用程序提供高效灵活的身份认证服务。该身份认证方法和设备能低代 价地满足同一开发者开发多个相对独立的、但却又相同 /相近身份认证的需求。 并且, 该身份认证方法和设备可兼容本地身份以及代表联合身份认证趋势的 OpenlD 身份, 并有很好的扩展性以兼容更多类别的身份。 整个认证过程可达 到 Kerberos协议相似的低认证次数效果。 附图说明
在参照附图阅读了本发明的具体实施方式以后,本领域技术人员将会更清 楚地了解本发明的各个方面。本领域技术人员应当理解的是: 这些附图仅仅用 于配合具体实施方式说明本发明的技术方案,而并非意在对本发明的保护范围 构成限制。
图 1是根据本发明的一个实施例的身份认证服务模型的示意图;
图 2是根据本发明的一个实施例、 基于 PaaS平台的身份认证方法的示意 图。 具体实施方式
下面介绍的是本发明的多个可能实施例中的一些,旨在提供对本发明的基 本了解, 并不旨在确认本发明的关键或决定性的要素或限定所要保护的范围。 容易理解, 根据本发明的技术方案, 在不变更本发明的实质精神下, 本领域的 一般技术人员可以提出可相互替换的其它实现方式。 因此, 以下具体实施方式 以及附图仅是对本发明的技术方案的示例性说明,而不应当视为本发明的全部 或者视为对本发明技术方案的限定或限制。
对于 PaaS而言, 只支持本地身份的 PaaS会在其业务拓展上遇到瓶颈。让 用户省去注册的歩骤并直接兼容用户已有身份是未来互联网发展的趋势,其中 最有代表性的联合身份认证协议便是 OpenID。 例如, 登录一个支持 OpenID的 网站非常简单, 只需要输入预先注册的 OpenID用户名, 然后登录的网站会跳 转到 OpenID服务网站。 在 OpenID服务网站内输入密码(或者其他需要填写的 信息)验证通过后, 跳转回登录的网站并且这时已经成功登录。 OpenID可应用 于所有需要身份验证的地方, 既可以应用于单点登录系统, 也可以用于共享敏 感数据时的身份认证。 因而兼容本地身份以及 OpenID 身份(或其他身份)的 PaaS是所希望的。
对于应用程序 (Application, App)开发者而言, 其在 PaaS云平台上开发 了自己应用程序, 例如 Appl和 App2。 应用程序在功能上相对独立, 并且使用 不同的语言开发, 但通常其身份认证需求是相近的。 随着身份种类的增多, 身 份认证问题变得越发复杂。开发者往往希望 PaaS平台能够提供身份认证服务, 以使得开发者只需简单调用 API便能够对用户进行身份认证。作为举例, 开发 者可配置其应用程序的访问策略, 例如: 对于 Appl , 开发者希望只有本地身 份才可以访问;对于 App2,开发者希望本地身份以及 OpenID身份都可以访问。
对于使用开发者应用程序的用户而言, 不管其拥有的身份如何, 总希望在 访问应用时减少认证次数。认证次数的减少意味着密钥使用频率的下降, 这一 点除了能够提高系统效率, 还能够显著提高安全性。
为了兼容多种身份、 满足 PaaS上应用程序对身份认证的需求以及减少认 证次数,本文提供了 PaaS平台上的身份认证设备以及基于 PaaS平台的身份认 证方法。 提供 PaaS服务的云计算服务商可以使用这种身份认证设备和方法来 为其上的应用提供高效、 灵活、 易扩展的身份认证服务。
图 1示出了基于 PaaS环境下的身份认证模型的示意图。 该身份认证模型 包括了三大部分: 用户、 开发者以及 PaaS平台。 以下依次对其进行简单的介 绍。
如图 1所示,用户(custom, C)包括本地用户、 OpenID用户以及其他用户。 其中, 本地用户指在 PaaS平台注册的用户, OpenID用户指根据 OpenID协议 在某个 OpenID提供商处注册的身份, 而其他用户则是指扩展的其他多种身份 的用户。
开发者是借助云平台开发应用 App服务的人员, 其可向 PaaS平台制定其 开发的应用程序的访问策略。
PaaS云平台一方面对开发者提供 PaaS服务以部署应用程序, 另一方面对 访问平台上的应用程序的用户进行身份验证。 如图 1所示, PaaS云平台可包 括程序池和密钥分发中心。
图 1中的程序池仅示出有两个应用程序:第一应用程序(app l)和第二应用 程序(app2),但本领域技术人员应当理解,程序池中可包含更多或更少的程序, 而不单单限于两个。
在一个具体的实施例中, 本文所述的身份认证设备可通过 PaaS平台上的 密钥分发中心来实现。该密钥分发中心用于根据开发者的访问策略对用户进行 认证并分发票据。
如图 1所示, 密钥分发中心可包括用于负责认证用户身份, 并分发票据许 可票据(Ticket Granting Ticket , TGT)的鉴别服务器(Authentication Server , AS)。 在一个具体的实施例中, 鉴别服务器可配置成接收来自用户的 验证请求, 确定用户的身份所属的协议, 根据协议来确定用户的验证方式以及 在验证成功后向用户发送票据许可票据。有必要指出的是,用户的身份所属的 协议可以是 Kerberos协议、 OpenID协议或其他扩展的协议。
继续参考图 1, 密钥分发中心还可包括用于验证票据许可票据 (TGT)并负 责分发访问 App的服务许可票据的票据许可服务器(Ticket Grant ing Server , TGS)。在一个具体的实施例中,票据许可服务器可配置成从用户接收针对 PaaS 平台中的第一应用程序 (appl)的票据请求, 该票据请求中包含票据许可票据; 向用户发送针对第一应用程序的服务许可票据,使得用户凭借此服务许可票据 可获得第一应用程序的服务。票据许可服务器可进一歩配置成从用户接收针对 PaaS 平台中的第二应用程序 (app2)的票据请求, 该票据请求中同样包含票据 许可票据; 以及向用户发送针对第二应用程序的服务许可票据, 使得用户凭借 此服务许可票据可获得第二应用程序的服务。
表 1示出了身份认证模型中的重要交互。 表 1
Figure imgf000008_0001
用户认证是身份认证模型的核心部分。根据本发明的一个具体实施例,用 户访问应用程序主要经过三大歩骤。
第一歩, 鉴别访问交换:用户访问密钥分发中心的鉴别服务器以验证身份 并获得票据许可票据,验证的方式根据其身份所属的协议不同而有所差异。第 二歩, 票据许可服务交换: 用户访问密钥分发中心的票据许可服务器, 用票据 许可票据换取服务许可票据。 第三歩, 客户 /服务器鉴别交换: 用服务许可票 据访问应用的服务。
在第一歩鉴别访问交换中, 用户既可以用本地身份登陆也可以使用 OpenlD 身份登陆, 随着系统的扩展还可以使用更多的其他身份登陆。 如果使 用本地身份,那么用户类似传统方式在 PaaS服务商注册, 此后用户和 AS根据 注册时创建的共享口令按照 KerberOS V5的鉴别访问交换协议进行认证。如果 使用 OpenlD身份,则用户和云平台的身份认证工作需要由 OpenlD提供商协助 完成。 Kerberos V5协议的鉴别访问交换的前提是用户和鉴别服务器已共享密 钥,而在 OpenlD协议中却是另一种场景。用户在 OpenlD提供商处注册 OpenlD 身份, 使得只有 OpenlD提供商拥有对用户进行认证的能力。 此时用户访问作 为 RP (Relying Party, 依赖方)的 PaaS服务商, RP并没有和用户共享密钥。 RP对用户的身份认证必须依照 OpenlD协议引入 OpenlD提供商方的协助。 基 于上述考虑需要对 Kerberos的鉴别访问交换进行修改, 具体认证流程如下:
(1)用户利用 Diffie-Hel lman协议计算公私钥对;
(2)用户向鉴别服务器发送请求,请求中包括用户 ID标识、票据许可服务 器标识、 用户端时钟和用户方公钥;
(3)鉴别服务器、 OpenID提供商以及用户三方依据 OpenID的协议标准进 行认证, 成功认证后鉴别服务器信任用户符合其声称的身份;
(4)鉴别服务器利用 Diffie-Hel lman 协议计算公私钥对以及其与用户之 间共享的密钥;
(5)鉴别服务器向用户发送票据许可票据, 其中包含鉴别服务器方公钥, 以及用鉴别服务器与用户之间共享的密钥加密的内容,该内容包括用户与票据 许可服务器共享的密钥、 票据许可服务器标识、服务许可票据的签发时间、服 务许可票据的有效期、 以及用户用来访问票据许可服务器的票据。 其中, 用户 用来访问票据许可服务器的票据可进一歩包括用票据许可服务器与鉴别服务 器之间共享的永久密钥加密的第二内容。第二内容包括用户与票据许可服务器 临时生成的共享密钥、 用户 ID标识、 票据许可服务器标识、 该票据的签发时 间以及该票据的有效期。
在现有技术中, Kerberos 是一种多应用身份认证解决方案, 但是其局限 性在于 Kerberos认证前假设每个用户的口令都已储存在认证服务器端, 双方 的认证是基于预共享口令, 这点限制了 Kerberos的应用。 有必要指出的是, 在本发明的实施例中,用户与鉴别服务器之间临时生成的共享密钥能有效弥补 用户与鉴别服务器在传递请求之前没有共享密钥的问题, 实现了保密性。
如果希望支持 PaaS平台支持更多的身份以访问应用, 只需根据身份所参 照的协议修改鉴别访问交换阶段即可,这体现了本模型对于更多身份类别的可 扩展性。
鉴别访问交换阶段结束后, 用户得到了票据许可票据。
对于第二歩票据许可服务交换, 其实现的流程可如下所示:
(1)客户向票据许可服务器发送请求用于访问某个程序 V, 该请求中包括 应用程序 V的标识、 用户用来访问票据许可服务器的票据(该票据例如可从鉴 别访问交换的第 5歩中获得)、 由用户生成标识自身的内容, 该内容包含用用 户与票据许可服务器临时生成的共享密钥来对用户标识和用户申请服务许可 票据的时间两者进行加密的内容;
(2)票据许可服务器向用户返回用以访问程序 V的票据, 该票据包括用用 户与票据许可服务器临时生成的共享密钥来对用户与应用程序之间的共享密 钥、程序 V的标识、该票据签发的时间以及用户用以访问应用程序 V的票据进 行加密的内容。 用户用以访问应用程序 V 的票据可进一歩包括用应用程序 V 的密钥对用户与应用程序 V之间的共享密钥、用户标识、应用程序 V标识以及 该票据的签发时间进行加密的内容。
票据许可服务交换独立于鉴别服务器的鉴别过程。应用程序的开发者事先 定义了访问的策略, 并由票据许可服务器存储授权该策略。在票据许可服务交 换阶段,票据许可服务器依据开发者定义的授权信息来分发具体应用的服务许 可票据。
对于第三歩用户 /服务器鉴别交换, 用户使用服务许可票据来访问应用程 序 。 具体来说, 用户向应用程序发送访问请求, 其中包括服务许可票据以及 用用户与应用程序之间的共享密钥对用户标识进行加密的内容。
图 2中示出的基于 PaaS平台的身份认证方法很好地展示了上述三大歩骤。 图 2中示出的请求 TGT、 身份认证、 返回 TGT歩骤示意示出之前所述的鉴别访 问阶段, 图 2中示出的请求 ticket、 返回 ticket歩骤则示意示出了票据许可 服务交换阶段。 最后, 图 2中示出的访问应用歩骤则属于用户 /服务器鉴别交 换阶段。
综上, 采用本发明所述的基于 PaaS平台的身份认证方法和身份认证设备 可取得如下优点:
1)传统身份认证方式访问每个应用都需要独立的身份验证。 本发明中 AS 和 TGS的设计使得用户多次访问同一位开发者的不同 App应用时无需反复进行 身份认证。用户只需通过一次身份认证以获得 TGT,随后针对不同的 App用 TGT 换取应用程序对应的 ticket , 减少了用户口令的使用频度。
2)与现有的一些跨应用身份认证方式相比, 兼容了本地身份以及 OpenID, 并对其他的身份兼容也有很好的扩展性和灵活性。当系统需要支持更多的身份 类别时, 只需要在鉴别访问交换阶段增加认证方式。
3)本发明设计的 PaaS的身份认证服务使得应用程序开发者从越发复杂的 身份认证问题中解脱出来, 能够专注于应用的开发。
4)最小化认证开销, 减小了用户口令的使用频度, 用户体验更加友好。 上文中, 参照附图描述了本发明的具体实施方式。但是, 本领域中的普通 技术人员能够理解,在不偏离本发明的精神和范围的情况下, 还可以对本发明 的具体实施方式作各种变更和替换。这些变更和替换都落在本发明权利要求书 所限定的范围内。

Claims

权利要求
1. 一种基于 PaaS平台的身份认证方法, 包括:
接收来自使用所述 PaaS平台的用户的验证请求;
确定所述用户的身份所属的协议; 以及
根据所述协议来确定所述用户的验证方式。
2. 如权利要求 1所述的身份认证方法, 还包括:
在验证成功后向所述用户发送第一许可票据。
3. 如权利要求 2所述的身份认证方法 , 还包括:
从所述用户接收针对 PaaS平台中的 J 一应用的票据请求, 所述票据请求 中包含所述第一许可票据; 以及
向所述用户发送针对所述第一应用的第二许可票据,使得所述用户凭借此 第二许可票据可获得所述第一应用的服务
4. 如权利要求 3所述的身份认证方法, 进一歩包括:
从所述用户接收针对 PaaS平台中的 J 二应用的票据请求, 所述票据请求 中包含所述第一许可票据; 以及
向所述用户发送针对所述第二应用的第三许可票据,使得所述用户凭借此 第三许可票据可获得所述第二应用的服务
5. 如权利要求 2至 4中任一项所述的身份认证方法, 其中, 所述第一许可 票据为票据许可票据 TGT。
6. 如权利要求 3所述的身份认证方法, 其中,所述第二许可票据为服务许 可票据。
7. 如权利要求 4所述的身份认证方法, 其中,所述第三许可票据为服务许 可票据。
8. 如权利要求 1所述的身份认证方法, 其中,所述用户的身份所属的协议 可以是 Kerberos协议或 OpenlD协议。
9. 如权利要求 8所述的身份认证方法, 其中, 当确定所述用户的身份所属 的协议是 OpenlD协议时, PaaS平台中的鉴别服务器、 OpenlD提供商以及所述 用户三方依据 OpenlD的协议标准进行认证。
10. 如权利要求 9所述的身份认证方法, 其中, 所述用户和所述鉴别服务 器利用 Diffie-Hel lman算法来计算共享的密钥。
11. 一种 PaaS平台上的身份认证设备, 所述身份认证设备用于对准备访 问所述 PaaS平台上的应用的用户进行身份认证, 所述身份认证设备包括: 密钥分发中心, 用于根据 PaaS平台上的应用的开发者所制定的访问策略 对用户进行认证并分发票据, 其中, 所述密钥分发中心包括鉴别服务器, 所述 鉴别服务器配置成接收来自所述用户的验证请求;确定所述用户的身份所属的 协议;根据所述协议来确定所述用户的验证方式以及在验证成功后向所述用户 发送第一许可票据。
12. 如权利要求 11所述的身份认证设备,其中,所述密钥分发中心还包括: 票据许可服务器, 所述票据许可服务器配置成从所述用户接收针对 PaaS平台 中的第一应用的票据请求, 所述票据请求中包含所述第一许可票据; 向所述用 户发送针对所述第一应用的第二许可票据,使得所述用户凭借此第二许可票据 可获得所述第一应用的服务。
13. 如权利要求 12所述的身份认证设备, 其中,所述票据许可服务器还配 置成从所述用户接收针对 PaaS平台中的第二应用的票据请求, 所述票据请求 中包含所述第一许可票据;以及向所述用户发送针对所述第二应用的第三许可 票据, 使得所述用户凭借此第三许可票据可获得所述第二应用的服务。
14. 如权利要求 11至 13中的任一项所述的身份认证设备, 其中, 所述第一 许可票据为票据许可票据 TGT。
15. 如权利要求 12所述的身份认证设备,其中所述第二许可票据为服务许 可票据。
16. 如权利要求 13所述的身份认证设备,其中所述第三许可票据为服务许 可票据。
17. 如权利要求 11所述的身份认证设备, 其中,所述用户的身份所属的协 议可以是 Kerberos协议或 OpenID协议。
18. 如权利要求 17所述的身份认证设备, 其中, 当所述鉴别服务器确定所 述用户的身份所属的协议是 OpenID协议时, 所述鉴别服务器、 OpenID提供商 以及所述用户三方依据 OpenID的协议标准进行认证。
19. 如权利要求 18所述的身份认证设备, 其中,所述用户和所述鉴别服 器利用 Diffie-Hel lman算法来计算共享的密钥。
PCT/CN2014/075883 2013-04-22 2014-04-22 基于PaaS平台的身份认证方法以及身份认证设备 Ceased WO2014173278A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310139856.2A CN104113412A (zh) 2013-04-22 2013-04-22 基于PaaS平台的身份认证方法以及身份认证设备
CN201310139856.2 2013-04-22

Publications (1)

Publication Number Publication Date
WO2014173278A1 true WO2014173278A1 (zh) 2014-10-30

Family

ID=51710051

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/075883 Ceased WO2014173278A1 (zh) 2013-04-22 2014-04-22 基于PaaS平台的身份认证方法以及身份认证设备

Country Status (2)

Country Link
CN (1) CN104113412A (zh)
WO (1) WO2014173278A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104660583B (zh) * 2014-12-29 2018-05-29 国家电网公司 一种基于Web加密服务的加密服务方法
CN105072138B (zh) * 2015-01-16 2018-07-10 北京科技大学 一种云系统安全访问方法
CN105429991A (zh) * 2015-12-02 2016-03-23 成都汇合乾元科技有限公司 移动终端高效数据传输方法
CN105635132B (zh) * 2015-12-24 2018-09-07 浪潮软件集团有限公司 一种用户认证的方法及系统
CN108243158A (zh) * 2016-12-26 2018-07-03 中移(苏州)软件技术有限公司 一种安全认证的方法和装置
US10659464B2 (en) * 2017-05-10 2020-05-19 Microsoft Technology Licensing, Llc Securely authenticating a bot user
CN108574576B (zh) * 2018-04-26 2021-05-28 中科边缘智慧信息科技(苏州)有限公司 基于Kerberos系统的跨云际认证方法
CN109120397B (zh) * 2018-07-18 2020-12-11 郑州信大捷安信息技术股份有限公司 一种基于标识密码的单证鉴别方法及系统
CN114385986B (zh) * 2020-10-21 2025-08-29 卡奥斯数字科技(青岛)有限公司 一种应用访问方法、系统、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102457376A (zh) * 2010-10-29 2012-05-16 中兴通讯股份有限公司 一种云计算服务统一认证的方法和系统
CN102571948A (zh) * 2011-12-29 2012-07-11 国云科技股份有限公司 基于云计算的PaaS平台系统及其实现方法
US20130007845A1 (en) * 2011-06-30 2013-01-03 International Business Machines Corporation Authentication and authorization methods for cloud computing security platform

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102457376A (zh) * 2010-10-29 2012-05-16 中兴通讯股份有限公司 一种云计算服务统一认证的方法和系统
US20130007845A1 (en) * 2011-06-30 2013-01-03 International Business Machines Corporation Authentication and authorization methods for cloud computing security platform
CN102571948A (zh) * 2011-12-29 2012-07-11 国云科技股份有限公司 基于云计算的PaaS平台系统及其实现方法

Also Published As

Publication number Publication date
CN104113412A (zh) 2014-10-22

Similar Documents

Publication Publication Date Title
CN112822675B (zh) 面向MEC环境的基于OAuth2.0的单点登录机制
WO2014173278A1 (zh) 基于PaaS平台的身份认证方法以及身份认证设备
EP4264880B1 (en) Integration of legacy authentication with cloud-based authentication
US10810515B2 (en) Digital rights management (DRM)-enabled policy management for an identity provider in a federated environment
US9094208B2 (en) User identity management and authentication in network environments
US10541991B2 (en) Method for OAuth service through blockchain network, and terminal and server using the same
CN103718201B (zh) 由多租户服务提供方执行动态平台重新配置
US9038138B2 (en) Device token protocol for authorization and persistent authentication shared across applications
JP5570610B2 (ja) 遠隔ユーザ・セッションのためのシングル・サインオン
CN102792311B (zh) 安全动态权力委派
CN105577665B (zh) 一种云环境下的身份和访问控制管理系统及方法
CN103563294B (zh) 用于云计算平台安全性的认证和授权方法
WO2022121461A1 (zh) 一种云平台资源访问控制的令牌构造方法、装置及设备
KR102410006B1 (ko) 사용자 권한 관리가 가능한 did 생성 방법 및 이를 이용한 사용자 권한 관리 시스템
CN114793243A (zh) 自包含格式的一次性使用授权码
US20140013409A1 (en) Single sign on for cloud
TW200833060A (en) Authentication delegation based on re-verification of cryptographic evidence
JP2017535843A (ja) スマートカードによるログオンおよび連携されたフルドメインログオン
WO2013071087A1 (en) Single sign on for cloud
CN107820689A (zh) 将认证密钥分发给应用程序安装
WO2017020452A1 (zh) 认证方法和认证系统
CN102223420A (zh) 一种面向多媒体社交网络的数字内容分发方法
WO2023160632A1 (zh) 针对飞地实例的云服务访问权限设置方法和云管理平台
JP2024538626A5 (zh)
US12531844B2 (en) Computing systems and methods for protecting application programming interfaces with two-factor authentication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14788604

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14788604

Country of ref document: EP

Kind code of ref document: A1