CN113821784A - 多系统单点登录方法、装置及计算机可读存储介质 - Google Patents

多系统单点登录方法、装置及计算机可读存储介质 Download PDF

Info

Publication number
CN113821784A
CN113821784A CN202111190504.0A CN202111190504A CN113821784A CN 113821784 A CN113821784 A CN 113821784A CN 202111190504 A CN202111190504 A CN 202111190504A CN 113821784 A CN113821784 A CN 113821784A
Authority
CN
China
Prior art keywords
authentication
application system
application
cookie
user
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.)
Pending
Application number
CN202111190504.0A
Other languages
English (en)
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.)
Dingdao Zhilian Beijing Technology Co ltd
Original Assignee
Dingdao Zhilian Beijing 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 Dingdao Zhilian Beijing Technology Co ltd filed Critical Dingdao Zhilian Beijing Technology Co ltd
Priority to CN202111190504.0A priority Critical patent/CN113821784A/zh
Publication of CN113821784A publication Critical patent/CN113821784A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/101Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • G06F21/1014Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to tokens

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种多系统单点登录方法、装置及计算机可读存储介质,包括:在接收到针对第一应用系统的第一访问请求时,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接;获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,将cookie‑auth发送至第一应用系统,以使第一应用系统将cookie‑auth再次发送至认证系统;若认证系统确定cookie‑auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。该方案不限定相互信任的应用系统的认证机制,可以实现多个应用系统的跨域。

Description

多系统单点登录方法、装置及计算机可读存储介质
技术领域
本申请涉及计算机技术领域,具体而言,本申请涉及一种多系统单点登录方法、装置及计算机可读存储介质。
背景技术
HTTP(Hyper Text Transfer Protocol,超文本传输协议)是无状态(Stateless)的协议:HTTP对于事务处理没有记忆能力,不对请求和响应之间的通信状态进行保存。为了能够记录用户的登录状态,早期使用了Cookie-Session(Cookie会话)的认证机制,后来又衍生了基于Token(令牌)的认证机制。
随着企业的发展,用到的应用系统会越来越多,运营人员在操作不同的应用系统时,需要进行多次登录操作,而且每个系统的账号都不一样,这对于运营人员来说,很不方便。所以需要实现多个应用系统的单点登录功能,即在多个应用系统中,只需要登录一个应用系统,就可以访问其他相互信任的应用系统。
目前的单点登录方案大多基于Cookie-Session认证机制实现,该方案能够很好的适用于多个都是基于Cookie-Session认证机制的应用系统,但无法适用于多个基于其他认证机制的应用系统,因此有必要提出一种新的单点登录方案。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一,本申请实施例所提供的技术方案如下:
第一方面,本申请实施例提供了一种多系统单点登录方法,包括:
在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统;
重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统;
若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
在本申请的一种可选实施例中,在接收用户发出的针对第一应用系统的访问请求之前,方法还包括:
接收用户发出的针对第二应用系统的登录请求,登录请求包括登录信息;
存储第二链接,并将登录信息发送至认证系统,以使认证系统对登录信息的有效性进行验证;
若认证系统确定登录信息有效,则接收第二应用系统发送的第二认证凭证并存储。
在本申请的一种可选实施例中,若第二应用系统为基于Cookie-Session认证机制的应用系统,则认证系统确定第二认证凭证有效,包括:
认证系统将第二认证凭证发送至第二应用系统,若第二应用系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,若第二应用系统为基于Token认证机制的应用系统,则认证系统确定第二认证凭证有效,包括:
若认证系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,若第一应用系统为基于Cookie-Session认证机制的应用系统,则第一认证凭证为第一应用系统在接收到认证系统发送的cookie-auth有效的反馈消息后,生成的Cookie。
在本申请的一种可选实施例中,方法还包括:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Cookie发送至第一应用系统;
若第一应用系统确定Cookie有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
在本申请的一种可选实施例中,若第一应用系统为基于Token认证机制的应用系统,则第一认证凭证为从认证系统接收到的认证系统在确定cookie-auth有效后,生成的Token。
在本申请的一种可选实施例中,方法还包括:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Token发送至第一应用系统,以使第一应用系统将Token发送至认证系统;
若认证系统确定Token有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
第二方面,本申请实施例提供了一种多系统单点登录装置,包括:
代理链接获取模块,用于在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统;
代理认证模块,用于重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统;
登录和访问模块,用于若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
在本申请的一种可选实施例中,该装置可以包括第二应用系统登录模块,用于在接收用户发出的针对第一应用系统的访问请求之前,接收用户发出的针对第二应用系统的登录请求,登录请求包括登录信息;
存储第二链接,并将登录信息发送至认证系统,以使认证系统对登录信息的有效性进行验证;
若认证系统确定登录信息有效,则接收第二应用系统发送的第二认证凭证并存储。
在本申请的一种可选实施例中,代理认证模块具体用于:
若第二应用系统为基于Cookie-Session认证机制的应用系统,认证系统将第二认证凭证发送至第二应用系统,若第二应用系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,代理认证模块具体用于:
若第二应用系统为基于Token认证机制的应用系统,若认证系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,若第一应用系统为基于Cookie-Session认证机制的应用系统,则第一认证凭证为第一应用系统在接收到认证系统发送的cookie-auth有效的反馈消息后,生成的Cookie。
在本申请的一种可选实施例中,该装置还可以包括第二访问模块,用于:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Cookie发送至第一应用系统;
若第一应用系统确定Cookie有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
在本申请的一种可选实施例中,若第一应用系统为基于Token认证机制的应用系统,则第一认证凭证为从认证系统接收到的认证系统在确定cookie-auth有效后,生成的Token。
在本申请的一种可选实施例中,该装置还可以包括第二访问模块,用于:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Token发送至第一应用系统,以使第一应用系统将Token发送至认证系统;
若认证系统确定Token有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
第三方面,本申请实施例提供了一种电子设备,包括存储器和处理器;
存储器中存储有计算机程序;
处理器,用于执行计算机程序以实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第四方面,本申请实施例提供了一种计算机可读存储介质,计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第五方面,本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
本申请提供的技术方案带来的有益效果是:
用户访问未登录的第一应用系统时,重定向至已登录的相互信任的第二应用系统,认证系统在确定第二应用系统第二认证凭证有效时,使第一应用系统获取第一认证凭证,并反馈至用户,用户访问第一应用系统时无需输入登录信息,实现了单点登录,且该方案不限定相互信任的应用系统的认证机制,可以实现多个应用系统的跨域。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的而一种多系统单点登录方法的流程示意图;
图2为本申请实施例的一个示例中访问基于Token认证机制的应用系统的交互示意图;
图3为本申请实施例的一个示例中访问基于Cookie-Session认证机制的应用系统的交互示意图;
图4为本申请实施例的一个示例中以基于Token认证机制的应用系统为代理访问基于Cookie-Session认证机制的应用系统的交互示意图;
图5为本申请实施例的一个示例中以基于Cookie-Session认证机制的应用系统为代理访问基于Token认证机制的应用系统的交互示意图;
图6为本申请实施例提供的一种多系统单点登录装置结构框图;
图7为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能解释为对本申请的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当我们称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
由于目前的单点登录方案大多基于Cookie-Session认证机制实现,对于基于Token认证机制的应用系统,为了实现多点登录,一般采用将应用系统的认证机制转换为基于Cookie-Session的认证机制,并在转换后的多个应用系统中实现Session的共享。但是,该方案对代码侵入比较严重,破坏了Token认证的流程以及原有系统的安全性。并且,该方案无法解决各应用系统中跨域的问题。
另一种方案是通过为每个应用系统实现独立的认证系统,为各应用系统颁发认证Cookie,可以解决多个应用系统跨域的问题。但是该方案同样也存在以下问题:用户在实现登录流程后,只与应用系统的服务端进行交互,导致认证Cookie过期的问题,此时便无法免密码登录到其他应用系统。
认证Cookie长时间保存在浏览器中会存在一定的安全隐患,攻击者可以利用本地Cookie进行欺骗和CSRF(Cross-site request forgery,跨站请求伪造)攻击。Session保存在服务器端,如果短时间内有大量用户,会影响服务器性能。如果有些应用系统没有集成统一的认证系统,则无法在当前系统免密码登录到已集成单点登录的应用系统。
针对上述问题,本申请实施例提供了一种多系统单点登录方法、装置及计算机可读存储介质。下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本申请的实施例进行描述。
图1为本申请实施例提供的而一种多系统单点登录方法的流程示意图,该方法的执行主体为用户访问应用系统所使用的媒介,包括但不限于浏览器,app(Application,应用程序),小程序,笔记本电脑等,下文将以浏览器为例进行方案的描述,如图1所示,该方法可以包括:
步骤S101,在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统。
其中,第一应用系统和第二应用系统为相互信任应用系统,可以预先确定哪些应用系统为可以执行单点登录的应用系统,例如,企业可以设置一个相互信任的应用系统清单,位于清单上的应用系统都可以通过本申请提供的单点登录方式实现登录功能。
其中,认证系统用于单个应用系统的登录认证以及多个应用系统的点点登陆的登录认证,在对该方案进行说明过程中将对认证系统的功能进行详细描述。
具体地,当前用户需要访问第一应用系统,用户向浏览器发送针对第一应用系统的第一访问请求,浏览器将该访第一访问请求发送至认证系统,认证系统确定用户未登陆第一应用系统,且浏览器中存储有已登录的第二应用系统的第二链接(该链接也可称为代理链接),则启动单点登录。
需要说明的是,若当前浏览器中没有存储已登录的应用系统的链接,即之前没有相互信任的应用系统登录,则认证系统将返回统一的登录界面,用户通过该同一的登录界面输入对应的登录信息,即输入对应的用户名和密码进行登录。若之前有相互信任的应用系统登录,则获取该应用系统的链接作为代理链接,进行代理方式的单点登录,该代理方式的单点登录方式即为本申请实施例的关键点,后续将详细说明。
进一步地,本申请实施例中相互信任的应用系统自身的认证机制没有限制,可以为Cookie-Session认证机制,也可以为Token认证机制,或者其他认证机制。
步骤S102,重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统。
其中,认证凭证为应用系统登录后得到用于后续访问应用系统凭证,举例来说,对于基于Cookie-Session认证机制的应用系统,对应的认证凭证为登录后应用系统生成的Cookie,对于基于Token认证机制的应用系统,对应的认证凭证为登录后认证系统生成的Token。
具体地,浏览器在获取到已登录的第二应用系统的第二链接后,重定向至第二应用系统,获取之前存储的第二应用系统的第二认证凭证。
然后浏览器将该第二认证凭证和第一应用系统的第一链接一并发送给认证系统,认证系统对该第二认证凭证进行有效性验证,若确定该第二认证凭证有效,则生成与多数第二应用系统之间的cookie-auth(cookie授权)。其中,认证系统对第二认证凭证有效性的验证是基于第二应用系统本身所采用的认证机制的。
然后认证系统重定向至第一应用系统,并将生成的cookie-auth发送至第一应用系统。第一应用系统在接收到cookie-auth后,再次将cookie-auth发送至认证系统。其中,第一认证凭证的生成方式与第一应用系统本身的认证机制相关。
步骤S103,若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
具体地,若认证系统确定cookie-auth有效,则浏览器会接收到第一应用系统发送的第一认证凭证并存储,至此即完成了单点登录过程,第一应用系统同时还会将第一访问请求对应的资源发送给浏览器。后续用户即可基于第一认证凭证对第一应用系统进行访问。需要说明的是,本申请实施例中,用户访问应用系统所使用的媒介为浏览器时,采用cookie对第一认证凭证进行存储,若用访问应用系统所使用的媒介不是浏览器,则可以采用预先约定的文件形式对第一认证凭证进行存储。
可以理解的是,在访问未登录的第一应用系统过程中,通过已登录的第二应用系统作为代理,即认证系统对第二应用系统的认证凭证进行验证,并在认证通过后,第一应用系统将其自身的认证凭证反馈给浏览器,即完成了单点登录。第一应用系统和第二应用系统本身无论是何种认证机制都可以实现单点登录。
本申请提供的方案,用户访问未登录的第一应用系统时,重定向至已登录的相互信任的第二应用系统,认证系统在确定第二应用系统第二认证凭证有效时,使第一应用系统获取第一认证凭证,并反馈至用户,用户访问第一应用系统时无需输入登录信息,实现了单点登录,且该方案不限定相互信任的应用系统的认证机制,可以实现多个应用系统的跨域。
在本申请的一种可选实施例中,在接收用户发出的针对第一应用系统的访问请求之前,该方法还包括:
接收用户发出的针对所述第二应用系统的登录请求,所述登录请求包括登录信息;
存储所述第二链接,并将所述登录信息发送至所述认证系统,以使所述认证系统对所述登录信息的有效性进行验证;
若所述认证系统确定所述登录信息有效,则接收所述第二应用系统发送的第二认证凭证并存储。
具体地,在进行单点登录之前,第二应用系统需要完成登录,可以认为第二应用系统为多个相互信任的应用系统中首个通过浏览器登录的应用系统。基于不同的认证机制的应用系统登录过程有所区别。需要说明的是,本申请实施例中,用户访问应用系统所使用的媒介为浏览器时,采用cookie对第二认证凭证进行存储,若用访问应用系统所使用的媒介不是浏览器,则可以采用预先约定的文件形式对第二认证凭证进行存储。
举例来说,若第二应用系统为基于Token认证机制的应用系统,如图2所示,用户针对第二应用系统的登录和访问流程可以包括:
(1)用户首次通过浏览器访问第二应用系统。
(2)用户输入登录信息,即用户名、密码或其他信息向第二应用系统提交登录请求。
(3)第二应用系统收到登录请求后将登录信息提交到认证系统进行验证。
(4)认证系统对用户身份验证成功后,生成Token并返给第二应用系统。
(5)第二应用系统收到认证系统的验证结果后,将对应资源以及Token返给浏览器。
(6)浏览器保存Token,并向用户展示第二应用系统的系统页面,并在后续的访问请求中携带此值为参数。
(7)第二应用系统每次收到浏览器的请求后,均要向认证系统验证Token的有效性,并将对应结果返给浏览器。
若第二应用系统为基于Cookie-Session认证机制的应用系统,如图3所示,用户针对第二应用系统的登录和访问流程可以包括:
(1)用户通过浏览器首次访问第二应用系统。
(2)用户提交登录信息,即用户名、密码或其他信息到第二应用系统进行登录。
(3)第二应用系统收到登录请求后,将登录信息提交到认证系统进行身份验证。
(4)认证系统验证成功后返回验证结果。
(5)第二应用系统收到认证系统的成功结果,则创建Session-Cookie信息,即生成对应的Cookie,并将Cookie发送至浏览器,浏览器保存该Cookie,并向用户展示第二应用系统的系统页面。
(6)用户再次通过浏览器访问第二应用系统时均携带Cookie。
(7)第二应用系统每次处理浏览器的请求时,均会验证Cookie与服务端保存的Session-Cookie信息是否匹配再将对应结果返给浏览器。
在本申请的一种可选实施例中,若第二应用系统为基于Cookie-Session认证机制的应用系统,则认证系统确定第二认证凭证有效,包括:
认证系统将第二认证凭证发送至第二应用系统,若第二应用系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
具体地,单点登录采用第二应用系统作为代理的方式,此情形下第二认证凭证为Cookie,认证系统在接收到该Cookie后,将其发送至第二应用系统,验证Cookie与服务端保存的Session-Cookie信息是否匹配,若匹配则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,若第二应用系统为基于Token认证机制的应用系统,则认证系统确定第二认证凭证有效,包括:
若认证系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
具体地,单点登录采用第二应用系统作为代理的方式,此情形下第二认证凭证为Token,认证系统在接收到该Token后,确定是否发放过该Token,若发放过则确定第二认证凭证有效。
在本申请的一种可选实施例中,若第一应用系统为基于Cookie-Session认证机制的应用系统,则第一认证凭证为第一应用系统在接收到认证系统发送的cookie-auth有效的反馈消息后,生成的Cookie。
具体地,若第一应用系统为基于Cookie-Session认证机制的应用系统,在认证系统确定cookie-auth有效后,第一应用系统生成Cookie作为第一认证凭证。
进一步地,该方法还可以包括:
在接收到用户针对所述第一应用系统请求的第二访问请求时,将所述访问请求和所述Cookie发送至所述第一应用系统;
若所述第一应用系统确定所述Cookie有效,则接收所述第一应用系统发送的所述第二访问请求对应的资源,并向所述用户反馈所述资源。
具体地,在完成单点登录后,浏览器接收到用户针对所述第一应用系统的第二访问请求,第一应用系统只需要对Cookie进行验证即可。
在本申请的一种可选实施例中,若第一应用系统为基于Token认证机制的应用系统,则第一认证凭证为从认证系统接收到的认证系统在确定cookie-auth有效后,生成的Token。
具体地,若第一应用系统为基于Token认证机制的应用系统,在认证系统确定cookie-auth有效后,认证系统直接生成Token作为第一认证凭证。
进一步地,该方法还可以包括:
在接收到用户针对所述第一应用系统请求的第二访问请求时,将所述访问请求和所述Token发送至所述第一应用系统,以使所述第一应用系统将所述Token发送至所述认证系统;
若所述认证系统确定所述Token有效,则接收所述第一应用系统发送的所述第二访问请求对应的资源,并向所述用户反馈所述资源。
具体地,在完成单点登录后,浏览器接收到用户针对所述第一应用系统的第二访问请求,第一应用系统将Token发送至认证系统,认证系统对Token进行验证即可。
下面通过示例对本申请的单点登录方案进行进一步说明,如图4所示,以基于Token认证机制的应用系统为代理访问基于Cookie-Session认证机制的应用系统,可以包括以下几个步骤:
1.用户通过浏览器访问应用系统A,应用系统A为基于Token认证机制的应用系统。
2.应用系统A收到请求后通过认证系统验证用户是否已经登录。
3.认证系统判断用户没有登录则返回统一登录页面。
4.用户在浏览器上输入登录信息,即用户名、密码或其他登录信息,当用户点击提交按钮时,浏览器记录当前系统的代理链接proxy-url-A,并将表单提交至认证系统。
5.认证系统验证用户登录信息成功后生成Token-A并返回应用系统A。
6.应用系统A收到Token-A后,携带此Token返回用户请求的页面。
7.浏览器在渲染页面后,将Token-A保存至当前域的本地缓存。
8.用户与应用系统A之后的交互均需要携带此Token-A。
9.应用系统A在收到浏览器的请求后通过认证系统判断Token-A的有效性,如果Token-A有效则返回对应资源。
10.用户此时在浏览器中访问应用系统B,即发送针对应用系统的访问请求,应用系统B为Cookie-Session认证机制的应用系统。
11.应用系统B收到浏览器的访问请求后通过认证系统判断用户是否登录。
12.认证系统判断用户没有登录则返回统一登录页面,返回参数中含有应用系统B的链接。
13.浏览器在渲染登录页面之后,发现有步骤4记录的代理链接proxy-url-A,则直接重定向至此链接,此链接参数包含步骤12中的应用系统B的链接。
14.浏览器渲染proxy-url-A的页面后,读取步骤7中保存的Token-A,并将token-A以及步骤13中的应用系统B的链接发给认证系统。
15.认证系统验证Token-A的有效性,并记录正在请求的资源,Token-A有效则生成应用系统A与认证系统之间的Session-Cookie信息Cookie-auth。
16.认证系统生成Cookie-auth后重定向至步骤14传递的应用系统B的链接,此链接中的参数包括Cookie-auth。
17.应用系统B收到步骤15的请求以及Cookie-auth后,再次向认证系统判断用户是否登录。
18.认证系统收到步骤17的请求后检测到Cookie-auth,返回已登录的结果。
19.应用系统B收到已登录的结果后,生成Cookie-Session信息Cookie-B,并返回步骤15记录的请求的资源。
20.用户再通过浏览器访问应用系统B的资源时均会携带Cookie-B。
21.应用系统B每次只需验证Cookie-B的有效性及可。
如图5所示,以基于Cookie-Session认证机制的应用系统为代理访问基于Token认证机制的应用系统,可以包括以下几个步骤:
1.用户通过浏览器访问应用系统B,应用系统B为基于Token认证机制的应用系统。
2.应用系统B收到请求后通过认证系统验证用户是否已经登录。
3.认证系统判断用户没有登录则返回统一的登录页面。
4.用户在浏览器上输入登录信息,即用户名、密码或其他登录信息,当用户点击提交按钮时记录当前系统的代理链接proxy-url-B,并将表单提交至认证系统。
5.认证系统验证用户身份成功后将结果返回应用系统B。
6.应用系统B收到成功的反馈后,生成Cookie-Session信息,将Cookie-B返给浏览器。
7.浏览器保存当前Cookie并渲染对应的页面资源。
8.用户再次通过浏览器与应用系统B交互时,均会携带Cookie-B
9.应用系统B通过保存的Session信息验证Cookie-B并将结果返回给浏览器。
10.用户首次通过浏览器访问应用系统A,应用系统A为基于Token认证机制的应用系统。
11.应用A通过认证系统判断用户是否登录。
12.认证系统判断用户没有登录则返回登录页面,返回参数中含有应用系统A的链接。
13.浏览器在渲染登录页面之后,发现有步骤4记录的代理链接proxy-url-B,则直接重定向至此链接,此链接参数包含步骤12中的应用系统A的链接。
14.浏览器渲染proxy-url-B的页面后,读取步骤7中保存的Cookie-B,并将Cookie-B以及步骤13中的应用系统A的链接发给认证系统。
15.认证系统收到验证请求之后,向应用系统验证Cookie-B是否有效,Cookie-B有效则生成Cookie-auth并转发到应用A的链接。
16.应用A收到请求后以Cookie-auth为参数向认证系统验证是否登录。
17.认证系统验证Cookie-auth有效则生成Token-A并返给应用系统A。
18.应用系统A收到token-A后则返回对应的资源给浏览器。
由以上示例可以看出本申请实施例提供的多系统单点登录方案还进一步具有以下有益效果:
独立的认证系统不仅保证了原有系统中的认证服务不受影响外,还解决了多个应用系统跨域时遇到的Cookie同源的问题。
集成单点登录的应用系统不受原有认证机制的限制,可以使用任意的认证机制,包括但不限于Token认证,Session-Cookie认证等。
降低了Cookie-Session的生命周期不仅降低了Cookie被篡改的风险,同时也避免了认证系统里大量积压的Session信息,提高了认证系统的性能。
对于没有集成独立认证系统的应用系统只需要实现认证系统的代理接口即可免密码登录其他已集成单点登录的应用系统,并不会破坏原有系统的认证机制。
图6为本申请实施例提供的一种多系统单点登录装置结构框图,如图6所述,该装置600可以包括:代理链接获取模块601、代理认证模块602以及登录和访问模块603,其中:
代理链接获取模块601用于在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统;
代理认证模块602用于重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统;
登录和访问模块603用于若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
本申请提供的方案,用户访问未登录的第一应用系统时,重定向至已登录的相互信任的第二应用系统,认证系统在确定第二应用系统第二认证凭证有效时,使第一应用系统获取第一认证凭证,并反馈至用户,用户访问第一应用系统时无需输入登录信息,实现了单点登录,且该方案不限定相互信任的应用系统的认证机制,可以实现多个应用系统的跨域。
在本申请的一种可选实施例中,该装置可以包括第二应用系统登录模块,用于在接收用户发出的针对第一应用系统的访问请求之前,接收用户发出的针对第二应用系统的登录请求,登录请求包括登录信息;
存储第二链接,并将登录信息发送至认证系统,以使认证系统对登录信息的有效性进行验证;
若认证系统确定登录信息有效,则接收第二应用系统发送的第二认证凭证并存储。
在本申请的一种可选实施例中,代理认证模块具体用于:
若第二应用系统为基于Cookie-Session认证机制的应用系统,认证系统将第二认证凭证发送至第二应用系统,若第二应用系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,代理认证模块具体用于:
若第二应用系统为基于Token认证机制的应用系统,若认证系统确定发放过第二认证凭证,则认证系统确定第二认证凭证有效。
在本申请的一种可选实施例中,若第一应用系统为基于Cookie-Session认证机制的应用系统,则第一认证凭证为第一应用系统在接收到认证系统发送的cookie-auth有效的反馈消息后,生成的Cookie。
在本申请的一种可选实施例中,该装置还可以包括第二访问模块,用于:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Cookie发送至第一应用系统;
若第一应用系统确定Cookie有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
在本申请的一种可选实施例中,若第一应用系统为基于Token认证机制的应用系统,则第一认证凭证为从认证系统接收到的认证系统在确定cookie-auth有效后,生成的Token。
在本申请的一种可选实施例中,该装置还可以包括第二访问模块,用于:
在接收到用户针对第一应用系统请求的第二访问请求时,将访问请求和Token发送至第一应用系统,以使第一应用系统将Token发送至认证系统;
若认证系统确定Token有效,则接收第一应用系统发送的第二访问请求对应的资源,并向用户反馈资源。
下面参考图7,其示出了适于用来实现本申请实施例的电子设备(例如执行图1所示方法的终端设备或服务器)700的结构示意图。本申请实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)、可穿戴设备等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图7示出的电子设备仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
电子设备包括:存储器以及处理器,存储器用于存储执行上述各个方法实施例所述方法的程序;处理器被配置为执行存储器中存储的程序。其中,这里的处理器可以称为下文所述的处理装置701,存储器可以包括下文中的只读存储器(ROM)702、随机访问存储器(RAM)703以及存储装置708中的至少一项,具体如下所示:
如图7所示,电子设备700可以包括处理装置(例如中央处理器、图形处理器等)701,其可以根据存储在只读存储器(ROM)702中的程序或者从存储装置708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM703中,还存储有电子设备700操作所需的各种程序和数据。处理装置701、ROM 702以及RAM703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。
通常,以下装置可以连接至I/O接口705:包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置706;包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置707;包括例如磁带、硬盘等的存储装置708;以及通信装置709。通信装置709可以允许电子设备700与其他设备进行无线或有线通信以交换数据。虽然图7示出了具有各种装置的电子设备,但是应理解的是,并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地,根据本申请的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在非暂态计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信装置709从网络上被下载和安装,或者从存储装置708被安装,或者从ROM 702被安装。在该计算机程序被处理装置701执行时,执行本申请实施例的方法中限定的上述功能。
需要说明的是,本申请上述的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:电线、光缆、RF(射频)等等,或者上述的任意合适的组合。
在一些实施方式中,客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol,超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信,并且可以与任意形式或介质的数字数据通信(例如,通信网络)互连。通信网络的示例包括局域网(“LAN”),广域网(“WAN”),网际网(例如,互联网)以及端对端网络(例如,ad hoc端对端网络),以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。
上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被该电子设备执行时,使得该电子设备:
在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统;重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统;若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码,上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的模块或单元可以通过软件的方式实现,也可以通过硬件的方式来实现。其中,模块或单元的名称在某种情况下并不构成对该单元本身的限定,例如,代理链接获取模块还可以被描述为“获取代理链接的模块”。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如,非限制性地,可以使用的示范类型的硬件逻辑部件包括:现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
在本申请的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的计算机可读介质被电子设备执行时实现的具体方法,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令,处理器执行该计算机指令,使得该计算机设备执行时实现如下情况:
在接收到用户发出的针对第一应用系统的第一访问请求时,将访问请求发送至认证系统,若认证系统确定用户未登录第一应用系统,则获取已登录的第二应用系统的第二链接,第二应用系统与第一应用系统为互相信任的应用系统;重定向至第二链接,获取第二应用系统的第二认证凭证,并将第二认证凭证和第一应用系统的第一链接,发送至认证系统,以使认证系统在确定第二认证凭证有效时,生成与第二应用系统之间的cookie-auth,并重定向至第一链接,将cookie-auth发送至第一应用系统,以使第一应用系统将cookie-auth再次发送至认证系统;若认证系统确定cookie-auth有效,则接收第一应用系统发送的第一认证凭证和访问请求对应的资源,进而存储第一认证凭证,并将资源反馈给用户。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本发明的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种多系统单点登录方法,其特征在于,包括:
在接收到用户发出的针对第一应用系统的第一访问请求时,将所述访问请求发送至认证系统,若所述认证系统确定所述用户未登录所述第一应用系统,则获取已登录的第二应用系统的第二链接,所述第二应用系统与所述第一应用系统为互相信任的应用系统;
重定向至所述第二链接,获取所述第二应用系统的第二认证凭证,并将所述第二认证凭证和所述第一应用系统的第一链接,发送至所述认证系统,以使所述认证系统在确定所述第二认证凭证有效时,生成与所述第二应用系统之间的cookie-auth,并重定向至所述第一链接,将所述cookie-auth发送至所述第一应用系统,以使所述第一应用系统将所述cookie-auth再次发送至所述认证系统;
若所述认证系统确定所述cookie-auth有效,则接收所述第一应用系统发送的第一认证凭证和所述访问请求对应的资源,进而存储所述第一认证凭证,并将所述资源反馈给所述用户。
2.根据权利要求1所述的方法,其特征在于,在接收用户发出的针对第一应用系统的访问请求之前,所述方法还包括:
接收用户发出的针对所述第二应用系统的登录请求,所述登录请求包括登录信息;
存储所述第二链接,并将所述登录信息发送至所述认证系统,以使所述认证系统对所述登录信息的有效性进行验证;
若所述认证系统确定所述登录信息有效,则接收所述第二应用系统发送的第二认证凭证并存储。
3.根据权利要求1所述的方法,其特征在于,若所述第二应用系统为基于Cookie-Session认证机制的应用系统,则所述认证系统确定所述第二认证凭证有效,包括:
所述认证系统将所述第二认证凭证发送至所述第二应用系统,若所述第二应用系统确定发放过所述第二认证凭证,则所述认证系统确定所述第二认证凭证有效。
4.根据权利要求1所述的方法,其特征在于,若所述第二应用系统为基于Token认证机制的应用系统,则所述认证系统确定所述第二认证凭证有效,包括:
若所述认证系统确定发放过所述第二认证凭证,则所述认证系统确定所述第二认证凭证有效。
5.根据权利要求1所述的方法,其特征在于,若所述第一应用系统为基于Cookie-Session认证机制的应用系统,则所述第一认证凭证为所述第一应用系统在接收到所述认证系统发送的所述cookie-auth有效的反馈消息后,生成的Cookie。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
在接收到用户针对所述第一应用系统请求的第二访问请求时,将所述访问请求和所述Cookie发送至所述第一应用系统;
若所述第一应用系统确定所述Cookie有效,则接收所述第一应用系统发送的所述第二访问请求对应的资源,并向所述用户反馈所述资源。
7.根据权利要求1所述的方法,其特征在于,若所述第一应用系统为基于Token认证机制的应用系统,则所述第一认证凭证为从所述认证系统接收到的所述认证系统在确定所述cookie-auth有效后,生成的Token。
8.根据权利要求7所述的方法,其特征在于,所述方法还包括:
在接收到用户针对所述第一应用系统请求的第二访问请求时,将所述访问请求和所述Token发送至所述第一应用系统,以使所述第一应用系统将所述Token发送至所述认证系统;
若所述认证系统确定所述Token有效,则接收所述第一应用系统发送的所述第二访问请求对应的资源,并向所述用户反馈所述资源。
9.一种多系统单点登录装置,其特征在于,包括:
代理链接获取模块,用于在接收到用户发出的针对第一应用系统的第一访问请求时,将所述访问请求发送至认证系统,若所述认证系统确定所述用户未登录所述第一应用系统,则获取已登录的第二应用系统的第二链接,所述第二应用系统与所述第一应用系统为互相信任的应用系统;
代理认证模块,用于重定向至所述第二链接,获取所述第二应用系统的第二认证凭证,并将所述第二认证凭证和所述第一应用系统的第一链接,发送至所述认证系统,以使所述认证系统在确定所述第二认证凭证有效时,生成与所述第二应用系统之间的cookie-auth,并重定向至所述第一链接,将所述cookie-auth发送至所述第一应用系统,以使所述第一应用系统将所述cookie-auth再次发送至所述认证系统;
登录和访问模块,用于若所述认证系统确定所述cookie-auth有效,则接收所述第一应用系统发送的第一认证凭证和所述访问请求对应的资源,进而存储所述第一认证凭证,并将所述资源反馈给所述用户。
10.一种电子设备,其特征在于,包括存储器和处理器;
所述存储器中存储有计算机程序;
所述处理器,用于执行所述计算机程序以实现权利要求1至8中任一项所述的方法。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法。
CN202111190504.0A 2021-10-13 2021-10-13 多系统单点登录方法、装置及计算机可读存储介质 Pending CN113821784A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111190504.0A CN113821784A (zh) 2021-10-13 2021-10-13 多系统单点登录方法、装置及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111190504.0A CN113821784A (zh) 2021-10-13 2021-10-13 多系统单点登录方法、装置及计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN113821784A true CN113821784A (zh) 2021-12-21

Family

ID=78920244

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111190504.0A Pending CN113821784A (zh) 2021-10-13 2021-10-13 多系统单点登录方法、装置及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN113821784A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114297598A (zh) * 2022-02-23 2022-04-08 阿里云计算有限公司 用户权限处理方法及装置
CN114430340A (zh) * 2021-12-24 2022-05-03 天翼云科技有限公司 一种跨域单点登录方法、装置及设备
CN115102724A (zh) * 2022-06-06 2022-09-23 珠海格力电器股份有限公司 一种双Token跨端跳转系统的登录方法、系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114430340A (zh) * 2021-12-24 2022-05-03 天翼云科技有限公司 一种跨域单点登录方法、装置及设备
CN114297598A (zh) * 2022-02-23 2022-04-08 阿里云计算有限公司 用户权限处理方法及装置
CN115102724A (zh) * 2022-06-06 2022-09-23 珠海格力电器股份有限公司 一种双Token跨端跳转系统的登录方法、系统
CN115102724B (zh) * 2022-06-06 2023-12-08 珠海格力电器股份有限公司 一种双Token跨端跳转系统的登录方法、系统

Similar Documents

Publication Publication Date Title
US10965664B2 (en) Single sign-on for unmanaged mobile devices
US10880292B2 (en) Seamless transition between WEB and API resource access
EP3308525B1 (en) Single sign-on for unmanaged mobile devices
CN111639319B (zh) 用户资源授权方法、装置及计算机可读存储介质
WO2017028804A1 (zh) 一种Web实时通信平台鉴权接入方法及装置
TWI725958B (zh) 雲端主機服務權限控制方法、裝置和系統
US9104848B2 (en) Cross-platform authentication from within a rich client
KR101850677B1 (ko) 웹사이트에 로그인하는 단말기가 모바일 단말기인지를 결정하기 위한 방법 및 시스템
CN112131021B (zh) 一种访问请求处理方法及装置
US9584615B2 (en) Redirecting access requests to an authorized server system for a cloud service
CN113821784A (zh) 多系统单点登录方法、装置及计算机可读存储介质
CN113630377B (zh) 托管移动设备的单点登录
US9298896B2 (en) Safe auto-login links in notification emails
CN111062023B (zh) 多应用系统实现单点登录的方法及装置
CA2633311A1 (en) Method, apparatus and program products for custom authentication of a principal in a federation by an identity provider
WO2019040658A1 (en) SINGLE HYBRID SIGNATURE FOR APPLICATIONS AND SOFTWARE SERVICES USING CLASSIC AND MODERN IDENTITY PROVIDERS
CN111865882B (zh) 一种微服务认证方法和系统
CN112866385B (zh) 接口调用方法、装置、电子设备和存储介质
CN111698250A (zh) 访问请求处理方法、装置、电子设备及计算机存储介质
CN112583834B (zh) 一种通过网关单点登录的方法和装置
CN112491778A (zh) 认证方法、装置、系统及介质
CN115001840B (zh) 一种基于代理的鉴权方法、系统及计算机储存介质
WO2023170653A1 (en) System and method for providing multi factor authorization to rdp services through a zero trust cloud environment
CN113765876B (zh) 报表处理软件的访问方法和装置
CN114764507A (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