[应用安全]什么是联合身份管理?
介绍
联合身份管理是一种可以在两个或多个信任域之间进行的安排,以允许这些域的用户使用相同的数字身份访问应用程序和服务。这称为联合身份,使用这种解决方案模式称为身份联合。
联合身份管理建立在两个或多个域之间的信任基础之上。例如,信任域可以是合作伙伴组织、业务单位、子公司等。
在当今的任何数字组织中,身份和访问管理 (IAM) 是一项专门的功能,委托给称为身份代理的服务提供商。这是一项专门在多个服务提供商之间代理访问控制的服务,也称为依赖方。联合身份管理是跨组织的两个或多个提供者之间做出的安排。
根据身份代理在联合身份管理中所扮演的角色,身份代理可能有其他名称。这些名称在整个行业中并未标准化,尽管以常见的说法使用并且可以互换使用。因此,无论何时使用这些名称,都必须在相关上下文中指定这些名称,并且根据安排,身份代理可能扮演多个角色。
这些角色包括:
- 身份提供者
- 居民身份提供者
- 联合身份提供者
- 联合提供者
- 常驻授权服务器
以下是每个角色的简要说明。
身份提供者负责声明带有声明的数字身份,供服务提供者使用。
居民身份提供者是针对数字身份定义的,并且不负责在其信任域内声明数字身份。有时这也称为本地身份提供者或现任身份提供者。
联合身份提供者是针对信任域定义的,并负责声明属于第二个信任域的数字身份。两者之间建立了信任关系。
联合提供者一词表示身份代理,它专门根据信任关系在多个服务提供者和多个身份提供者之间调解 IAM 操作。
驻留授权服务器是针对服务提供者定义的,并且是应用程序或服务提供者的逻辑表示所在的位置。它负责对应用程序或服务提供者进行身份验证和授权以获取所请求的访问权限。
身份联合的好处
- 提供无缝的用户体验,因为用户只需要记住一组凭据。
- 大多数实现都支持单点登录。
- 通过将帐户和密码管理职责委托给常驻身份提供者来避免管理开销,而不必管理多个身份孤岛。
- 简化数据管理和存储成本。
- 避免隐私和合规负担。
联合身份管理用例示例
- 联合身份管理提供对来自供应商、分销商和合作伙伴网络的用户的访问。
- 联合身份管理为并购后传统组织范围之外的新用户提供访问权限。
- 联合身份管理提供对来自银行等商业身份提供者的用户的访问,例如,PSD2 中的第三方支付提供者 (TPP)。提供对来自银行等商业身份提供者的用户的访问,例如,PSD2 中的第三方支付提供者 (TPP) .
- 联合身份管理使用国家身份提供者(例如 DigiD、Emirates ID 等)向公民提供访问权限。
- 联合身份管理为拥有公共组织 ID(例如 ORCID ID)的用户提供访问权限。
- 此外,这允许使用社交登录(注册/登录/连接),例如 Facebook、Google、LinkedIn 等。
- 此外,它可以用作临时安排,以支持 IAM 系统之间的转换。
入站和出站身份联合
身份联合大致分为两个领域:
- 入站身份联合
- 出站身份联合
在身份联合流程中,一个从另一个身份代理接收断言的身份代理称为入站身份联合。这允许您向您的组织的传统边界/信任域之外的身份提供对您的应用程序和服务的访问。
类似地,产生要由另一个身份代理使用的断言的身份提供者称为出站身份联合。这允许您管理的身份访问您组织的传统边界/信任域之外的应用程序和服务。
- Figure 1: Identity Federation between the Enterprise and SaaS Application
图 1 说明了企业和 SaaS 应用程序之间的身份联合安排。SaaS 应用程序托管在 Azure 云中,其身份验证委托给联合提供商。企业是 SaaS 应用程序的租户和联合提供商。企业身份提供者 (ADFS) 在 Azure 云中联合提供者的相应租户中配置为联合身份提供者。因此,在云租户的联合提供者和企业身份提供者之间建立了信任。因此,企业身份提供者中的用户将能够使用他们在企业身份提供者中的身份登录到 SaaS 应用程序的相应租户。
所描述的流程是关于认证的。但是,为了让用户获得完全访问权限,他们还需要通过授权。授权可能是也可能不是这种联合安排的一部分。
身份联合与单点登录
大多数联合身份管理解决方案的实施方式是,用户无需在每个登录会话中多次证明其身份。单点登录不是身份联合的同义词。但是,它是其实施方式的副产品。
另一方面,并不是所有的单点登录实现都可以归类为身份联合。例如,基于 Kerberos 网络身份验证协议的集成 Windows 身份验证 (IWA) 是跨应用程序和服务的单点登录实施示例,但不被视为身份联合的示例,因为它仅限于特定网络。
带上你自己的身份
随着使用社交身份访问应用程序和服务的趋势,自带身份 (BYOID) 一词变得流行起来。虽然 BYOID 通常用于社会身份的背景下,但该概念适用于由*、非*组织或企业发布的任何联合数字身份。
用例 3、4、5 和 6 都是 BYOID 的示例,常见于客户 IAM (CIAM)。它们可以进一步划分为 BYOID,用于注册、登录和连接。尽管所有这 3 个用例都遵循类似的流程,但这些用例的目标存在细微差别。
“用于注册的 BYOID”的目标是通过检索一部分以完成在中间身份代理中为用户创建帐户所必需的个人资料信息,使用管理的身份来改善自我注册过程的用户体验由第三方。
相反,“用于登录的 BYOID”的目的是使最终用户的登录流程尽可能顺畅,同时尽可能减少额外输入的提示。用于登录的 BYOID 不一定需要在中间身份代理中配置本地帐户。
最后,“BYOID 连接”的目的只是用附加/缺失的信息丰富/填充本地用户配置文件。
联合帐户链接
联合身份提供者的关键特征之一是将多个联合身份提供者中的单个身份的数字标识符链接到常驻身份提供者中的数字标识符。 这称为联合帐户链接。
如果没有联合帐户链接,联合提供者将仅在服务提供者和联合身份提供者之间进行调解。这种联合模式常见于非关键应用和服务中,例如公共论坛、下载表格、白皮书、报告等。这可以在下面的图 2 中看到。
- Figure 2: Federated login without account linking
然而,对于联合帐户链接,除了调解之外,联合提供者还可以提供帐户管理、密码管理和权利管理等功能,如图 3 所示。
- Figure 3: Federated login with account linking
即时账户配置
即时帐户配置技术用于在中间身份代理中为用户即时设置帐户。 即时账户配置是即时账户链接的关键部分。图 4 更好地说明了这一概念。
Figure 4: Federated login with just-in-time account provisioning
即时密码配置
即时密码配置是即时账户配置的可选步骤。对此类供应的需求通常取决于组织的组合帐户和密码策略以及用户将访问的应用程序。如果您决定为本地帐户提供新密码,则允许用户继续使用联合身份登录也是可选的。
家庭领域发现
与单一身份提供者联合不足以满足当今的企业需求。由于需要支持多个合作伙伴或多个社交登录选项,通常会配置多个联合身份提供者(称为领域)。在这种情况下,为尝试访问应用程序或服务的特定用户选择常驻身份提供者(通常称为家庭领域)成为一项挑战,尤其是在用户体验方面。
家庭领域发现 (HRD) 是识别特定用户的常驻身份提供者的过程,以便对用户进行身份验证并通过声明断言用户的身份。HRD 最初是 Microsoft 术语,但该概念适用于所有现代身份联合。关于如何实施 HRD 没有标准。每个供应商都有自己的风格,因此很难支持可移植性。
HRD 方法可以是自动的或涉及手动用户交互。以下是一些常用的HRD方法:
- 向用户提供可供选择的选项列表。
- 标识符首次登录 — 提示用户输入自己的标识符,并根据标识符解析身份提供者。例如,如果标识符是 johann@gmail.com,我们会知道 Johann 的身份提供者是 Google,向 Google 发起身份验证请求,理想情况下,标识符会预先填写在 Google 登录表单中,以便用户不必重新输入他的标识符。
- 选择性家庭领域发现 — 限制用于特定服务提供者的身份提供者。这在有多个您信任的联合身份提供者但具有仅由身份提供者的特定子集中的用户使用和访问的服务提供者的情况下很有用。
- 使用服务提供者添加的 HTTP 查询参数。
- 使用用户设备的 IP 地址。例如,Intranet 用户必须使用 Active Directory (AD) 中的本地帐户登录,而 Internet 用户必须从具有多因素身份验证的上游身份提供者登录,以提高安全性。
- 使用通过拦截代理服务器添加的标头。
- 使用 cookie 来记住用户之前在设备上选择的领域。如果未找到 cookie,则回退到手动方法。
- 联合身份提供者本身可以是一个联合提供者,后者又与其他身份提供者联合。在这种情况下,提示用户在每个中间联盟提供商处为 HRD 提供信息,可能会被认为是糟糕的用户体验。因此,可能需要预先从用户那里收集所有可能的信息,以将其路由到正确的居民身份提供者。
支持 IAM 转换
身份联合也可以用作 IAM 的过渡策略。它可以促进从多个分散的源用户目录到单个集中的目标用户目录的转换。在这种情况下,将提供密码。最终迁移所有帐户后,您可能决定将这些管理分布式目录的联合身份提供者与生态系统断开连接。
概括
本文重点介绍联合身份管理及其用法。有许多身份联合协议,例如安全断言标记语言 (SAML2) Web SSO、OpenID Connect、WS-Trust、WS-Federation 等。虽然我们没有研究任何用于实现联合身份管理的特定协议,我们讨论的概念对于您可能选择用来实现它的任何协议都保持不变。
WSO2 Identity Server 是在 Apache 2.0 许可下分发的开源 IAM 产品。它拥有强大的身份管理和身份联合框架,使其能够在联合身份管理系统中扮演任何身份代理的角色,如本文所述。
本文 |
https://jiagoushi.pro/what-federated-identity-management |
|
---|---|---|
讨论:知识星球【首席架构师圈】或者加微信小号【cea_csa_cto】或者加QQ群【792862318】 | ||
公众号 |
【jiagoushipro】【超级架构师】精彩图文详解架构方法论,架构实践,技术原理,技术趋势。我们在等你,赶快扫描关注吧。 |
|
微信小号 |
【cea_csa_cto】50000人社区,讨论:企业架构,云计算,大数据,数据科学,物联网,人工智能,安全,全栈开发,DevOps,数字化. |
|
QQ群 |
【792862318】深度交流企业架构,业务架构,应用架构,数据架构,技术架构,集成架构,安全架构。以及大数据,云计算,物联网,人工智能等各种新兴技术。加QQ群,有珍贵的报告和干货资料分享。 |
|
视频号 |
【超级架构师】1分钟快速了解架构相关的基本概念,模型,方法,经验。每天1分钟,架构心中熟。 |
|
知识星球 |
向大咖提问,近距离接触,或者获得私密资料分享。 |
|
喜马拉雅 |
路上或者车上了解最新黑科技资讯,架构心得。 |
【智能时刻,架构君和你聊黑科技】 |
知识星球 |
认识更多朋友,职场和技术闲聊。 |
知识星球【职场和技术】 |
微博 |
【智能时刻】 |
智能时刻 |
哔哩哔哩 |
【超级架构师】 |
|
抖音 |
【cea_cio】超级架构师 |
|
快手 |
【cea_cio_cto】超级架构师 |
|
小红书 |
【cea_csa_cto】超级架构师 |
|
谢谢大家关注,转发,点赞和点在看。
上一篇: CSS 复合选择器
推荐阅读
-
[应用安全]什么是联合身份管理?
-
iCloud 切换区域,中国区保留 appStore(更新)--自 2018 年 2 月 28 日起,中国区 iCloud 由云上贵州管理 苹果公司发布的公告 https://support.apple.com/zh-cn/HT208352 关键词 关键部分 受影响的 iCloud 账户:国家或地区设置为 "中国 "的 Apple ID。 iCloud 包含的服务照片、邮件、通讯录、日历、提醒事项、备忘、书签、钱包、钥匙串、云备份、云驱动器、应用程序数据 新条款和条件: 同意仅出于本协议允许的目的并在中国法律允许的范围内使用服务。 云桂洲在提供服务时应使用合理的技能并尽职尽责,但在适用法律允许的最大范围内,我们不保证或担保您通过本服务存储或访问的任何内容不会意外损坏、崩溃、丢失或根据本协议的条款被删除,如果发生此类损坏、崩溃、丢失或删除,我们不承担任何责任。您应自行负责维护您的信息和数据的适当备份。 Apple 和云上贵州有权访问您存储在服务中的所有数据,包括有权根据适用法律相互之间共享、交换和披露所有用户数据(包括内容)。 本协议的解释、效力和履行应适用*法律。对于因本协议引起的或与本协议有关的任何争议,云桂洲和您同意提交中国国际经济贸易仲裁委员会(CIETAC)根据提交仲裁时有效的法律在北京进行具有约束力的仲裁。 由云桂洲管理,用户选择: 停用; ID 到地区; 受 iCloud(由云桂洲运营)条款和条件约束 首先,我想说说我对数据安全的看法。 当我在朋友圈发布通知时,有些朋友回复说国外的操作并没有多安全,或者国外的安全只是相对于国外而言的等等。首先,我非常感谢这些朋友,这让我反思什么是数据安全。以下观点均属个人观点: 国外的月亮一定比国内圆? 这是一个根深蒂固的问题,只要有人说国外的东西比国内好,就会有人嘲笑崇洋媚外。我觉得我们在某些方面应该向国外学习,比如搜索引擎和版权问题。打开百度搜索 "数据安全",第一行肯定是广告。打开谷歌搜索 "数据安全",第一条就是 "数据安全_百度百科" .....各种版权问题大家都明白,支持正版,但不仅客户一心想找免费破解,就连作者也往往没有保护自己劳动成果或产品的想法。但从另一个层面来说,国内的发展和安全,甩国外几条街。没有说哪里好,哪里不好,辩证地去学习更好。 国外也有别有用心的数据泄露,谈何安全? 从加密解密的角度看,自古以来就没有绝对安全的加密,只有相对安全的做法。苹果的棱镜门、微软的 cpu 漏洞,各种参差不齐的被破解案例 ....是的,这的确是一个很好的论据,但凡事都不能只看一面,当年苹果面对FBI破解手机的要求,几经论证,苹果还是拒绝破解。这点拿到国内,只要上面的文件传达下去,还有企业敢说不吗?还敢说不吗? 关于这次iCloud数据迁移个人看法? 把数据迁移到贵州的云端,相当于把手机的所有数据都存储在贵州的云端服务器上。也许访问数据的速度会快很多,但我会把我的iCloud区放到美国,因为我不想数据存在云上贵州后经常接到莫名其妙的电话或短信,更不想因为乱用国外服务器而被请去喝茶。iCloud一个ID,即从中国账号转到美国区,主要用于数据存在美国服务器上。appStore一个ID,除了注册一个中国ID外,专门用来下载应用用,因为国外ID不支持酷狗和网易云等应用。麻烦的是,用了新的 appStore ID 后,当前的应用还得重新下载安装,因为旧的应用 ID 与新的应用 ID 不兼容,安装不了。最后,iCloud迁移后,国内用户使用美国服务器,估计要 "扶墙 "了。 专业步骤: 首先,进行appleID设置,这是前提条件,否则无法选择转移区域! 取消 appleID 的双重认证 取消家庭共享选项 二、窗口下载并安装 icloud 3.0 版
-
基于 NFC 的无线电池管理 BMS - ● 主动读取内部传感器:利用 NFC 技术,BMS 能够主动读取内部传感器的数据 [... 考虑车辆外使用案例中的空闲状态场景:NFC 技术可用于处理闲置状态下的电池组读取,例如在第二次生命转移期间进行存储。 主动诊断读取:在邻近系统中部署了 BMS 的情况下,使用 NFC 技术进行主动诊断读取。 (ii) 系统结构 系统架构如图所示,在建立安全通道之前,需要对设备进行身份验证。数据链路通信层由 NDEF 记录处理,而数据存储可以是离线的,也可以是数据库中的在线存储。活动和空闲状态的诊断读数取决于设备和数据方向,需要与外部 NFC 阅读器进行通信。软件架构分为三层,包括硬件抽象层(HAL)、中间层(中间件)和应用层。HAL 处理硬件驱动组件,中间件执行设备验证,而应用层则由开发人员根据安全漏洞和格式扩展*定义。 为确保安全,系统采用了一个安全模型,为 BMS 和主动诊断读取情况格式化应用数据。安全考虑因素包括设备相互验证、使用安全通道(加密和防篡改)以及确保电池组内读数的安全。 考虑到不同的 BMS 拓扑,包括集中式、调制式、分布式和分散式,系统需要满足设备相互验证和使用安全通道的要求。对于每种拓扑结构,都必须考虑将性能开销降至最低。电池是封闭的,对其进行物理攻击不可行或成本太高。外部攻击可能也很困难。基于对称或非对称加密技术的自动验证可用于保护电池组读数。安全协议在验证阶段和会话密钥确认阶段采用双密钥加密,以抵御攻击。中间件在数据格式验证、确认和处理中发挥关键作用,确保数据传输安全。 (iii) 唤醒模型设计
-
澎湃新闻对话腾讯丁珂:从 "治已病 "到 "治未病",企业需快速构建 "安全免疫力"--丁珂指出,对企业而言,安全不是成本而是生命线 丁珂指出,对企业而言,安全不是成本而是生命线,也是商业 "硬币 "的另一面。在数字智能化的新阶段,发展驱动安全建设已成为普遍共识,企业需要转变安全思维,从被动建设到主动防御,构建一套新的安全范式和框架,以更加积极、主动的安全观来提升数字安全免疫力,以 "治未病 "的理念取代 "治已病",前置安全,快速构建 "安全免疫力"。对 "已病",前置预判,及时应对处置安全风险,才能维护品牌价值,保障健康发展。 与此同时,安全建设还普遍存在 "不知道往哪投、怎么投 "的痛点。对此,腾讯安全提出,企业可以按照数字安全免疫模型的框架进行安全全局部署,重点在业务安全、数据安全、安全运维管理、边界安全、终端安全、应用开发安全等薄弱环节的关键领域注入 "免疫增强针"。 今年进入公众视野的AIGC还在产业化、产品化的过程中,但大量攻击者已经利用它生成攻击脚本、钓鱼邮件,甚至伪造身份进行诈骗。"人工智能本身是否安全,会不会让网络更不安全? 腾讯安全研究认为,AIGC的风险主要集中在 "无法解释 "和 "无法追踪 "的特点上,但这在技术上是能够找到应对方法的。丁珂谈到,AIGC作为生产力的巨大提升,确实会带来更复杂的攻防态势和更大的防御难度。但任何新技术都要经历这样的周期。而法律法规也会随着技术的演进而不断更新,使新技术的发展更加规范和健全。 丁珂认为,随着我国网络安全法律法规体系的不断完善,合规性将给企业推进网络安全带来很大的推动力,并很直观地展现在需求端。未来,伴随着数据要素市场的建立或企业对数据价值的挖掘,也将带动数据安全市场的快速增长。 对于腾讯安全的商业逻辑和运营,丁珂表示,不谋求建立竞争壁垒,而是期望与生态共同发展,腾讯安全希望通过能力开放,实现安全与业务相伴的生态模式。 谈到未来,丁磊表示,安全领域已经进入加速发展期,在蓝海中会持续关注很多新的业务领域,希望孵化出新的商业模式,腾讯安全团队也会持续关注并抓住机会做好产品。 以下为采访实录(在不改变原意的基础上略有删减): 冲浪新闻:当前,以人工智能、大数据等新技术为驱动的第四次工业革命正向纵深推进,给人类生产生活带来深刻变革。而互联网作为新技术的载体,面临的安全挑战不仅数量越来越多,形式也越来越复杂。从互联网安全从业者的角度,腾讯观察到近年来国内外网络安全形势发生了哪些变化?这些变化呈现出怎样的趋势?
-
腾讯视频直播 02-推流-美颜滤镜 同样,腾讯云提供了 setBeautyFilter 方法来设置美颜风格、磨皮程度、美白程度和泛红程度 //style 磨皮风格:0:平滑 1:自然 2:朦胧 //美容级别:0-9。值为 0 时关闭美颜效果。默认值:0,关闭美颜效果。 //美白级别:取值 0-9。值为 0 时,将关闭美白效果。默认值:0,关闭美白效果。 //ruddyLevel:取值范围为 0-9。值为 0 时关闭美白效果。默认值:0,关闭美白效果。 public boolean setBeautyFilter(int style, int beautyLevel, int whiteningLevel, int ruddyLevel);; public boolean setBeautyFilter(int style, int beautyLevel, int whiteningLevel, int ruddyLevel) 滤镜 setFilter 方法可以设置滤镜效果,滤镜本身是一个直方图文件。setSpecialRatio 方法可以设置滤镜的程度,从 0 到 1,越大滤镜效果越明显,默认值为 0.5。 Bitmap bitmap = BitmapUtils.decodeResource(getResources, R.drawable.langman); if (mLivePusher) if (mLivePusher ! = null) { mLivePusher.setFilter(bmp); } 控制摄像头 腾讯云 sdk 默认为前置摄像头(可以通过修改 TXLivePushConfig 的配置函数 setFrontCamera 来修改默认值),调用一次 switchCamera 就切换一次,注意切换摄像头前要确保 TXLivePushConfig 和 TXLivePusher 对象已经初始化。 mLivePushConfig.setFrontCamera(true); // 默认前置摄像头。 mLivePusher.switchCamera; //切换摄像头。 ⑦ 设置徽标水印 腾讯视频云目前支持两种设置水印的方式:一种是在流媒体 SDK 中设置水印,原理是在 SDK 中对视频进行编码前在画面中设置水印。另一种方式是在云端设置水印,即由云端解析视频并添加水印标识。 建议使用 SDK 添加水印,因为在云端添加水印会有问题。下面是添加水印的 SDK 介绍: //设置视频水印 mLivePushConfig.setWatermark(BitmapFactory.decodeResource(getResources,R.drawable.watermark), 10, 10); // 最后两个参数是视频的水印。 //最后两个参数是水印位置的 X 轴和 Y 轴坐标。 mLivePusher.setConfig(mLivePushConfig); 如果需要对水印图像的位置进行模型适配,则需要调用水印规范化接口。 /设置视频水印 mLivePushConfig.setWatermark(mBitmap, 0.02f, 0.05f, 0.2f); //参数为水印图像。 //参数包括水印图像的位图、水印位置的 X 轴坐标、水印位置的 Y 轴坐标和水印宽度。后三个参数的范围是 [0,1]。 // 最后两个参数是水印位置的 X 轴坐标和 Y 轴坐标。 mLivePusher.setConfig(mLivePushConfig); TXLivePushConfig 中的 setHardwareAcceleration 方法可以启用或禁用硬件编码。 if (mHWVideoEncode){ if (mLivePushConfig ! = null) { if (Build.VERSION.SDK_INT < 18){ Toast.makeText(getApplicationContext, "Hardware acceleration failed, current phone API level is too low (min 18)"、 Toast.LENGTH_SHORT).show; mHWVideoEncode = false; } } } } mLivePushConfig.setHardwareAcceleration(mHWVideoEncode ? TXLiveConstants.ENCODE_VIDEO_HARDWARE : TXLiveConstants.ENCODE_VIDEO_SOFTWARE); mLivePusher.setConfig(mLivePushConfig); // 如果您不确定何时启用硬件加速,建议将其设置为 ENCODE_VIDEO_AUTO。 // 默认情况下启用软件编码,但如果手机的 CPU 使用率超过 80% 或帧速率为 10,SDK 将自动切换到硬件编码。 ⑨ 后台推流 在常规模式下,一旦应用程序进入后台,摄像头捕捉数据的能力就会被 Android 禁用,这意味着 SDK 无法继续捕捉和编码音频和视频数据。如果我们什么都不做,故事就会按照下面的脚本发展: 阶段 1(背景剪切后 10 秒 ->)- CDN 无法将视频流传输给观众,因为没有数据,观众看到的是主帧。 阶段 2(10 秒-> 70 秒)--观众一方的播放器因无法接收到直播流而退出,房间里空无一人。 第 3 阶段(70 秒后)--服务器直接断开了推送流媒体的 RTMP 链接,主播需要重新打开直播才能继续。 主播可能只是短暂地接了一个紧急电话,但各云提供商的安全措施会迫使主播的直播提前结束。 1) 设置 setPauseFlag 在开始推流之前,使用 TXLivePushConfig 的 setPauseImg 接口设置一个等待图像,其含义建议为 "主播将暂时离开,稍后再回来"。
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)
-
玩转Java底层:JMX详解 - jconsole与自定义MBean监控工具的实际应用与区别" 在日常JVM调优中,我们熟知的jconsole工具通过JMX包装的bean以图形化形式展示管理数据,而像jstat和jmap这类内建监控工具则由JVM直接支持。本文将以jconsole为例,深入讲解其实质——基于JMX的MBean功能,包括可视化界面上的bean属性查看和操作调用。 MBeans在jconsole中的体现是那些可观察的组件属性和方法,如上图所示,通过名为"Verbose"的属性能看到其值为false,同时还能直接操作该bean的方法,例如"closeJerryMBean"。 尽管jconsole给我们提供了直观的可视化界面,但请注意,这里的MBean并非固定不变,开发者可根据JMX提供的接口将自己的自定义bean展示到jconsole。以下步骤展示了如何创建并注册一个名为"StudyJavaMBean"的自定义MBean: 1. 首先定义接口`StudyJavaMBean`,接口需遵循MBean规范,即后缀为"MBean"且包含getter方法代表属性,如`getApplicationName`,和无返回值的setter方法代表操作,如`closeJerryMBean`。 ```java public interface StudyJavaMBean { String getApplicationName(); void closeJerryMBean(); } ``` 2. 编写接口的实现类`StudyJavaMBeanImpl`,实现接口中的方法: ```java public class StudyJavaMBeanImpl implements StudyJavaMBean { @Override public String getApplicationName() { return "每天学Java"; } @Override public void closeJerryMBean() { System.out.println("关闭Jerry应用"); } } ``` 3. 在代码中注册自定义MBean,涉及的关键步骤包括: - 获取平台MBeanServer - 定义ObjectName,指定唯一的MBean标识符 - 注册MBean到服务器 - 启动RMI连接器服务,以便jconsole能够访问 ```java public void registerMBean() throws Exception { // ... 具体实现省略 ... } ``` 实际运行注册后的MBean,您将在jconsole中发现并查看自定义bean的属性和调用相关方法。然而,这种方式相较于传统的属性/日志查看和HTTP接口,实用性相对有限,可能存在潜在的安全风险。但不可否认的是,JMX及其MBean机制对于获取操作系统信息、内存状态等关键性能指标仍然具有重要价值。例如: 1. **获取操作系统信息**:通过JMX MBean,可以直接获取到诸如CPU使用率、操作系统版本等系统级信息,这对于资源管理和优化工作具有显著帮助。