首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏MongoDB中文社区

    MongoDB 认证那点事

    此时的提示正是说明你当前的操作没有获得许可,使用appdb预创建的用户进行: ? 可以发现,在通过验明身份之后,stats操作的获得了许可。 二、方式 阐述Mongodb支持的几种方式 方式是指Mongodb如何识别接入用户,如何检查权限是否合法的一系列校验机制。 Kerberos的,仅企业版支持 SCRAM-SHA-1 是当前推荐使用的方式,既然如此,有必要上图继续解释: ? 客户端发起一个SCRAM请求; 参数中带上用户名、客户端随机字符串(防止重放攻击); 2. 支持双向认证 三、内部 副本集、分片集群内方式 内部是指 Mongo集群内部节点之间进行访问的方式,比如副本集内主备之间的访问、分片集群内Mongos 与Mongod之间的访问。

    2.7K20发布于 2018-08-14
  • 来自专栏田飞雨的专栏

    浅析 kubernetes 的认证机制

    笔者最初接触 kubernetes 时使用的是 v1.4 版本,集群间的通信仅使用 8080 端口,认证机制还未得到完善,到后来开始使用 static token 作为认证机制,直到 v1.6 时才开始使用 随着社区的发展,kubernetes 的认证机制已经越来越完善,新版本已经全面趋于 TLS + RBAC 配置,但其认证机制也极其复杂,本文将会带你一步步了解。 认证解决的问题是识别用户的身份,是为了解决用户有哪些权限,准入控制是作用于 kubernetes 中的对象,通过合理的权限管理,能够保证系统的安全可靠。 kubernetes 的机制(Authorization) kubernetes 目前支持如下四种机制: Node ABAC RBAC Webhook 下面仅介绍两种最常使用的机制: Node 访问 apiserver 的几种方式 通过上文可以知道访问 apiserver 时需要通过认证以及访问控制三个步骤,认证的方式可以使用 serviceaccounts 和 X509 证书,的方式使用

    1.4K20发布于 2019-12-20
  • 来自专栏田飞雨的专栏

    浅析 kubernetes 的认证机制

    笔者最初接触 kubernetes 时使用的是 v1.4 版本,集群间的通信仅使用 8080 端口,认证机制还未得到完善,到后来开始使用 static token 作为认证机制,直到 v1.6 时才开始使用 随着社区的发展,kubernetes 的认证机制已经越来越完善,新版本已经全面趋于 TLS + RBAC 配置,但其认证机制也极其复杂,本文将会带你一步步了解。 认证解决的问题是识别用户的身份,是为了解决用户有哪些权限,准入控制是作用于 kubernetes 中的对象,通过合理的权限管理,能够保证系统的安全可靠。 kubernetes 的机制(Authorization) kubernetes 目前支持如下四种机制: Node ABAC RBAC Webhook 下面仅介绍两种最常使用的机制: Node 证书,的方式使用 RBAC,访问控制若没有特殊需求可以不使用。

    2.1K00发布于 2019-12-15
  • 来自专栏HUC思梦的java专栏

    JWT对SpringCloud进行认证

    Header:声明令牌的类型和使用的算法 alg:签名的算法 typ:token的类型,比如JWT Header eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 iIsImV4cCI6MTU5MDU4NTc1OCwidHlwZSI6IjIiLCJlbWFpbCI6IjI3MTMxNDk5OEB xcS5jb20iLCJtYXJrIjoiZ2VycnkiLCJ0cyI6IjE1OTA0OTkzNTgifQ Signature ZQba2qY0Q9AzdnmV850Xr1QdOFexLxRrb5qa66mOvZo JWT 不仅可以用于认证,也可以用于交换信息。 JWT的最大缺点是服务器不保存会话状态,所以在使用期间不可能取消令牌或更改令牌的权限。 JWT本身包含认证信息,为了减少盗用,JWT的有效期不宜设置太长。 为了减少盗用和窃取,JWT不建议使用HTTP协议来传输代码,而是使用加密的HTTPS协议进行传输。 oauth2 认证原理: 客户端向服务器申请授权,服务器认证以后,生成一个token字符串并返回给客户端,此后客户端在请求受保护的资源时携带这个token,服务端进行验证再从这个token中解析出用户的身份信息

    78210发布于 2020-09-03
  • 来自专栏Linyb极客之路

    SpringCloud认证的6种方案

    SpringCloud认证方案 开始我们接触的时候权限认证 无从下手,但是当接触之后会发现 权限认证时一件很简单的事情,但是我们 方案众多又该如何选择呢,下面会分别对每种方案进行简单的阐述 含义 5.浏览器Cookie与网关结合方案 6.网关Token和 服务间结合 (还有狠多,不再一一列举) 7.简单案例讲解 详细介绍 1.单体应用下的常用方案 传统的单体应用,一般会写一个固定的认证的包 ,里面包含很多的认证的类,当用户请求时可以利用session的方式,把用户存入session并生成一个sessionid,之后返回客户端。 但是针对微服务(服务之间调用):每个 服务都进行每个用户端 的sso动作,那么每个服务里都会做用户的认证,可能保存每个用户的信息或者每个用户都会和服务打交道,这些情况都会带来非常大的网路开销和性能消耗 网关Token和 服务间结合 我们都知道网关适合做认证,但是在安全层面,我们要求更严格的权限,对于有些项目来说,本身网络跟外部隔离,再加上其它的安全手段,所以我们只要求在网关上就可以了。

    8K30发布于 2019-05-23
  • 来自专栏全栈程序员必看

    kafka 认证方式_kafka实际应用

    前言 kafka官网关于sasl_scram Kafka消费端配置 创建SCRAM Credentials 依赖zk,需要先启动zk,然后在zk中创建存储SCRAM 凭证: cd kafkacluster arg0 arg2 arg3 print each param from “#” 3 修改服务启动配置文件server.properties vim config/server.properties # , 用于账号密码认证, 此处使用管理员账号进行sasl认证, 可以生产所有主题: cp bin/kafka-console-producer.sh bin/kafka-console-producer-admin.sh kafka-console-consumer-admin.sh --bootstrap-server kafkaIP:port --topic test --consumer.config config/consumer.properties 配置后用启动 使用原先的provider和consumer会,必须用的provider/consumer-admin.sh和指定配置文件启动: 服务端部署 在IDE的控制台我们运行是没有问题的,但是在服务端部署的时候遇到

    4K10编辑于 2022-11-17
  • 来自专栏Titan笔记

    SpringBoot整合JWT认证机制实现接口

    什么是JWT认证机制 Json Web Token(缩写JWT)是目前最流行的跨域认证解决方案 session登录的认证方案是看,用户从客户端传递用户名和密码登录信息,服务端认证后将信息储存在session 中,将session_id放入cookie中,以后访问其他页面,服务器都会带着cookie,服务端会自动从cookie中获取session_id,在从session中获取认证信息。 JWT的解决方案是,将认证信息返回个客户端,储存在客户端,下次访问其他页面,需要从客户端传递认证信息回服务器端。 SpringBoot与JWT的整合 通过在SpringBoot中整合JWT,可以构建有认证机制的Restful Web服务,或者实现前后端分离开发中的状态认证(比如和Vue进行整合)。

    3.9K11发布于 2020-07-22
  • 来自专栏互扯程序

    docker私有仓库搭建,证书认证管理

    这篇文章默认你的机器上已经安装了docker,并有了docker的一些基础知识,本文主要讲私有仓库搭建,证书认证管理等内容,关于docker的内容请参考其他文章。 可以使用openssl生成自签名证书,在测试环境可以这么用,但是在生产环境我们还是用CA签发的认证证书吧。证书是收费的(按年),少则一两千,多则七八千。 Registry的管理 Registry提供了一种基础的方式,我们在Register server上,为Registry增加test用户,密码test123 生成密码文件 $ mkdir / docker run --entrypoint htpasswd registry:2 -Bbn test test123 > /auth/htpasswd $ ls auth htpasswd 启动带功能的 提示失败。 那么我们要做的就是先登陆到私有仓库,然后再进行提交。

    3.5K20发布于 2019-05-14
  • 来自专栏阿杜的世界

    微服务架构下的身份认证

    深入聊聊微服务架构的身份认证问题 昨天晚上学习了“聊聊架构”组织的技术分享,做了一点总结如下: 微服务架构下的身份认证.png

    61330发布于 2018-08-06
  • 来自专栏java思维导图

    微服务架构下的安全认证

    为了适应架构的变化、需求的变化,身份认证方案也在不断的变革。面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的方案? 本文将会为大家阐述微服务架构下的安全认证方案。 一、单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证面临的挑战越来越大。 而微服务架构下,一个应用会被拆分成若干个微应用,每个微应用都需要对访问进行,每个微应用都需要明确当前访问用户以及其权限。 尤其当访问来源不只是浏览器,还包括其他服务的调用时,单体应用架构下的方式就不是特别合适了。在为服务架构下,要考虑外部应用接入的场景、用户 - 服务的、服务 - 服务的等多种场景。 ? JWT 更加轻巧,在微服务之间进行访问已然足够,并且可以避免在流转过程中和身份认证服务打交道。

    2.9K30发布于 2019-06-26
  • 来自专栏vue学习

    JWT

    使用 koa-jwt + jsonwebtoken 完成用户功能。 JWT 在 app.js 中引入并使用。 后面的 path 路径是设置匹配不需要的路由或目录,比如我这里设置了所有的 public 开头的、登录 xxxx/login 的请求都不需要。 至此,服务端的主要功能就完成了。 前端设置 在前端,首先我们需要登录的时候获取这个 token,然后把它放到 vuex 中或者本地缓存起来。 至此,我们使用 koa-jwt + jsonwebtoken 完成了用户功能,具体代码实现请移步项目仓库中。

    2.1K20发布于 2020-11-12
  • 来自专栏MCNU云原生

    Docker Registry部署镜像私有仓库及认证

    Registry的官方镜像: docker pull registry:2 2.2、Docker Registry配置 Docker Registry的配置文件使用YAML格式编写,可以通过修改配置文件来启用认证机制 三、Docker Registry认证 Docker Registry是一个中央存储和分发Docker镜像的服务器,其支持多种认证机制,包括基本认证、Bearer Token认证、LDAP认证等 下面我们详细介绍其中的几种常用认证机制,并给出相应的代码配置示例。 3.1、基本认证 基本认证是一种简单的HTTP认证机制,它通过在HTTP头中发送Base64编码的用户名和密码来验证用户的身份。Docker Registry支持基本认证,可以通过配置文件来启用。 以上是常用的几种Docker Registry的认证机制,不同的认证机制在配置文件中的参数有所不同。可以根据实际需求选择相应的认证机制并进行配置。

    2.8K10编辑于 2023-03-17
  • 来自专栏EAWorld

    微服务架构下的安全认证

    为了适应架构的变化、需求的变化,身份认证方案也在不断的变革。面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的方案? 本文将会为大家阐述微服务架构下的安全认证方案。 一、单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证面临的挑战越来越大。 而微服务架构下,一个应用会被拆分成若干个微应用,每个微应用都需要对访问进行,每个微应用都需要明确当前访问用户以及其权限。 尤其当访问来源不只是浏览器,还包括其他服务的调用时,单体应用架构下的方式就不是特别合适了。在为服务架构下,要考虑外部应用接入的场景、用户 - 服务的、服务 - 服务的等多种场景。 ? JWT 更加轻巧,在微服务之间进行访问已然足够,并且可以避免在流转过程中和身份认证服务打交道。

    4.1K60发布于 2018-03-30
  • 来自专栏aoho求索

    聊聊微服务架构中的认证那些事

    应用系统绕不开基础的,微服务架构推荐使用 HTTP 的方式进行服务间通信,这里推荐一篇介绍 HTTP 认证的文章。 上半年参与的项目涉及到 gateway 和 id 权限认证系统,通过系统性的学习与接触,了解很多 HTTP 的那些事。 分享实践的细节,都是通用做法,符合标准协议,不涉及公司机密 本文主要讲如何给第三方服务,即 API 做,而不是用户登录系统。 用户信息传到 Context 中即可 如果业务需要与第三方公司 partner 合作,或是开放 API 给外部,那么需要全面了解 HTTP 的知识。 本文参考了凤凰架构[1] 和 HTTP API 认证授权术[2] 基本概念 的本质:用户 (user / service) 是否有以及如何获得权限 (Authority) 去操作 (Operate)

    3.6K22发布于 2021-11-25
  • 来自专栏个人开发

    告别裸奔,聊聊主流消息队列的认证

    为了能对客户端有一定限制,需要对消息队列进行认证,今天我们就来聊一聊主流消息队列是怎么做认证的。 1 认证 认证是指通过一定手段,对访问用户身份进行校验,只有校验通过的用户,才允许访问。 想要细粒度的控制集群资源,就需要引入模型,常见的模型如下: ACL:Access Control List,也就是访问控制列表,特点是直接把用户和权限关联起来。 2.4 ACL 主流的消息队列都是基于 ACL 来实现的。要实现 ACL(Access Control List) ,首先需要定义好集群中有哪些资源或哪些操作需要做。 3 总结 默认情况下,主流消息队列都是不开启认证的。但在复杂的业务架构中,为了保证队列中数据安全性,必须开启认证。消息队列的认证机制有很多,则主要是通过 ACL 来实现。 希望本文能对你理解消息队列的认证有所帮助。 感谢阅读,如果对你有帮助,请点赞和在看。欢迎加我微信:zhujinjun86。

    58910编辑于 2024-05-30
  • 来自专栏码农那些事!!!

    Spring Gateway、Sa-Token、Nacos 认证方案,yyds!

    大家好,我是不才陈某~ 之前进行、授权都要写一大堆代码。如果使用像Spring Security这样的框架,又要花好多时间学习,拿过来一用,好多配置项也不知道是干嘛用的,又不想了解。 最近看到一个权限认证框架,真是够简单高效。这里分享一个使用Sa-Token的gatewaydemo。 SaResult.error(e.getMessage()); }) ; } } 只需要在gateway中添加一个全局过滤器进行操作就可以实现认证 /操作了。 有时候一个token认证并不能让我们区分用户能不能访问这个资源,使用那个菜单,我们需要更细粒度的。 在经典的RBAC模型里,用户会拥有多个角色,不同的角色又会有不同的权限。

    2.3K12编辑于 2024-01-23
  • 来自专栏Eliauk的小窝

    SpringSecurity源码

    SpringSecurity源码 之前写了一篇SpringSecurity的认证,下面接着来说一下对源码,SpringSecurity有一个专门对过滤器来进行FilterSecurityInterceptor ,他是专门来进行对,下面来根据源码一点点看一下。 这次由于测试我们先写一下基本对数据,基本跟认证时候一样,不过要改一些配置 也就是我们对hello请求需要ADMIN这个角色才能通过访问,所以为了测试我把ADMIN角色都给每个用户 下面我们登陆之后把断点打到 ,然后出来之后就是进行attemptAuthorization,也就是AccessDecisionManager接口对默认实现AffirmativeBased类的decide方法,这个方法就是一个投票器 动态 这就是基本的了,现在问题来了,难到我们每次所有对接口都要去配置文件里边配置吗,很明显笨死了就,但是我们该如何去定制化对设置动态呢。

    1.4K10编辑于 2022-11-15
  • 来自专栏会呼吸的Coder

    Beego JWT

    简介 谈起web应用,登录是必不可少的一步。beego应用当然也需要。今天我结合我目前在做的项目谈一下jwt。 JWT-Auth 其下载命令分别如下: go get github.com/dgrijalva/jwt-go go get github.com/adam-hanna/jwt-auth 因为我是利用jwt-go的 (string) return Phone } 当然了真正的项目中不会这么简单的,现在的方式。只要有人能拿到token。然后完全可以畅通无阻的用任何脚本去访问。 登录认证模块 func AuthenticateUserForLogin(loginName,password string)(*models.AdminUser,error){ if len(password 自此,一个简单的登录做完了。是不是很简单。

    4.3K20发布于 2020-02-17
  • 来自专栏GreenLeaves

    .Net 授权

    在这里总结一下工作中遇到的和授权的方法 ① 固定token的方案 通过在nginx或者代码中写死token,或者通过在限制外网访问的方式已来达到安全授权的方式 ② session方案 分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中 ①,用户输入登录信息,发送身份信息到身份认证服务进行认证 ②,在身份认证服务处通过认证,身份认证服务选择用户储存的且自己需要的信息(比如用户id),使用哈希算法通过一个秘钥生成token ③,用户将Token (C)客户端使用上一步获得的授权,向认证服务器申请令牌。(D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。(E)客户端使用令牌,向资源服务器申请获取资源。 · 客户端将用户名和密码发给认证服务器,向后者请求令牌。 · 认证服务器确认无误后,向客户端提供访问令牌。 (4)客户端模式 · 客户端向认证服务器进行身份认证,并要求一个访问令牌。 · 认证服务器确认无误后,向客户端提供访问令牌。

    2K30发布于 2018-12-25
  • 来自专栏开源

    API 插件上线!用户可自定义

    0.4.0 版本更新主要围绕这几个方面: 分组独立的 UI,支持分组 API API 测试支持继承 API 支持用户自定义插件,仅需部分配置即可发布插件 开始介绍功能之前,我想先和大家分享一下功能设计的一些思考 在大多数情况下,信息一般是: 对大多数 API 生效而不是仅某几个 API 需要 测试使用不需要显示在文档信息中,一般会有个说明文件全局说明此项目下的 API 使用什么 以下三种设计都可以满足在测试前自动的需求 : 信息配置在分组/项目中,内部的 API 从父级继承信息 每个 API 配置独立的 在环境中配置信息,选中后 API 引用环境信息 我们如何判断要将这个功能放在哪里呢? 基于上面考虑,我们的支持在分组配置,我们继续来看看如何使用~ 选中相应的分组-选中,因为值涉及到敏感数据,为了在协作环境中工作时保持此数据安全,我们建议使用全局变量。 所以我们将功能设计成了可拓展的!! 例如这就是官方的 Basic Auth 插件代码,核心逻辑不到 30 行,非常简单易懂。

    1.9K30编辑于 2023-04-06
领券