Keycloak是一款开源的认证授权平台,在Github上已有9.4k+Star。Keycloak功能众多,可实现用户注册、社会化登录、单点登录、双重认证 、LDAP集成等功能。
Realm翻译成中文为领域。用来逻辑隔离一些特定空间,有点多租户的感觉,不同的Realm之间互相隔离,有各自的特色配置,互不影响。
我们在Keycloak Admin Console中的所有操作都有特定的Restful API,被统称为Keycloak Admin REST API。而 Keycloak Admin Client正是对Keycloak Admin REST API的Java HTTP客户端封装。我们只需要引入下面的依赖就可以集成了:
在Spring Security集成Keycloak 适配器时需要引入一些额外的配置属性。一般我们会把它配置到Spring Boot的配置文件中。
Keycloak对流行的Java应用提供了适配器。在系列文章的上一篇我们演示了针对Spring Boot的安全保护,用的就是适配器的一种。Keycloak同样提供Spring Security的适配器,后续的几篇文章我们就来共同学习Spring Security适配器的使用。 ❝ Keycloak的安装可参考前面的系列教程。 适配器集成 在Spring 应用中我们集成keycloak-spring-security-adapter: <dependency> <groupId>org.keycloa
我们在上一篇初步尝试了keycloak,手动建立了一个名为felord.cn的realm并在该realm下建了一个名为felord的用户。今天就来尝试一下对应的Spring Boot Adapter,来看看keycloak是如何保护Spring Boot应用的。
登录及身份认证是现代web应用最基本的功能之一,对于企业内部的系统,多个系统往往希望有一套SSO服务对企业用户的登录及身份认证进行统一的管理,提升用户同时使用多个系统的体验,Keycloak正是为此种场景而生。本文将简明的介绍Keycloak的安装、使用,并给出aspnetcore 应用如何快速接入Keycloak的示例。
单体服务如果想要突破到高并发服务就需要升级为集群服务。同时集群化也为高可用打下了坚实的基础。纵观现在比较流行的服务或者中间件,不管是RabbitMQ还是redis都提供了集群的功能。
在本文中,我们将介绍安装、配置Keycloak服务器的基础知识,如何将Spring Boot应用程序**和Keycloak服务器连接起来,以及在Spring Security下如何使用它。
API Server 作为 Kubernetes 的网关,是用户访问和管理资源对象的入口。对于每个访问请求, API Server 都需要对访问者的合法性进行检查,包括身份验证、权限验证等等。Kubernetes 支持多种身份验证的方式,本文将对 OpenID Connect 认证进行介绍。
最近想要打通几个应用程序的用户关系,搞一个集中式的用户管理系统来统一管理应用的用户体系。经过一番调研选中了红帽开源的Keycloak,这是一款非常强大的统一认证授权管理平台。之所以选中了Keycloak是基于以下几个原因。
本文中我们将会为 Kuebernetes 构建一个完备的单点登录系统,这个系统会为 kubectl、Web 应用的 Ingress,以及 Docker 镜像仓库和 Gitea 提供服务,本文中会涉及多数单点登录模型,对于 Gitlab、Kibana、Grafana 等其它应用,应该也是适用的。
安全性是现代软件系统中非常重要的元素。这是一个巨大的话题,它包含了很多不同的方面,不应该是事后才想到的。要把每件事都做好是很困难的,特别是在分布式微服务体系结构的环境中,尽管如此,在本教程的这一部分中,我们将讨论最关键的领域,并就如何处理它们提出建议。
简单来说,以google授权为例,一般就是通过用户授权页面登录google账号,再跳转用code换取到相应权限的token,就可以代表用户去发起一些google api的请求。
上一篇文章简单介绍了Keycloak,反响不错。看来大家都对这个东西感兴趣,今天就来进一步的体验Keycloak,让我们对它有一个直观的认识,然后逐步深入,把它的设计理念和概念各个击破。
单页应用程序(也称为基于浏览器的应用程序)在从网页加载 JavaScript 和 HTML 源代码后完全在浏览器中运行。由于浏览器可以使用整个源代码,因此它们无法维护客户端机密的机密性,因此这些应用程序不使用机密。因为他们不能使用客户端密码,所以最好的选择是使用 PKCE 扩展来保护重定向中的授权代码。这类似于也不能使用客户端密码的移动应用程序的解决方案。
Keycloak是一款主流的IAM(Identity and Access Management 的缩写,即“身份识别与访问管理”)开源实现,它具有单点登录、强大的认证管理、基于策略的集中式授权和审计、动态授权、企业可管理性等功能。
单点登录(Single Sign On)简称为SSO,用户只需要登录认证中心一次就可以访问所有相互信任的应用系统,无需再次登录。
基于角色的访问控制(RBAC)为服务提供服务级别和方法级别的访问控制。RBAC政策是附加的。依次检查策略。根据操作以及是否找到匹配的策略,允许或拒绝请求。
此前,笔者曾写过一篇《OpenLDAP 安装初体验》尝试使用 Docker 一键式部署 OpenLDAP。其中,对 LDAP 协议也作了一定的基础入门,但对如何利用 LDAP 来为各式各样的应用提供统一认证服务还未有深入的实践。本文就打算以 LDAP 为中心集成到团队内部的各类第三方系统或服务中。例如,团队内部常用的私有化代码托管服务 Gitlab、网盘服务 Nextcloud、缓存加速服务 Squid、访问内部集群的专用 OpenVPN 服务、内部团队知识库服务 Dokuwiki、内部代码库及容器镜像服务 Nexus3 等等。
在微服务时代,用户需要在多个应用程序和服务之间进行无缝切换,同时保持其登录状态。我们可以通过单点登录(SSO)或者 OAuth2.0 等身份验证和授权协议来实现这一目标。
上一文我们对Keycloak保护Spring Boot应用进行了实操。让大家见识到了Keycloak的强大。为了掌握Keycloak就必须对OpenID Connect(OIDC)协议进行了解。OIDC是OAuth 2.0的一个扩展协议。它为什么要扩展OAuth 2.0?在搞清楚这个问题之前我们需要再回顾一下OAuth 2.0协议。
[Hea01a7018ebc445787a9789dde52b592p.png]
Istio帮助使“服务网格”概念变得更加具体和可访问,随着Istio 1.0的最新发布,我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在InfoQ之前的一篇文章中很好地介绍了Istio和服务网格,因此我想借此机会介绍Istio的一个特定领域,它将为云服务和应用程序的开发人员和运营商带来巨大的价值:安全性
“ OAuth 2.0 provides specific authorization flows for web applications, desktop applications, mobile phones, and smart devices.”
最早使用linux是在高三时,买了两张盗版的linux安装盘,安装的RedHat什么版本记不清楚了。 那时候安装是需要选择精简安装和完整安装,如果选了精简安装,很多应用就没有了。所以那时很苦恼,全装占磁盘,不全安装,要学习某个应用,又得重新拿B盘安装,我对装应用的印相一直停留在那个时候。
1月份和2月份GitHub上最热门的Java开源项目排行已经出炉啦,一起来看看上榜详情
众所周知,K8s 的权限管理体系 (不熟悉的盆友可以跳转至《Kubernetes 安全机制解读》) 中,可以将 RoleBinding 绑定到 ServiceAccount、User、Group 上来实现权限分配。
密钥交换,也有称作密钥协商,这套机制,最主要的作用是用来得到通信双方的临时会话密钥。
安全外壳协议(SSH)是一种网络协议,用于在不安全的网络上提供安全的通信。SSH通过在客户端和服务器之间建立安全通道,确保数据的机密性和完整性,广泛应用于远程登录和文件传输。本文将深入探讨SSH中的三个关键组件:密钥交换(Kex)、主机密钥(HostKey)和消息认证码(HMAC),以及它们在维护通信安全中的作用。
概述: WCF的安全传输主要涉及认证、消息一致性和机密性三个主题。WCF采用两种不同的机制来解决这三个涉及传输安全的问题,一般将它们成为不同的安全模式,即Transport安全模式和Message安全模式。 一、Transport安全模式 Transport安全模式利用基于传输层协议的安全机制解决传输安全涉及的三个问题(认证、消息一致性和机密性)。 TLS/SSL是实现Transport安全最常用的方式 1.TLS、SSL、HTTPS (1)SSL->SSL1.0->SSL2.0->SSL3.0->TLS
如何让您的开发人员使用刷新令牌来获取新的访问令牌。如果您的服务随访问令牌一起发出刷新令牌,则您需要实现此处描述的刷新授权类型。
本文概述了OAuth 2.0协议。它讨论了OAuth 2.0实现过程中涉及的不同参与者和步骤。
[由于业务需要,最近在云上新购买了一批centos7.0的服务器,用脚本批量添加了用户(脚本请见我之前的博客/秘钥认证用户自动控制:]](http://my.oschina.net/pwd/blog/388254)[),加完秘钥之后发现,但是secureCRT抛出了一下异常。]
首先,HTTPS 并不是一个新的协议,而是 HTTP + SSL/TLS,即 SSL(Security Socket Layer)和 TLS(Transport Layer Security) 的缩写。但其实作为 SSL 的继任者,TLS 已经完全替代了 SSL,只是大概还是习惯使用 SSL 这个名词。为了严谨,后续都会继续使用 TLS。
使用强客户端身份验证(例如 client_assertion / client_token)
攻击者可以通过复制节点进行DOS攻击,或者生成不合法的XML导致服务器端逻辑的中断。攻击者也可以操纵外部实体,导致打开任何文件或TCP连接端口。XML数据定义的中毒也可以导致运行流程的改变,助攻击者获取机密信息。
WCF的安全体系主要包括三个方面:传输安全(Transfer Security)、授权或者访问控制(Authorization OR Access Control)以及审核(Auditing)。而传输安全又包括两个方面:认证(Authentication)和消息保护(Message Protection)。认证帮助客户端或者服务确认对方的真实身份,而消息保护则通过签名和加密实现消息的一致性和机密性。WCF采用两种不同的机制来解决这三个涉及到传输安全的问题,我们一般将它们称为不同的安全模式,即Transpor
HTTPS 是在HTTP(Hyper Text Transfer Protocol)的基础上加入SSL(Secure Sockets Layer),在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。以此避免HTTP的明文传输容易被窃听、不验证身份容易被伪装、无法验证报文完整性容易被篡改等问题。除了被广泛用于互联网上安全敏感的通讯,大部分网站也正在广泛采用 。
这部分主要涉及企业级应用的安全问题,一般来说安全框架主要提供3个典型的安全行为:认证、授权和审核。除了典型的安全问题,对于一个以消息作为通信手段的分布式应用,还需要考虑消息保护(Message Pro
圣诞节很快就要到了,对渗透测试的热情仍然有增无减。我们SINE安全在此为用户认证登录安全制定一个全面的检测方法和要点Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。
HTTPS(Hypertext Transfer Protocol Secure)是HTTP(Hypertext Transfer Protocol)的安全版本,用于在用户的Web浏览器和网站之间传输数据。HTTPS在传输过程中对数据进行加密,提供了一个安全且私密的通信通道。以下是HTTPS的工作原理的简化解释:
当开发人员访问您的网站时,他们将需要一种方法来创建新的应用程序并获取凭据。通常,在他们可以创建应用程序之前,您会让他们创建一个开发者帐户,或代表他们的组织创建一个帐户。
阅读本文前需要了解 OAuth 2.0 授权协议的相关内容, 可以参考我的上一篇文章 OAuth 2.0 的探险之旅[1]。
随着互联网的快速发展,网络安全问题变得越来越重要。不断涌现的威胁和攻击手段对我们的信息和数据构成了严重的威胁。为了确保网络安全,我们需要采取一系列安全措施,其中安全协议设计起着至关重要的作用。本文将探讨网络安全的威胁和攻击类型,并深入了解如何设计有效的安全协议来保护我们的网络。
平台团队的工作流程和检查表,用于在其平台中构建安全性、流水线、预配、连接性、编排和可观察性。
咦咦咦,各位小可爱,我是你们的好伙伴——bug菌,今天又来给大家普及通信协议相关知识点了,别躲起来啊,听我讲干货还不快点赞,赞多了我就有动力讲得更嗨啦!所以呀,养成先点赞后阅读的好习惯,别被干货淹没了哦~
领取专属 10元无门槛券
手把手带您无忧上云