realm

　　　　　　　　　　　　　　 快速搭建Kerberos服务端及入门使用 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰 版权声明：原创作品，谢绝转载！否则将追究法律责任。 　　 　　Kerberos是一种网络身份验证协议。 它旨在通过使用秘密密钥加密为客户端/服务器应用程序提供强身份验证。 麻省理工学院 可以免费实施该协议。Kerberos也可用于许多商业产品。　 　　尽管有许多配置参数和设置，但配置一个受Kerberos管理的Hadoop集群还是相当简单的。只要清楚地了解在前面部分中介绍的Kerberos概念，就可以自信地使用Kerberos来保护集群。 　　总之，Kerberos是解决您的网络安全问题的解决方案。它通过网络提供身份验证和强大加密工具，帮助您保护整个企业的信息系统。 kerberos的官方地址： http://web.mit.edu/kerberos/ 。 一.搭建Kerberos服务器（node101.yinzhengjie.org.cn） 博主推荐阅读： 　　Kerberos的发布页面：https: // kerberos.org/dist/index.html 　　Kerberos的官方文档：http: // web.mit.edu/kerberos/krb5-1.17/doc/index.html 　

术语 realm 领域的名称， 这是必需的。 resource 应用程序的client-id，每个应用程序都有一个用于标识该应用程序的client-id。 这是必需的。 realm-public-key 领域的公钥，PEM格式。 您可以从管理控制台中获取。 这是可选的，建议您不要进行设置。 如果未设置，则适配器将从Keycloak下载此文件，并且始终会在需要时重新下载它（例如Keycloak旋转其密钥）。 但是，如果设置了realm-public-key，那么适配器将永远不会从Keycloak下载新密钥，因此，当Keycloak旋转其密钥时，适配器会损坏。 auth-server-url Keycloak服务器的基本URL。 所有其他Keycloak页面和REST服务端点都从此派生。 通常采用https：// host：port / auth的形式。 这是必需的。 ssl-required 确保与Keycloak服务器之间的所有通信均通过HTTPS。 在生产中，这应该设置为全部。 这是可选的。 默认值为外部，这意味着外部请求默认情况下需要HTTPS。 有效值为“全部”，“外部”和“无”。 confidential-port Keycloak服务器用于通过SSL / TLS进行安全连接的机密端口。 这是可选的。 默认值为8443。 use-resource-role-mappings

Spring Security 系列还没搞完，最近还在研究。 有的时候我不禁想，如果从 Spring Security 诞生的第一天开始，我们就一直在追踪它，那么今天再去看它的源码一定很简单，因为我们了解到每一行代码的缘由。 然而事实上我们大部分人都是中途接触到它的，包括松哥自己。所以在阅读源码的时候，有时候会遇到一些不是那么容易理解的东西，并不是说这个有多难，只是我们不了解 N 年前的开发环境，因此也就不容易理解某一行代码出现的意义。 所以为了搞透彻这个框架，有时候我们还得去了解之前发生了什么。 这就跟学 Spring Boot 一样，很多小伙伴问要不要跳过 SSM ，我说不要，甚至还专门写了一篇文章（ Spring Boot 要怎么学？要学哪些东西？要不要先学 SSM？ ），跳过了 SSM ，Spring Boot 中的很多东西就无法真正理解。 扯远了。。。 Spring Security 中对 HttpServletRequest 请求进行了封装，重写了 HttpServletRequest 中的几个和安全管理相关的方法，想要理解 Spring Security 中的重写，就要先从 HttpServletRequest 开始看起。 有小伙伴可能会说，HttpServletRequest 能跟安全管理扯上什么关系？今天松哥就来和大家捋一捋，我们不讲 Spring

镜像推送 通过save和load操作 docker save 会输出到文件流中，注意通过id生成的tar,load会丢失tag标签，所以建议都是使用tag进行save -o 输入到文件 docker save xxx -o xxx.tar docker save xxx > tar.gz docker save xxx | gzip > xxx.tar.gz 推荐方式（gzip可以从文件流中进行压缩） docker load 这种方式不会改变镜像的id docker load -i 通过私有registry 如果报错server gave HTTP response to HTTPS client，因为在新的版本docker的registry都是通过https，需要在docker客户端增加配置 /etc/docker/daemon.json # 设置为目标registry的地址 "insecure-registries":["172.21.104.195:5000", "registry.docker.com:5000"] sudo systemctl daemon-reload sudo systemctl restart docker docker tag xxx ip:port/xxx docker login ip:port docker push ip:port/xxx

一、问题 在我的文章 【我的Android进阶之旅】Android 混淆文件资源分类整理之二：将混淆文件拆分成更小粒度的混淆文件 中有介绍一篇文章 生成带混淆配置的aar库 里面有介绍如何生成带配置的aar库 https://github.com/realm/realm-java/tree/master/realm/realm-library 定义混淆配置 引用混淆配置 https://github.com/realm/realm-java/blob/master/realm/realm-library/build.gradle 来源： oschina 链接： https://my.oschina.net/u/4360442/blog/4320116

前言 说明一下需求，最近做的平台，有多张用户表，怎么根据不同用户登录去执行自己查询不同数据库并实现认证的业务逻辑呢？ 博主参与的产品开发进入阶段性完成期，有时间将过程中遇到的相关问题一一总结。 总结 实现本需求，首先是从Subject入手，它是完成shiro登录过程的入口，login(UsernamePasswordToken)方法完成用户名密码传递，后面自己实现Realm去认证登录，关键就在如何区分这些用户名密码是对应哪个数据库表，若有一个状态去判断它们，则可以解决问题。 设计上的反思 其实从实际参与这个大产品开发之后，越来越发现，它不便于我们对各类用户的管理，虽然做了很多针对shiro的扩展去实现自己想要的功能，但渐渐明白为什么shiro不提供这样的解决方案。 这里，博主也建议，用户表可以有多个，但登录认证的表其实只保留一个就好，将你的多Realm抽象出来一个关系表映射，将各种状态加入，登录等认证交由统一维护，具体信息查询等封装抽象，下面做对应实现即可，这样才应该是跨平台的，以后也只需要存储跟别的平台的用户关系绑定，就完成了登录。 转载内容 https://blog.csdn.net/visket2008/article/details/78539334 码云传送门 https://gitee.com/visket/cloud 来源： oschina 链接： https:/

一、shiro 内部结构 1、shiro 包含的组件 shiro主要包括认证器（Authenticator），授权器（Authrizer），session会话管理（SessionManager），加密处理（Cryptography），记住我（remember me），对权限的缓存（CacheManager） 2、shiro 各组件介绍 Subject：主体，可以理解为 与应用交互的用户 subject 里包含用户的所有信息 如 用户信息，用户角色，用户权限，是否登录等等； SecurityManager：安全管理器 shiro通过securityManager 管理着整个shiro各个模块。 Authenticator：认证器，负责认证用户是否是合法用户 Authenticator具体认证过程 是通过realm 来处理用户是否是合法用户； Authrizer：授权器， 负责给用户授权 Authrizer 具体授权是通过realm 来获取用户所具有的权限； Realm：可以有1个或多个Realm，也可以自定义realm realm在shiro框架中很重要 负责处理用户的认证信息和授权信息； SessionManager：负责session的管理； SessionDAO：对session的curd操作； CacheManager：可以对用户权限信息进行缓存 提供性能；

Ceph天生带两地三中心概念，所谓的双活就是两个数据中心（multi-site）。Ceph两数据中心可以在一个集群也可以在不同的集群中。架构图（它山之石）如下所示： 1、环境信息 2、创建Master zone 在一个multi-site配置当中的所有rgw都会接收来自master zone group中的mater zone对应的ceph-radosgw的相关配置。因此必须先配置一个master zone group和一个master zone。 2.1 创建realm 一个realm包含multi-site配置中的zone groups以及zones，并且在该realm中作为全局唯一的名称空间。在主集群任意一个节点上执行下面的命令创建： [root@ceph01 ~]# radosgw-admin -c ceph1 realm create --rgw-realm=xzxj --default { "id": "0f13bb55-68f6-4489-99fb-d79ba8ca959a", "name": "xzxj", "current_period": "02a14536-a455-4063-a990-24acaf504099", "epoch": 1 } realm只用于本集群的话，则添加--default选项，radosgw-admin就默认会使用该realm。 2.2