WO2012162952A1 - 凭据认证方法及单点登录服务器 - Google Patents

凭据认证方法及单点登录服务器 Download PDF

Info

Publication number
WO2012162952A1
WO2012162952A1 PCT/CN2011/078543 CN2011078543W WO2012162952A1 WO 2012162952 A1 WO2012162952 A1 WO 2012162952A1 CN 2011078543 W CN2011078543 W CN 2011078543W WO 2012162952 A1 WO2012162952 A1 WO 2012162952A1
Authority
WO
WIPO (PCT)
Prior art keywords
credential
single sign
authentication
user
sso
Prior art date
Application number
PCT/CN2011/078543
Other languages
English (en)
French (fr)
Inventor
朱振宇
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN2011800018226A priority Critical patent/CN103069741A/zh
Priority to PCT/CN2011/078543 priority patent/WO2012162952A1/zh
Publication of WO2012162952A1 publication Critical patent/WO2012162952A1/zh

Links

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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a credential authentication method and a single sign-on server. Background technique
  • SSO Single Sign On
  • the system When the user accesses the unified portal framework, the system will authenticate the system according to the login information provided by the user. If it passes the verification, it should return a certificate (Token) to the user; the user accesses the platform-integrated third-party application system after logging in. When this token is taken, it will be used as the credential for its own authentication. After receiving the request, the third-party application system will send the token to the SSO authentication system for verification, and check the validity of the token. If verified, users can access third-party applications without having to log in again.
  • Token certificate
  • the third-party application system After receiving the request, the third-party application system will send the token to the SSO authentication system for verification, and check the validity of the token. If verified, users can access third-party applications without having to log in again.
  • the SSO server is deployed in a cluster manner.
  • a token is generated in an SSO server, and the user logs in to the SSO server.
  • the third-party application system integrated by the portal is unified, the third-party application system sends the user token to the platform request authentication, and a certain SSO server processes the request. If the request is not in the local memory, the poll is requested through the SOAP. Access other SSO servers, verify that the Token is valid, and finally return the SSO single sign-on authentication result to the application system. In this way, the user may have multiple SOAP authentication requests for one SSO single sign-on authentication.
  • the system is inefficient and becomes a system bottleneck, and the user experience is poor.
  • the embodiment of the invention provides a credential authentication method and a single sign-on server, which can reduce single sign-on Token verification time.
  • the embodiment of the invention provides a credential authentication method, including:
  • the service system sends a single sign-on authentication response, and the single sign-on authentication response includes the credential authentication result.
  • the embodiment of the invention further provides a single sign-on server, including:
  • a receiving module configured to receive a single sign-on authentication request sent by the service system, where the single sign-on authentication request carries a credential
  • the determining module is configured to determine whether the credential is saved in the shared memory pool. If the credential is saved in the shared memory pool, the credential authentication succeeds. If the credential is not saved in the shared memory pool, the authentication fails.
  • a sending module configured to send, to the service system, a single sign-on authentication response according to the credential authentication result, where the single sign-on authentication response includes the credential authentication result.
  • the service system authenticates the Token to the SSO server
  • the SSO server since the Token is stored in the shared memory pool, the SSO server directly judges whether the Token already exists from the shared memory pool, and does not need to go to other SSO servers.
  • the query saves the Token, so it can reduce the verification time of SSO and improve the efficiency of SSO verification.
  • FIG. 1 is a flowchart of a Token authentication method according to an embodiment of the present invention.
  • FIG. 2 is a signaling flowchart of a Token creation method according to an embodiment of the present invention
  • FIG. 3 is a signaling flowchart of a Token authentication method according to another embodiment of the present invention
  • 4 is a structural diagram of a single sign-on server according to an embodiment of the present invention
  • FIG. 5 is a structural diagram of a single sign-on server according to another embodiment of the present invention.
  • FIG. 1 is a flowchart of a method for credential authentication provided by an embodiment of the present invention.
  • the embodiment describes a process flow of an SSO server, and the embodiment includes:
  • the user identity Before receiving the single sign-on authentication request sent by the service system, the user identity needs to be authenticated. After the user identity authentication succeeds, the user credential is generated, and the user credential is saved in the memory sharing pool.
  • the user identity Before receiving the single sign-on authentication request sent by the service system, the user identity needs to be authenticated, and after the user identity authentication succeeds, a single sign-on object is generated, where the single sign-on object includes the last use time of the credential. And the credential expiration time, the single sign-on is saved in the memory sharing pool.
  • the memory shared pool is composed of memory provided by each single sign-on server of the cluster, and the size of the memory shared pool is fixed or dynamically changed.
  • the method further includes receiving a single sign-on heartbeat message sent by the service system, where the single sign-on heartbeat message includes a timestamp of the last used credential; and updating the last use time of the credential according to the timestamp of the last used credential . And if the difference between the current time and the last time of the credential is greater than the credential expiration time, the token and the single sign-on object in the shared memory pool are deleted.
  • the SSO server when the service system authenticates the Token to the SSO server, since the Token is stored in the shared memory pool, the SSO server directly determines whether the Token already exists from the shared memory pool, and does not need to go to other SSO servers. The query saves the Token, so it can reduce the verification time of single sign-on and improve the efficiency of SSO verification.
  • FIG. 2 is a signaling flow diagram of a Token creation method for single sign-on according to an embodiment of the present invention.
  • the embodiment includes:
  • the ordinary user sends a login request to the SSO server through the terminal to log in.
  • the login request contains the username and password.
  • the SSO module of the SSO server receives the login request, and sends the username and password to the operation processing module of the SSO server to request password authentication.
  • the operation processing module of the SSO server After receiving the username and password, the operation processing module of the SSO server performs identity authentication, and returns an authentication result to the SSO module.
  • the authentication result includes the identifier of the authentication failure. If the authentication succeeds, the authentication result includes the basic attributes of the user, the organizational structure of the user, and the user role.
  • a list of user permissions may include: the user's name, the user's gender, the user's age, the user's account balance, and the user's account credits.
  • the organization structure of the user is an individual user. If the user belongs to the enterprise user, the organizational structure of the user may include: the enterprise to which the user belongs and the specific department information of the enterprise to which the user belongs.
  • the user role indicates the role the user is in the system, such as: normal user, administrator, and so on.
  • the user's permission list can contain a list of services that the user can access.
  • the user's basic attributes, the organization structure of the user, the user role, and the user's permission list may not be included in the authentication result, and may be sent to the SSO module as a separate message.
  • the SSO module receives the authentication result returned by the user, and generates a Token according to the authentication result. After the SSO module receives the authentication result, if the authentication is successful, the SSO module is based on the authentication success identifier and the basic attributes of the user, the organizational structure of the user, the user role, and the user's permission column.
  • the table generates the token Token and SSO objects of the user single sign-on.
  • the SSO object encapsulates the basic attributes of the user, the organizational structure of the user, the user role, and the user's permission list, and saves the Token and SSO objects in the form of key-value pairs. In a shared memory pool.
  • the attributes contained in the SSO object include: basic user information, the organization to which the user belongs, the user role, the user's permission list, the last token usage time, and the Token expiration time.
  • the last time the Token is used indicates the time when the Token was last used.
  • the Token generation time can also be the last time the Token was used.
  • the Token expiration time indicates how long the Token will expire after it was used. For example: Token's expiration time is 15 minutes, which means that after the last use of Token, if the Token is not used within 15 minutes, the Token will automatically expire and cannot be used.
  • multiple SSO servers are deployed in a cluster, and a shared memory pool is established for multiple SSO servers to save user credential tokens and corresponding SSO objects. That is to say, each SSO server provides a part of the memory, so that the memory provided by all the SSO servers of the entire cluster constitutes a shared memory pool, and the shared memory pool can be implemented by using open source cache middleware, such as Jbosscache, oscache, memcache, etc.
  • the shared memory pool can be used to serially connect the shared memory pool through the JBosscache middleware.
  • the SSO module saves the Token and SSO objects in a shared memory pool in the form of key-value pairs.
  • the Token and SSO objects stored in the shared memory pool can realize all the Token and SSO objects in the cluster.
  • the SSO server is synchronized.
  • the SSO server modifies the expiration period in the SSO object attribute of the shared memory pool, thus realizing the simultaneous update of all SSO servers in the cluster for Token and SSO objects.
  • the SSO server deletes the shared memory pool Token and SSO objects, thus realizing the simultaneous deletion of Token and SSO objects in all SSO servers in the cluster.
  • the size of the shared memory pool can be fixed. For example: Each SSO server provides a fixed size of 10M memory. If there are 10 SSO servers in the cluster's SSO server, then the shared memory pool is 100M. The shared memory pool size is stable. The size of the shared memory pool can vary dynamically, for example: Each SSO server provides 10% of its memory as a shared memory pool. In some cases, if the amount of data of the Token at this time is too large, and the size of the existing shared memory pool is insufficient, and the size of the shared memory pool needs to be increased, each SSO server in the clustered SSO server provides its total memory. 15% of the shared memory pool is dynamically changed. Of course, in order not to affect the performance of the SSO server itself, the proportion of its dynamically floating memory can be set to an upper limit, for example, the size of the shared memory pool is limited to 20% of the SSO server's memory.
  • the S SO module After generating the Token, the S SO module sends a jump request to the website, where the jump request includes the SSO object.
  • the website interface After receiving the jump request, the website interface sends a personal content request to the personal attribute module according to the SSO object.
  • the website interface requests the personal attribute module to comply with the content involved in the personal right of the user according to the permission list of the user of the SSO object, that is, requests the task that the user needs to be processed.
  • the personal attribute module returns personal content to the website interface.
  • the website interface After receiving the jump request, the website interface sends a public content request to the public attribute module.
  • the website interface queries the public attribute module for public content, website messages, schedule reminders and other public content by requesting the public content.
  • the personal attribute module returns public content to the website interface.
  • the website interface forms a final web page according to the received personal content and public content of the user, and displays to the end user. Total content.
  • the SSO module After the SSO module generates the Token, it is saved in the shared memory pool. Since the shared memory pool is composed of the SSO servers in the cluster, the SSO server is composed of the SSO servers. You can know the user's Token.
  • FIG. 3 is a signaling flowchart of a Token authentication method for single sign-on according to an embodiment of the present invention.
  • the embodiment includes: 301. After a normal user logs in to the website, he can click on the third-party service linked in the website.
  • the website sends an access request carrying a Token to the third-party service system.
  • the third-party service system After receiving the access request, the third-party service system sends an SSO authentication request to the SSO server, where the SSO authentication request carries a Token.
  • the SSO server receives the SSO authentication request, queries the local shared memory pool according to the user token, determines whether the user token is valid, and returns an SSO authentication response to the third-party service system.
  • the SSO server If the token is valid, that is, before the expiration time of the token expires, the SSO server returns a successful SSO authentication response to the third-party service system. If the Token is invalid, that is, after the Token's expiration time has not expired, the SSO server returns the SSO authentication response for the authentication failure to the third-party service system.
  • each SSO server can be considered to keep the Token and SSO objects synchronously, so the SSO server receiving the SSO authentication request only needs to query the Token in the shared memory pool instead of The Tokeri needs to be queried to other SSO servers.
  • the SSO server can obtain the operation authority and the available data of the user, and send the data to the third-party service system through the SSO authentication response, where the SSO authentication response includes the operation authority and the available operation that the user can use.
  • the data includes the operation authority and the available operation that the user can use.
  • the third-party service system forms a final webpage page according to the received user operation authority and data authority, and displays an operation interface after the user logs in to the end user, and completes the SSO single sign-on.
  • the third-party service system sends an SSO heartbeat message to the SSO server during the interaction with the SSO server, where the SSO heartbeat message includes the timestamp of the last use of the Token.
  • the third-party service system can cache the Token of the user during the interaction between the SSO server, and if the third-party service system uses the Token, the third-time service system refreshes the timestamp of the last use of the Token.
  • the third-party service system may send an SSO heartbeat message to the SS0 server after each refresh of the last time of the Toke, or may periodically send an SSO heartbeat message to the SSO server. 307. After receiving the SSO heartbeat message, the SSO server refreshes the life cycle of the Token according to the SSO heartbeat message.
  • the SSO server After receiving the SSO heartbeat message, the SSO server updates the token's last usage time.
  • the SSO server needs to destroy the Token and the corresponding SSO object; for example, the last time the token is used is 10 o'clock, the expiration time of the Token is 15 minutes, if the current time is 10:16 , the SSO server needs to destroy the Token and the corresponding S SO object.
  • the third-party service system authenticates the Token to the SSO server
  • the shared SVM server forms a shared memory pool
  • the Token and SSO objects are also stored in the shared memory pool
  • the SSO server directly from the shared memory.
  • the pool determines whether the Token already exists, and does not need to query other SSO servers to save the Token. Therefore, the verification time of the single sign-on can be reduced, and the SSO verification efficiency is improved.
  • FIG. 4 is a diagram showing the structure of an SSO server according to an embodiment of the present invention, including:
  • the receiving module 401 is configured to receive a single sign-on authentication request sent by the service system, where the single-point login authentication request carries the credential;
  • the determining module 402 is configured to determine whether the credential is saved in the shared memory pool. If the credential is saved in the shared memory pool, the credential authentication succeeds. If the credential is not saved in the shared memory pool, the credential authentication fails.
  • the sending module 403 is configured to send a single sign-on authentication response to the service system according to the credential authentication result, where the single sign-on authentication response includes the credential authentication result.
  • the SSO server further includes: a generating module 404, configured to generate user credentials after the user's identity authentication succeeds, and save the user credentials in the In the memory sharing pool, the generating module 404 is further configured to generate a single sign-on object after the user's identity authentication succeeds, and the single sign-on object includes the last use time of the credential and the credential expiration time, and the single sign-on is saved in the memory sharing. In the pool.
  • the receiving module 401 is further configured to receive a single sign-on heartbeat message sent by the service system, where the single sign-on heartbeat message includes a timestamp of the last used credential; the SSO server further includes an update module 405, configured to use the credential according to the last time. Timestamp, the last time the credential was used.
  • the SSO server further includes: a deletion module 406, configured to delete the user credentials and the single sign-on object in the shared memory pool if the difference between the current time and the last time of the credential is greater than the credential expiration time.
  • a deletion module 406 configured to delete the user credentials and the single sign-on object in the shared memory pool if the difference between the current time and the last time of the credential is greater than the credential expiration time.
  • the SSO server when the service system authenticates the Token to the SSO server, since the Token is stored in the shared memory pool, the SSO server directly determines whether the Token already exists from the shared memory pool, and does not need to go to other SSO servers. The query saves the Token, so it can reduce the verification time of single sign-on and improve the efficiency of SSO verification.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM: Read Random Memory), or a random access memory (RAM).
  • ROM Read Random Memory
  • RAM random access memory

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

本发明涉及通信技术领域，公开了凭据认证方法和SSO服务器，包括：接收到业务***发送的单点登录认证请求，所述单点登录认证请求携带凭据；判断共享内存池中是否保存所述凭据，如果共享内存池中保存所述凭据，则凭据认证成功，如果共享内存池中没有保存所述凭据，则凭据认证失败；根据凭据认证结果，向所述业务***发送单点登录认证响应，所述单点登录认证响应包含了所述凭据认证结果。使用本发明，可以减少SSO的验证时间，提高了SSO验证效率。

Description

凭据认证方法及单点登录服务器 技术领域
本发明涉及通信技术领域， 具体涉及凭据认证方法及单点登录服务器。 背景技术
在计算机信息化***集成中， 多个应用***集成在一起时， 为了给最终客 户提供良好的感知， 无缝的融合， 通常需要提供统一的门户框架及业务支撑平 台， 实现单点登录（ Single Sign On, SSO )。 SSO表示在多个应用***中， 用 户只需要登录一次就可以访问所有相互信任的应用***。它包括可以将这次主 要的登录映射到其他应用中用于同一个用户的登录的机制，即用户只需登录一 次即可使用权限范围内的各类业务， 无需多次登录鉴权。
当用户访问统一门户框架时， ***会根据用户提供的登录信息，认证*** 进行身份效验， 如果通过效验， 应该返回给用户一个认证的凭据（Token ); 用 户登录后访问平台集成的第三方应用***时， 就会将这个 Token带上，作为自 己认证的凭据， 第三方应用***接受到请求之后会把 Token送到 SSO认证系 统进行效验， 检查 Token的合法性。 如果通过效验， 用户就可以在不用再次登 录的情况下访问第三方应用***。
现有技术方案中， SSO服务器采用集群方式进行部署的， 当有多台 SSO 服务器集群部署时， 用户登录统一门户网站后， 会在某台 SSO服务器中生成 Token, 当用户通过单点登录到该统一门户网站集成的第三方应用***时， 第 三方应用***会将用户 Token发送到平台请求鉴权， 随机某台 SSO服务器处 理该请求， 如果在本地内存中没有该请求， 则通过 SOAP请求轮询访问其他 SSO服务器， 验证 Token是否有效， 最后返回 SSO单点登录鉴权结果给应用 ***。 这样用户一次 SSO单点登录鉴权， 可能会有多次 SOAP鉴权请求， 系 统效率低， 并成为***瓶颈， 用户体验差。
发明内容
本发明实施例提供了凭据认证方法及单点登录服务器，可以减少单点登录 的 Token验证时间。
本发明实施例提供了一种凭据认证方法， 包括：
接收到业务***发送的单点登录认证请求，所述单点登录认证请求携带凭 据；
判断共享内存池中是否保存所述凭据， 如果共享内存池中保存所述凭据， 则凭据认证成功， 如果共享内存池中没有保存所述凭据， 则凭据认证失败； 根据凭据认证结果， 向所述业务***发送单点登录认证响应， 所述单点登 录认证响应包含了所述凭据认证结果。
本发明实施例还提供了一种单点登录服务器， 包括：
接收模块， 用于接收到业务***发送的单点登录认证请求， 所述单点登录 认证请求携带凭据；
判断模块， 用于判断共享内存池中是否保存所述凭据，如果共享内存池中 保存所述凭据， 则凭据认证成功， 如果共享内存池中没有保存所述凭据， 则凭 据认证失败；
发送模块， 用于根据凭据认证结果， 向所述业务***发送单点登录认证响 应， 所述单点登录认证响应包含了所述凭据认证结果。
从上可知， 业务***向 SSO服务器进行认证 Token时， 由于 Token保 存在共享内存池中， SSO服务器就直接从共享内存池中进行判断是否已经 存在了 Token 了， 而不需要再向其它 SSO 服务器进行查询是否保存了 Token, 因此可以减少 SSO的验证时间， 提高了 SSO验证效率。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所 需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明 的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提 下， 还可以根据这些附图获得其他的附图。
图 1为本发明一个实施例提供的 Token认证方法的流程图；
图 2为本发明一个实施例提供的 Token创建方法的信令流程图； 图 3为本发明另一个实施例提供的 Token认证方法的信令流程图； 图 4为本发明一个实施例提供的单点登录服务器的结构图；
图 5为本发明另一个实施例提供的单点登录服务器的结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
先介绍本发明实施例提供的凭据认证方法，图 1描述了本发明一个实施例 提供的凭据认证方法的流程图， 该实施例描述的是 SSO服务器的处理流程， 该实施例包括：
101、 接收到业务***发送的单点登录认证请求， 该单点登录认证请求携 带凭据。
其中，在接收到业务***发送的单点登录认证请求之前， 需要对用户身份 进行认证， 在用户的身份认证成功后， 生成所述用户凭据， 并将所述用户凭据 保存在内存共享池中。
其中，在接收到业务***发送的单点登录认证请求之前， 需要对用户身份 进行认证， 在用户的身份认证成功后， 生成单点登录对象， 所述单点登录对象 包含了凭据最后一次使用时间和凭据失效时间，所述单点登录保存在内存共享 池中。
102、判断共享内存池中是否保存该凭据，如果共享内存池中保存该凭据， 则凭据认证成功， 如果共享内存池中没有保存该凭据， 则凭据认证失败。
其中， 内存共享池由集群的各个单点登录服务器分别提供的内存所组成， 所述内存共享池大小是固定的或者是动态变化的。
103、 根据凭据认证结果， 向业务***发送单点登录认证响应， 单点登录 认证响应包含了凭据认证结果。
其中， 方法还包括接收所述业务***发送的单点登录心跳消息， 单点登录 心跳消息包含了最后一次使用凭据的时间戳；根据所述最后一次使用凭据的时 间戳， 更新凭据最后一次使用时间。 并且如果当前时间与凭据最后一次时间的差值大于凭据失效时间，则删除 共享内存池中所述 Token及单点登录对象。
从上可知， 业务***向 SSO服务器进行认证 Token时， 由于 Token保 存在共享内存池中， SSO服务器就直接从共享内存池中进行确定是否已经 存在了 Token 了， 而不需要再向其它 SSO 服务器进行查询是否保存了 Token, 因此可以减少单点登录的验证时间， 提高了 SSO验证效率。
图 2描述了本发明一个实施例提供的单点登录的 Token创建方法的信令流 程图， 该实施例包括：
201、 普通用户通过终端向 SSO服务器发送登录请求， 进行登录。 该登录 请求包含了用户名和密码。
202、 SSO服务器的 SSO模块接收了登录请求， 将用户名和密码发送给 SSO服务器的操作处理模块请求进行密码身份认证。
203、 SSO服务器的操作处理模块接收该用户名和密码后，进行身份认证， 并向 SSO模块返回认证结果。
其中， 如果身份认证失败， 则认证结果中包含了认证失败的标识； 如果身 份认证成功， 则认证结果除了包含认证成功的标识外，还可以包括用户的基本 属性、 用户所属组织结构、 用户角色以及用户的权限列表。 其中， 用户的基本 属性可以包含： 用户的姓名， 用户的性别， 用户的年龄， 用户的账户余额， 用 户的账户积分等信息。如果该用户为个人用户， 用户所属组织结构就是个人用 户， 如果该用户属于企业用户， 则用户所属组织结构可以包括： 用户所属企业 以及用户所属该企业的具体部门信息。用户角色表示该用户在***中所处于的 角色， 比如： 普通用户， 管理员等。 用户的权限列表可以包含了用户可以访问 的业务列表。
当然， 用户的基本属性、 用户所属组织结构、 用户角色以及用户的权限列 表还可以不用包含在认证结果中，可以单独的作为一个消息发送给 SSO模块。
204、 SSO模块接收了用户返回的认证结果， 并根据认证结果生成 Token。 SSO模块在接收了认证结果后， 如果认证成功的话， SSO模块根据认证 成功标识和用户的基本属性、用户所属组织结构、用户角色以及用户的权限列 表， 生成用户单点登录的凭据 Token及 SSO对象， SSO对象封装了用户的基 本属性、 用户所属组织结构、 用户角色以及用户的权限列表， 并将 Token及 SSO对象以键值对的形式保存到共享内存池中。
其中， SSO对象包含的属性包括了： 用户基本信息、 用户所属组织机构、 用户角色、 用户的权限列表、 Token最后一次使用时间、 Token失效时间。 其 中 Token最后一次使用时间表示 Token被最后一次使用的时间， Token生成的 时间也可以是 Token最后一次使用的时间， Token失效时间表示为 Token在从 前一次被使用后多长时间内会失效。 例如： Token的失效时间为 15分钟， 就 表示从最后一次使用 Token后， 如果 15分钟内， 该 Token—直没有被使用， 则该 Token将自动失效， 不能被使用了。
在本发明实施例中，多台 SSO服务器是进行集群部署的，通过对多台 SSO 服务器建立共享内存池， 用来保存用户凭据 Token及对应的 SSO对象。 也就 是说， 每个 SSO服务器都提供一部分的内存， 从而将整个集群的所有 SSO服 务器提供的内存组成一个共享内存池， 共享内存池可以使用开源的 cache中间 件实现， 如 Jbosscache, oscache, memcache等， 例如： 本发明实施例可以利 用共享内存池是通过 Jbosscache中间件来串接共享内存池。
当用户 Token创建时， SSO模块将 Token及 SSO对象以键值对形式保存 在共享内存池中， 这样保存在共享内存池中的 Token及 SSO对象， 就能够实 现 Token及 SSO对象在集群中的所有 SSO服务器都实现了同步。
当 Token有效期刷新时， SSO服务器会修改共享内存池的 SSO对象属性 中失效期， 这样就实现了 Token及 SSO对象在集群中的所有 SSO服务器同步 更新。
当 Token销毁时， SSO服务器会删除共享内存池 Token及 SSO对象， 这 样就实现了 Token及 SSO对象在集群中的所有 SSO服务器同步删除。
共享内存池的大小可以固定， 比如： 每个 SSO服务器都提供了固定大小 的 10M的内存， 如果集群的 SSO服务器中有 10个 SSO服务器， 那么共享内 存池的就是 100M， 这个共享内存池大小是固定的。 共享内存池的大小可以动 态变化的， 比如： 每个 SSO服务器都提供了其内存的 10%作为共享内存池的 一部分，如果此时的 Token的数据量过大时，现有的共享内存池的大小不够时， 需要提高共享内存池的大小， 则将集群的 SSO服务器中每个 SSO服务器都提 供了其总内存的 15%作为共享内存池的一部分，此时共享内存池大小是动态变 化的。 当然为了不影响 SSO服务器本身的性能， 其动态浮动的内存的比例可 以设置一个上限， 比如提供给共享内存池的大小最大限制到 SSO服务器的内 存的 20%。
205、 S SO模块生成 Token后， 向网站发送跳转请求， 该跳转请求包含了 SSO对象。
206、 网站接口接收了跳转请求后， 根据 SSO对象向个人属性模块发送个 人内容请求。
网站接口根据 SSO对象的用户的权限列表， 向个人属性模块请求符合该 用户个人权限中涉及到的内容， 也就是说请求了该用户需要待处理的任务。
207、 个人属性模块向网站接口返回了个人内容。
208、 网站接口接收了跳转请求后， 向公共属性模块发送公共内容请求。 网站接口通过向公共内容请求， 向公共属性模块查询网站的公共消息， 站 内消息， 日程提醒等公共内容。
209、 个人属性模块向网站接口返回了公共内容。
210、 网站接口根据了接收的该用户的个人内容和公共内容， 形成最终网 页页面， 并向最终用户进行展示。 共内容。
其中， 205-206和 207-208没有先后顺序关系的。
从上可知， SSO模块生成了 Token后， 将其保存在共享内存池中， 由于共 享内存池是由集群里的各个 SSO服务器都提供部分内存而共同组成的， 因此 在对于集群的各个 SSO服务器都可以获知用户的 Token了。
图 3描述了本发明一个实施例提供的单点登录的 Token认证方法的信令流 程图， 该实施例包括： 301、 普通用户登录网站后， 可以点击网站中链接的第三方业务。
302、 网站向第三方业务***发送携带 Token的访问请求。
303、 第三方业务***接收到访问请求后， 向 SSO服务器发送 SSO认证 请求， 该 SSO认证请求中携带了 Token。
304、 SSO服务器接收到 SSO认证请求， 根据用户 Token, 查询本地的共 享内存池， 判断该用户 Token是否有效， 并向第三方业务***返回 SSO认证 响应。
其中， 如果 Token的有效时， 即在 Token的失效时间没有到之前， 则 SSO 月良务器向第三方业务***返回认证成功的 SSO认证响应。 如果 Token的无效 时， 即在 Token的失效时间没有到之后， 则 SSO服务器向第三方业务***返 回认证失败的 SSO认证响应。
由于 Token及 SSO对象是保存在共享内存池中， 其各个 SSO服务器均可 以被认为同步保存了该 Token及 SSO对象，因此接收 SSO认证请求的 SSO服 务器只要在共享内存池中进行查询 Token,而不需要向其它 SSO服务器查询该 Tokeri。
如果 Token认证成功后， SSO服务器可以获取该用户对应的操作权限和可 以使用的数据， 并且通过 SSO认证响应发送给第三方业务***， 其中 SSO认 证响应包含了该用户可以使用的操作权限和可以使用的数据。
305、 第三方业务***根据接收的用户操作权限和数据权限， 形成最终网 页页面， 并向最终用户进行展现用户登录后的操作界面， 完成 SSO单点登录。
306、 第三方业务***在与 SSO服务器进行交互过程中， 向 SSO服务 器发送 SSO心跳消息，该 SSO心跳消息包含了 Token最后一次使用的时间 戳。
第三方业务***在 SSO 服务器进行交互过程中， 可以緩存该用户的 Token, 并且如果第三方业务***使用 Token的话， 则在第三方业务***刷 新该 Token最后一次使用的时间戳。
第三方业务***可以在每次刷新 To ke n最后一次使用的时间后，向 S S 0 服务器发送 SSO心跳消息，也可以定时向 SSO服务器发送 SSO心跳消息。 307、 SSO服务器在接收了 SSO心跳消息后， 根据 SSO心跳消息刷新 该 Token的生命周期
SSO服务器在接收到 SSO心跳消息后， 对该 Token最后一次使用时间 进行更新。
如果 Token的生命周期结束时， 则 SSO服务器需要销毁该 Token及对 应的 SSO对象； 比如该 Token最后一次使用时间为 10点整， 该 Token的 失效时间为 15分钟， 如果当前时间为 10: 16时， 则 SSO服务器需要销毁 该 Token及对应的 S SO对象。
从上可知， 第三方业务***向 SSO服务器进行认证 Token时， 由于集 群的 SSO服务器中形成了一个共享内存池，而 Token及 SSO对象也保存在 共享内存池中， 因此 SSO服务器就直接从共享内存池中进行确定是否已经 存在了 Token 了， 而不需要再向其它 SSO 服务器进行查询是否保存了 Token, 因此可以减少单点登录的验证时间， 提高了 SSO验证效率。
需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都 表述为一系列的动作组合， 但是本领域技术人员应该知悉， 本发明并不受 所描述的动作顺序的限制， 因为依据本发明， 某些步骤可以采用其他顺序 或者同时进行。 其次， 本领域技术人员也应该知悉， 说明书中所描述的实 施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
如下再介绍本发明实施例提供的 SSO服务器， 图 4描述了本发明一个实 施例提供的 SSO服务器的结构， 包括：
接收模块 401， 用于接收到业务***发送的单点登录认证请求， 该单点登 录认证请求携带凭据；
判断模块 402， 用于判断共享内存池中是否保存该凭据， 如果共享内存池 中保存该凭据， 则凭据认证成功， 如果共享内存池中没有保存该凭据， 则凭据 认证失败；
发送模块 403， 用于根据凭据认证结果， 向业务***发送单点登录认证响 应， 单点登录认证响应包含了凭据认证结果。
在本发明的另一个实施例中， 如图 5所示， SSO服务器还包括： 生成模块 404， 用于在用户的身份认证成功后， 生成用户凭据， 并将该用户凭据保存在 内存共享池中； 该生成模块 404: 还用于在用户的身份认证成功后， 生成单点 登录对象， 单点登录对象包含了凭据最后一次使用时间和凭据失效时间，单点 登录保存在内存共享池中。
接收模块 401， 还用于接收业务***发送的单点登录心跳消息， 单点登录 心跳消息包含了最后一次使用凭据的时间戳； 此时 SSO服务器还包括更新模 块 405， 用于根据最后一次使用凭据的时间戳， 更新凭据最后一次使用时间。
SSO服务器还包括： 删除模块 406， 用于如果当前时间与凭据最后一次时 间的差值大于凭据失效时间， 删除共享内存池中用户凭据及单点登录对象。
从上可知， 业务***向 SSO服务器进行认证 Token时， 由于 Token保 存在共享内存池中， SSO服务器就直接从共享内存池中进行确定是否已经 存在了 Token 了， 而不需要再向其它 SSO 服务器进行查询是否保存了 Token, 因此可以减少单点登录的验证时间， 提高了 SSO验证效率。
上述 SSO服务器内的各模块之间的信息交互、 执行过程等内容， 由于与 本发明方法实施例基于同一构思， 具体内容可参见本发明方法实施例中的叙 述， 此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算 机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。 其中， 上述的存储介质可为磁碟、 光盘、 只读存储记忆体（ROM: Read-Only Memory )或随机存储记忆体 ( RAM: Random Access Memory )等。 例的说明只是用于帮助理解本发明的方法及其思想； 同时，对于本领域的一般 技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处， 综上所述， 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 一种凭据认证方法， 其特征在于， 包括：
接收到业务***发送的单点登录认证请求，所述单点登录认证请求携带凭 据；
判断共享内存池中是否保存所述凭据， 如果共享内存池中保存所述凭据， 则凭据认证成功， 如果共享内存池中没有保存所述凭据， 则凭据认证失败； 根据凭据认证结果， 向所述业务***发送单点登录认证响应， 所述单点登 录认证响应包含了所述凭据认证结果。
2、 如权利要求 1所述的凭据认证方法， 其特征在于， 所述内存共享池由 集群的各个单点登录服务器分别提供的内存所组成，所述内存共享池大小是固 定的或者是动态变化的。
3、 如权利要求 1或 2所述的凭据认证方法， 其特征在于， 还包括： 用户 的身份认证成功后， 生成所述用户凭据， 并将所述用户凭据保存在内存共享池 中。
4、 如权利要求 3所述的凭据认证方法， 其特征在于， 还包括： 用户的身 份认证成功后， 生成单点登录对象，所述单点登录对象包含了凭据最后一次使 用时间和凭据失效时间， 所述单点登录保存在内存共享池中。
5、 如权利要求 4所述的凭据认证方法， 其特征在于， 还包括： 接收所述 业务***发送的单点登录心跳消息，所述单点登录心跳消息包含了最后一次使 用凭据的时间戳；
根据所述最后一次使用凭据的时间戳， 更新所述凭据最后一次使用时间。
6、 如权利要求 4或 5所述的凭据认证方法， 其特征在于， 还包括： 如果 当前时间与所述凭据最后一次时间的差值大于所述凭据失效时间，删除共享内 存池中所述 Token及单点登录对象。
7、 一种单点登录服务器， 其特征在于， 包括：
接收模块， 用于接收到业务***发送的单点登录认证请求， 所述单点登录 认证请求携带凭据；
判断模块， 用于判断共享内存池中是否保存所述凭据，如果共享内存池中 保存所述凭据， 则凭据认证成功， 如果共享内存池中没有保存所述凭据， 则凭 据认证失败；
发送模块， 用于根据凭据认证结果， 向所述业务***发送单点登录认证响 应， 所述单点登录认证响应包含了所述凭据认证结果。
8、 如权利要求 7所述的单点登录服务器， 其特征在于， 还包括： 生成模 块， 用于在用户的身份认证成功后， 生成所述用户凭据， 并将所述用户凭据保 存在所述内存共享池中；
所述生成模块： 还用于在用户的身份认证成功后， 生成单点登录对象， 所 述单点登录对象包含了凭据最后一次使用时间和凭据失效时间，所述单点登录 保存在内存共享池中。
9、 如权利要求 8所述的单点登录服务器， 其特征在于， 所述接收模块， 还用于接收所述业务***发送的单点登录心跳消息，所述单点登录心跳消息包 含了最后一次使用凭据的时间戳；
所述单点登录服务器还包括：
更新模块， 用于根据所述最后一次使用凭据的时间戳， 更新所述凭据最后 一次使用时间。
10、 如权利要求 8或 9所述的单点登录服务器， 其特征在于， 还包括： 删 除模块，用于如果当前时间与所述凭据最后一次时间的差值大于所述凭据失效 时间， 删除共享内存池中所述用户凭据及单点登录对象。
PCT/CN2011/078543 2011-08-17 2011-08-17 凭据认证方法及单点登录服务器 WO2012162952A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN2011800018226A CN103069741A (zh) 2011-08-17 2011-08-17 凭据认证方法及单点登录服务器
PCT/CN2011/078543 WO2012162952A1 (zh) 2011-08-17 2011-08-17 凭据认证方法及单点登录服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/078543 WO2012162952A1 (zh) 2011-08-17 2011-08-17 凭据认证方法及单点登录服务器

Publications (1)

Publication Number Publication Date
WO2012162952A1 true WO2012162952A1 (zh) 2012-12-06

Family

ID=47258298

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/078543 WO2012162952A1 (zh) 2011-08-17 2011-08-17 凭据认证方法及单点登录服务器

Country Status (2)

Country Link
CN (1) CN103069741A (zh)
WO (1) WO2012162952A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103501344B (zh) * 2013-10-10 2017-08-01 瑞典爱立信有限公司 多应用实现单点登录的方法及***
CN108833378A (zh) * 2018-05-31 2018-11-16 上海康斐信息技术有限公司 一种多帐号登陆的处理方法及***
CN109857344B (zh) * 2019-01-30 2022-05-20 平安科技（深圳）有限公司 基于共享内存的心跳状态判断方法、装置和计算机设备
CN114006751B (zh) * 2021-10-29 2024-06-11 广东宜教通教育有限公司 一种使用临时认证码的校园***单点登录方法
CN116865982A (zh) * 2022-03-22 2023-10-10 西安即刻易用网络科技有限公司 一种应用管理平台及登录认证方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015490A1 (en) * 2003-07-16 2005-01-20 Saare John E. System and method for single-sign-on access to a resource via a portal server
CN101159557A (zh) * 2007-11-21 2008-04-09 华为技术有限公司 单点登录的方法、装置及***
CN101207482A (zh) * 2007-12-13 2008-06-25 深圳市戴文科技有限公司 一种实现单点登录的方法及***
CN101764806A (zh) * 2009-12-31 2010-06-30 卓望数码技术（深圳）有限公司 一种单点登录方法、***以及登录服务平台

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101355527A (zh) * 2008-08-15 2009-01-28 深圳市中兴移动通信有限公司 一种跨域名单点登录的实现方法
CN101360107A (zh) * 2008-09-19 2009-02-04 腾讯科技（深圳）有限公司 一种提高单次登录***安全的方法、***及装置
US8151333B2 (en) * 2008-11-24 2012-04-03 Microsoft Corporation Distributed single sign on technologies including privacy protection and proactive updating
CN101699893B (zh) * 2009-11-10 2012-09-05 广州杰赛科技股份有限公司 认证服务器集群的鉴别服务实体ase状态的更改方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015490A1 (en) * 2003-07-16 2005-01-20 Saare John E. System and method for single-sign-on access to a resource via a portal server
CN101159557A (zh) * 2007-11-21 2008-04-09 华为技术有限公司 单点登录的方法、装置及***
CN101207482A (zh) * 2007-12-13 2008-06-25 深圳市戴文科技有限公司 一种实现单点登录的方法及***
CN101764806A (zh) * 2009-12-31 2010-06-30 卓望数码技术（深圳）有限公司 一种单点登录方法、***以及登录服务平台

Also Published As

Publication number Publication date
CN103069741A (zh) 2013-04-24

Similar Documents

Publication Publication Date Title
US20220191188A1 (en) Single sign-on enabled oauth token
US11588806B2 (en) Authentication service
US11601414B2 (en) Contact consolidation across multiple services
US9306939B2 (en) Authorization token cache system and method
US10819701B2 (en) Autonomous secrets management for a managed service identity
O’Malley et al. Hadoop security design
JP6096200B2 (ja) モバイルアプリケーション、シングルサインオン管理
US8627409B2 (en) Framework for automated dissemination of security metadata for distributed trust establishment
WO2015090116A1 (zh) 一种登录方法和桌面管理设备
US9584615B2 (en) Redirecting access requests to an authorized server system for a cloud service
US10778603B2 (en) Systems and methods for controlling access to broker resources
US10691790B2 (en) Autonomous secrets management for a temporary shared access signature service
WO2022121461A1 (zh) 一种云平台资源访问控制的令牌构造方法、装置及设备
US8370914B2 (en) Transition from WS-Federation passive profile to active profile
US8898318B2 (en) Distributed services authorization management
US11930001B2 (en) Polling service
CN102739658A (zh) 一种单点登录的离线验证方法
US9635024B2 (en) Methods for facilitating improved user authentication using persistent data and devices thereof
US20220360575A1 (en) Security for diverse computing systems
JP2013140480A (ja) サーバシステム、サービス提供サーバおよび制御方法
WO2012162952A1 (zh) 凭据认证方法及单点登录服务器
CN105049427A (zh) 应用***登录账号的管理方法及装置
WO2023024057A1 (zh) 跨域授权处理方法及跨域调用处理方法
Mestre et al. Securing RESTful Web Services using Multiple JSON Web Tokens
WO2023104117A1 (zh) 资源访问方法、***、电子设备和计算机可读存储介质

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180001822.6

Country of ref document: CN

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

Ref document number: 11866475

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: 11866475

Country of ref document: EP

Kind code of ref document: A1