关于Citrix与RSA认证结合认证模式

在一些项目中,Citrix的项目除了AD的常用身份认证之外,客户还希望集成RSA等类似的双因素身份验证解决方案。实现Citrix与RSA结合的认证模式主要有三种:

1) 仅使用RSA认证登陆,就可以访问应用程序,类似智能卡认证模式;

2) 在认证登陆界面上,同时输入User Name、Password、PassCode的认证模式;

3)实现分步登陆模式,首先由RSA的Web界面使用RSA的PassCode登陆,然后由Citrix的Web界面使用User Name、Password登陆。或者是先通过Citrix的Web界面使用User Name、Password登陆,然后再使用RSA的Web界面使用RSA的PassCode登陆。不管谁先谁后,都是需要分步二次输入的。

在这种集成解决方案当中,其和Citrix的Web Interface组件以及StoreFront组件是紧密集成的。现目前的解决方案当中,在Web Interface时代,都支持这三种模式:

Web Interface本身如果不经过二次开发或者RSA等解决方案不对Web Interface开发Agent,Web Interface仅支持的后两种模式:

1)仅RSA认证登录:在该模式下,经过测试无法实现,需要经过二次开发或者RSA等解决方案对Web Interface开发Agent,目前过来类似的解决方案有中科恒伦的厂家开发了基于Web Interface的Agent,可以做到这种认证方式。

测试这种方案:

首先在Citrix Web Interface服务器上安装RSA Agent,该RSA Agent使用默认的基于Windows的RSA Agent。但是有所注意的是,需要先安装RSA Agent,再安装CItrix Web Interface组件,然后再来配置Web Interface对RSA认证的支持。


       如上图所示,Web Interface默认支持基于RSA SecurID的认证模式,在双因素认证的设置中选择Use RSA SecurID,同时选择Use Windows password integration即可。

设置完毕之后通过Web Interface登录发现还是需要输入用户名和密码以及RSA的Code。我们猜测是RSA的Agent无法为Web Interface中的用户名和密码进行替代。因为RSA的Agent是常规的Windows的RSA Agent,并不是专门基于Web Interface的SDK所调取的Agent。

2)同时双因素密码输入的方式:在该模式下,在Web Interface在双因素认证的设置中选择Use RSA SecurID,不选择Use Windows password integration即可完成设置。

3)分步登录的方式需要在Web Interface上安装RSA Agent for Web的组件,其需要在服务器上建立一个RSA的登录Web站点。然后在IIS中增加RSA SecurID模块,启用RSA Web认证。在登录的时候,首先会进行RSA的认证,成功之后再跳转到Citrix Web  Interface的认证页面。

上述后两种方式Web Interface也可以和Citrix NetScaler Gateway集成,在NetScaler上做验证后再跳转到Citrix  Web Interface。如果采用NetScaler,那么第三种方式可以不用在Web interface上安装RSA Agent For Web,只需要在NetScaler上配置验证身份的先后顺序即可。

那么在StoreFront时代呢?

在StoreFront时代,其三种模式都受支持:

1)仅RSA认证登录:在该模式下,StoreFront实现由两种方式:

a、使用RSA Agent方式实现,该方式需要StoreFront 3.0及以上版本。该模式是RSA通过StoreFront的SDK,开发的一个RSA Agent For StoreFront来实现。也就是说,在StoreFront上安装了RSA的这个CitrixSF的Agent之后,用户就可以采用基于RSA的认证方式来代替AD用户名和密码方式了。

b、该方式是使用Citrix FAS来实现的,同时也需要StoreFront 3.6及以上版本。因为Citrix FAS整体需要的版本较高,因此这种实现方式其实需要Citrix XAXD为7.9及以上版本。

针对第一种方式,感兴趣的朋友可以访问以下网址去下载RSA Agent For StoreFront:https://www.rsa.com/en-us/products-services/identity-access-management/securid/authentication-agents/authentication-agent-for-citrix-storefront

该网站已经将相关文档以及Agent安装包放置在网址上免费下载。需要指出的是,支持该Agent的后端RSA AM需要8.1及以上版本。

该Agent如下图:

与Web Interface不同的是,该Agent需要先安装Citrix StoreFront,再安装RSA Agent。

第二种使用Citrix FAS来实现,需要在StoreFront上启用Citrix FAS,然后配置Citrix FAS的相关服务器并且最好和Citrix NetScaler集成使用。Citrix FAS的工作机制很简单:NetScaler在身份提供商处接受SAML令牌或者RSA SecurID令牌。内置Citrix SSO机制将身份传递给StoreFront,NetScaler将SAML名称或者RSA Code转换为相应的AD帐户名称。StoreFront使用Kerberos机制检查AD帐户是否有效,并执行资源枚举。启动应用程序时,StoreFront首先联系联合身份验证服务(FAS),以确保用户帐户的凭据已准备就绪。 FAS配置有受信任的StoreFront服务器的列表以执行此步骤。该凭证本身是由企业CA为Active Directory用户颁发的,由FAS拥有的私钥的智能卡证书。 FAS返回StoreFront的凭据句柄,该句柄被传递到VDA,供用户连接。当Receiver连接到VDA时,凭证句柄用于执行智能卡登录。

如前所述,FAS依靠AD证书服务为授权机构生成安全证书凭证,然后AD通过该凭证接受交互式会话登录。对于Windows上的VDA,它就好像用户有一个正常的智能卡,但私钥实际上是安全地保存在FAS服务器上,并且用户不会拥有这个私钥。而对于FAS这个组件, StoreFront和VDA插件现在已经默认集成在安装包中,我们安装了这些组件之后,在需要使用的时候只需启用即可,因此FAS服务器本身是唯一需要新安装的新组件。

这种方法的一个显着优点是可以缓存这些凭证以供重用,从而提高性能和可用性;另一个是证书可以在Internet Explorer,Outlook,Chrome和其他应用程序的会话内使用,以验证使用PKI的网络资源。

其实实质上,Citrix的身份验证体系或者说微软的公有云身份验证体系,或多或少的都在借鉴AWS的IAM,Citrix FAS只是个开始,其向IAM靠拢的脚步我觉得在以后的版本会越来越明显。

云计算的模式促使这些基于硬AD绑定的解决方案不得不寻求更加灵活的身份验证机制来解决越来越多的SaaS、PaaS应用所带来的IT方式的变革。而如今的认证解决方案中,基于IdP的认证模式,适用于所有场景和所有资源访问。因此基于IdP的认证模式是未来所以认证模式的方向。

感兴趣的朋友可以通过以下网址去下载资源进行测试使用:https://community.rsa.com/docs/DOC-24869

2)同时双因素密码输入的方式:在该模式下,StoreFront需要NetScaler的支持才可以,StoreFront本身不支持RSA的二次身份验证。


      如图所示,这就是通过NetScaler配置的基于RSA双因素认证,在同一登录界面同时输入AD账户和RSA口令的情况。

这种情况只需在NetScaler gateway上配置主身份验证LDAP和次身份验证RADIUS即可。

3)分步登录的方式也是需要StoreFront和NetScaler紧密集成来完成。具体的配置方案Google上可以收到或者上youtube查看配置视频。其情况上述已经说明,在此不再重复。

与以往只提供一种硬件令牌双因子认证方案相比,CKEY或RSA可以让客户选择如下三种动态密码形式的一种或者多种:

短信密码:通过短信将随机密码发至用户手机,无需安装软件、无需携带额外硬件设备;

手机令牌:动态密码生成手机客户端程序,支持iOS、Andriod、WP7,无使用成本;

硬件令牌:时间型、每隔60秒产生一个动态密码,无按键式、36个寿命;

在为用户提供安全认证的同时,提升使用便捷性,CKEY或RSA已成为国内Citrix用户首选方案。

时间: 2024-10-13 01:08:32

关于Citrix与RSA认证结合认证模式的相关文章

OpenSSH的RSA/DSA密钥认证系统

OpenSSH的RSA/DSA密钥认证系统,它可以代替OpenSSH缺省使用的标准安全密码认证系统. OpenSSH的RSA和DSA认证协议的基础是一对专门生成的密钥,分别叫做私用密钥和公用密钥. 使用这些基于密钥的认证系统的优势在于:在许多情况下,有可能不必手工输入密码就能建立起安全的连接.尽管基于密钥的认证协议相当安全,但是当用户并不完全了解这些简化操作对安全性的影响,为了方便而使用某些简化操作时,就会出现问题. 公用密钥用于对消息进行加密,只有拥有私用密钥的人才能对该消息进行解密.公用密钥

理解OpenSSH的RSA和DSA认证过程

OpenSSH 的 RSA 和 DSA 认证协议的基础是一对专门生成的密钥,分别叫做 专用密钥和 公用密钥.使用这些基于密钥的认证系统的优势在于:在许多情况下,有可能不必手工输入密码就能建立起安全的连接. 尽管基于密钥的认证协议相当安全,但是当用户并不完全了解这些简化操作对安全性的影响,为了方便而使用某些简化操作时,就会出现问题.本文中,我们将详细讨论如何正确使用 RSA 和 DSA 认证协议,使我们不会冒任何不必要的安全性风险.在我的下一篇文章里,我将向您展示如何使用 ssh-agent 隐藏

asp.net core 使用identityServer4的密码模式来进行身份认证(2) 认证授权原理

原文:asp.net core 使用identityServer4的密码模式来进行身份认证(2) 认证授权原理 前言:本文将会结合asp.net core 认证源码来分析起认证的原理与流程.asp.net core版本2.2 对于大部分使用asp.net core开发的人来说. 下面这几行代码应该很熟悉了. services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { o

翻译:WebApi 认证--用户认证Oauth解析

The Web API v2用户认证模板提供了流行的应用用户认证场景,如.使用本地帐号的用户名密码认账 (包括创建用户.设置和修改密码)以及使用第三方的认证方式,如facebook,google等等– 在本地中包含了外部帐号的连接 所有的这些均通过使用一个OAuth2认证服务进行. To make all that happen the template combines quite a bit of new stuff together: OWIN, Katana authentication

PPP PAP 认证 CHAP 认证

[实验名称] PPP PAP 认证 [实验目的] 掌握 PPP PAP 认证的过程及配置 [背景描述] 你是公司的网络管理员,公司为了满足不断增长的业务需求,申请了专线接入,你的客 户端路由器与 ISP 进行链路协商时要验证身份,配置路由器保证链路建立,并考虑其安全 性. [需求分析] 在链路协商时保证安全验证.链路协商时用户名.密码以明文的方式传输. [实验设备] 路由器(带串口) 2 台 V.35 线缆(DTE/DCE) 1 对 [实验原理] PPP 协议位于 OSI 七层模型的数据链路层,

微信服务号申请、认证、认证后

  微信公众号申请.认证:01. 账号申请开始------>02.申请账号结束----->7个工作日--->03.开始账号认证----->04.结束账号认证----->15个工作日--->05.账号认证通过 商家支付接口申请:     07.开始申请 商家微信支付接口----->08.结束申请 商家微信支付接口 ,等待审核---->7个工作日----->09.支付接口申请通过,进入技术集成阶段 -----------------------------

自学Aruba7.1-Aruba安全认证-WPA2-PSK认证(web页面配置)

点击返回:自学Aruba之路 自学Aruba7.1-Aruba安全认证-WPA2-PSK认证(web页面配置) 1 管理员账号管理 Configuration---Administrator中 原文地址:https://www.cnblogs.com/yaoyaojcy/p/9290050.html

基于mosquitto的MQTT服务器---SSL/TLS 单向认证+双向认证

基于mosquitto的MQTT服务器---SSL/TLS 单向认证+双向认证 摘自:https://blog.csdn.net/ty1121466568/article/details/81118468 2018年07月19日 16:51:57 曾来过 阅读数:1632 本文为参考网上其他博文搭建出服务器后的步骤记录,如有冒犯,请私信!!! 目录... 3 第 1 章 安装Mosquitto. 4 1.1 方法一:手动编译安装... 4 1.2方法二:在Ubuntu下使用apt-get安装..

?DRF?-----三大认证组件--认证组件

认证组件 铺垫: 源码分析 入口: restframework 框架内的 views 下的 APIView 的 dispatch方法 组件的最下面 有三个方法   分别是 认证组件  权限组件 和 频率组件 perform_authentication (认证组件) 校验用户 - 游客 合法用户 非法用户 游客: 代表校验通过 进入下一步校验 (权限校验) 合法用户: 代表校验通过 将用户 存储在 request.user 中 再进行下一步校验 非法用户: 代表校验失败 抛出异常 返回403 权