关于sso:Casdoor-开始

Casdoor 是一个基于 OAuth 2.0 / OIDC 的中心化的单点登录(SSO)身份验证平台,简略来说,就是 Casdoor 能够帮你解决用户治理的难题,你无需开发用户登录、注册等与用户鉴权相干的一系列性能,只需几个步骤进行简略配置,与你的主利用配合,便可齐全托管你的用户模块,简略省心,功能强大。 官网: https://casdoor.org/代码: https://github.com/casdoor/casdoor官网有 demo 体验,及文档。本文是按照文档「服务器装置」「应用 Docker 运行」于 Ubuntu 22 上的实际记录。 装置环境Go 1.17+Node.js LTS (16或14)Yarn 1.x装置 Go# 下载,根据零碎抉择 Linux x86-64 的公布包curl -O -L https://go.dev/dl/go1.20.4.linux-amd64.tar.gz# 解压tar -xzvf go1.20.4.linux-amd64.tar.gz# 重命名,带上版本号mv go go1.20.4.linux-amd64# 软链,便于配置或切版本sudo ln -sfT `pwd`/go1.20.4.linux-amd64 /usr/local/go# 配置,GOPATH 用本人的工作目录cat <<-EOF >> ~/.bashrc# goexport GOROOT=/usr/local/goexport GOPATH=\$HOME/Codes/Goexport PATH=\$GOROOT/bin:\$GOPATH/bin:\$PATHEOF# 查看go versiongo env装置 Node.js# 下载,选了以后最新的 LTS 版本,可用curl -O -L https://nodejs.org/dist/v18.16.0/node-v18.16.0-linux-x64.tar.xz# 解压tar -xvf node-v18.16.0-linux-x64.tar.xz# 软链,便于配置或切版本sudo ln -sfT `pwd`/node-v18.16.0-linux-x64 /usr/local/node# 配置,GOPATH 用本人的工作目录cat <<-EOF >> ~/.bashrc# nodeexport NODE_HOME=/usr/local/nodeexport PATH=\$NODE_HOME/bin:\$PATHEOF# 查看node -vnpm -v装置 Yarnnpm install yarn -g# 查看yarn -v装置 MySQLsudo apt update -y# 装置sudo apt install mysql-server -y# 查看systemctl status mysql.service# 或启动systemctl start mysql.service配置 MySQL: ...

May 14, 2023 · 4 min · jiezi

关于sso:体验开源IAM系统-authelia

开源调研authelia 是目前势头最猛的,star数最高的开源 IAM 零碎。 参考文档 https://github.com/topics/ssohttps://medium.com/@devops.en...https://github.com/kdeldycke/...https://sendoh-daten.medium.c...https://news.ycombinator.com/...https://blog.csdn.net/u010381...https://blog.csdn.net/little_...https://supertokens.com/blog/...配置 lite部署参考:https://www.yoyoask.com/?p=4619 为了体验成果,咱们须要批改以下内容 批改 notifier 为本地文件减少 identity_providers 生成 issuer_certificate_chain 和 issuer_private_key生成 client 的 secret批改 client 的 scopes,减少 offline_access批改 redirect uris# 进入 lite 目录cd examples/compose/lite# 启动服务docker-compose up -d# 敞开服务docker-compose stop# 重启服务docker-compose restart# 察看日志docker logs -f authelia增加 oauth client下载代码:https://github.com/authelia/o... # 编译go build .# 启动# id 和 secret 要和 identity_providers.clients.[].id 和 secret 统一# scopes 要减少 offline_access,这样能够获取 refresh token# -i 要和 docker-compose 里 authelia lables 外面 host 统一./oidc-tester-app -i https://authelia.example.com --id myapp --secret fu4HCuhk5npiKawlQcyuj1Bs8hnvHrIfu1uj2J0XroKwq1thPVq8JgVXWE4uuifSeBfbZaAn --scopes openid,offline_access,profile,email,groups 成果public ...

October 26, 2022 · 1 min · jiezi

关于sso:实战模拟│单点登录-SSO-的实现

什么是单点登录单点登录: SSO(Single Sign On) 用户只需登录一次,就可拜访同一帐号平台下的多个利用零碎。比方阿里巴巴这样的大团体,旗下有很多的服务零碎,比方天猫,淘宝,1688等等,如果每个子系统都须要用户进行登录认证,预计用户会被烦死。而 SSO 是一种对立认证和受权机制,去解决这种反复认证的逻辑,进步用户的体验。 单点登录的凭证由单点登录的原理,能够看进去,最重要的就是这个通用的登录凭证 ticket 如何取得而实现 ticket 多利用共享次要有三种形式:父域加密 Cookie、用户认证核心、Localstorage 父域 Cookie 形式用户在登录父利用后,服务端返回用户登录后的 cookie,客户端将该 cookie 保留到父域中这个 cookie 最好通过加密解决,因为 Cookie 自身并不平安这种加密算法只有服务端才能够晓得,服务端的解密算法不能暴漏放在父域中,次要是因为 Cookie 不能跨域实现免登,放到父域中能够解决跨域的问题父域也就是 domain 要设置成主域名,而非二级域名,这样二级域名就能够应用同一个 Cookie 了// 如果某个平台有三个利用,别离是:// 门户利用:www.autofelix.com// 商城利用:shop.autofelix.com// 领取利用:pay.autofelix.comdocument.cookie = "ticket=xxxxxx;domain=.autofelix.com;path=/ 用户认证核心形式应用一个认证核心,用来专门负责解决登录申请用户核心不解决业务逻辑,只是解决用户信息的治理以及受权给第三方利用第三方利用须要登录的时候,则把用户的登录申请转发给用户核心进行解决,用户处理完毕返回凭证,第三方利用验证凭证,通过后就登录用户。流程是用户拜访利用零碎,利用零碎先检查用户是否有 Ticket,如果没有,则阐明用户在该利用上尚未登录,跳转到用户核心,通过用户核心的 Cookie 去判断用户是否在其余利用上进行了登录如果认证核心发现用户尚未在其余任何利用上执行过登录,则提醒用户执行登录操作,期待用户登录后,生成 Tickcet,并让 Ticket 拼接在 URL 上,重定向回利用零碎当利用零碎拿到 Ticket 后,将从新向用户认证核心发动验证,避免该 Ticket 是用户伪造,验证胜利后,记录用户登录状态,并将 Ticket 写入到以后利用的 Cookie 中而当用户拜访该利用零碎时,就都会带上以后的 Ticket,也就能失常拜访服务了 localstorage形式当用户在一个利用下登录后,前端能够通过 iframe+postMessage() 形式,将同一份 Ticket 保留到多个域名下的 LocalStorage 中然而这种形式齐全由前端管制,后端仅仅须要将用户登录胜利后的 Ticket 返回给前端解决即可这样其实也实现了,多利用下单点登录的问题,并且反对跨域

July 8, 2022 · 1 min · jiezi

关于sso:Authing-团队管理-Wechaty-机器人-无限可能

用户故事其实用 Authing 团队治理 + Wechaty 机器人可能实现很多性能,来进步传统人事管理的效率。甚至还能够做一些数据的剖析、统计,来辅助决策。这里我就列了几个简略的事实场景,心愿能帮忙大家了解。 以 Authing 作为上游数据源同步数据到其余平台,后期为飞书和微信。创立完用户后,用户能够通过手机号间接登录飞书。集体微信增加 Wechaty Bot,通过音讯发送手机号进行用户关联绑定。在 Authing 中创立组织架构,同步对应创立飞书的部门和微信的群组。同步删除飞书用户、微信群移除群聊。 原有飞书组织接入微信飞书作为上游数据源。微信增加 Wechat Bot,通过音讯发送手机号进行用户关联绑定。在飞书中增加、删除用户,(先设置好同步频率,比方每 10 分钟查看一次),对应微信群中进行邀请退出或者移除。在飞书中进行部门(组织)治理,同步在微信中创立对应的群聊(扁平化,无层级),并同步群成员治理(增加/移除)。 原有微信群组并接入飞书抉择一个全员微信群进行接入,首先 Wechaty Bot 会为该群中所有成员创立 Authing 用户。微信增加 Wechaty Bot 或者 @提及的形式发送音讯手机号进行用户关联绑定,绑定手机号的成员能够通过该手机号进行飞书的登录。在原有微信大群中增加、删除用户,(先设置好同步频率,比方每 10 分钟查看一次),对应飞书用户增加或者移除。 撸一个 Wechaty Authing 的插件也能够通过插件的介绍页面间接去理解插件的应用阐明。该插件开源代码仓库位于: https://github.com/Authing/we... 设计思路该插件该当封装好了一些罕用的办法,来买通 Wechaty 与 Authing 之间的连贯装备了一些好用的工具类办法,进步开发效率具备肯定的可扩展性,不便有一些非通用需要的实现实现在着手开发这个插件之前,我是别离以 Wechaty 作为用户上游和 Authing 用户池作为用户上游做了两个 MVP 我的项目。而后通过我的项目中的一些办法和性能,来实现这个插件的最后版本。 列举一下 Wechaty 作为用户上游时,须要用到的一些办法: 查看微信好友或群内的用户是否曾经存在 Authing 用户池查看微信用户是否绑定了 Authing 账号(次要为手机号)当邀请、移除群成员时候,对应创立、删除 Authing 用户再列举一下将 Authing 作为用户上游时,须要用到的一些办法: 查看微信的好友申请、以及音讯,判断是否为 Authing 用户(通过音讯规定手机号校验)将微信号与 Authing 用户进行关联绑定 (通过音讯规定手机号校验)而后这个过程中,常常会有两个用户列表的比拟,一个是 Wechaty Contact[] 列表,一个是 Authing User[] 列表,去判断联系人是不是 Authing 用户、判断联系人有没有被邀请入群、或者判断联系人是否须要被移除群聊。 ...

January 21, 2022 · 5 min · jiezi

关于sso:你可能想要集成一个-Discourse-论坛使用-Authing-SSO-零代码帮你实现单点登录

Authing 是什么?Authing 是国内首款以开发者为核心的全场景身份云产品,集成了所有支流身份认证协定,为企业和开发者提供欠缺平安的用户认证和拜访治理服务。 以「API First」作为产品基石,把身份畛域所有罕用性能都进行了模块化的封装,通过全场景编程语言 SDK 将所有能力 API 化提供给开发者。同时,用户能够灵便的应用 Authing 凋谢的 RESTful APIs 进行性能拓展,满足不同企业不同业务场景下的身份治理需要。 传统零碎 SSO 单点登录革新首先,须要对原有零碎的用户体系进行革新,使其可能适应通用的用户认证标准协议(如 OAuth)。如果零碎体量较大,甚至还须要思考将原有业务中的用户体系抽出,专门做成单点登录的用户核心。须要进行设计、编码、测试、降级、扩容等一系列简单的开发运维操作,才可能实现。 该形式耗时间,耗精力,耗老本,危险大(须要在业务畛域之外一直去踩坑)。 Authing SSO 集成如果您的利用是基于 Authing 提供的身份零碎进行开发,那么祝贺你,能够应用较少的代码(或者配置)即可轻松几步,疾速实现单点登录的集成。 该形式低成本,毋庸额定设计和开发,采纳标准协议,轻松买通。 Discourse 装置参考资料: Discourse 官网 Docker 仓库: https://github.com/discourse/...装置指南文档: https://github.com/discourse/...倡议将 Discourse Docker 仓库 Fork,并在本地先进行开发调试确认无误后再进行产品环境的装置。上面是简略的装置步骤阐明及配置中常见问题的 FAQ。 留神:请在 Linux 服务器或者 macOS 下进行装置(Windows 须要自行摸索一下)。 拉取 Discourse Docker 仓库git clone https://github.com/discourse/discourse_docker.git /var/discoursecd /var/discourse应用自动化配置脚本: ./discourse-setup非 root 用户的话,须要在后面加 sudo 运行。依据提醒一步一步输出配置项,实现装置配置。默认的配置在本地运行的时候大概率会运行不起来。 关上 containers/app.yml 配置文件进行配置调整,如果手动配置,也能够执行: cp samples/standalone.yml containers/app.yml复制一个示例模板作为开始。 利用配置在开始配置之前,先确保域名曾经绑定到服务器上(DNS 中的 A 记录绑定),或者本地批改 /etc/hosts 文件(不要应用 example.com 或者须要强制 https 的域名后缀作为本地开发调试,如: .app、.dev等)。 ...

January 15, 2022 · 4 min · jiezi

关于sso:关于Authingcn在百度搜索关键字MaxKey单点登录认证系统侵权的通告

MaxKey单点登录认证零碎,谐音马克思的钥匙寓意是最大钥匙,是业界当先的企业级IAM身份治理和认证产品,反对OAuth 2.x/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议,提供简略、规范、平安和凋谢的用户身份治理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限治理和资源管理等。 MaxKey单点登录认证零碎是Dromara开源组织旗下的产品,并在中国版权保护核心申请软件著作权,软件著作权软件名称为MaxKey单点登录认证零碎,简称MaxKey单点登录。 2021年11月20日在百度搜寻“MaxKey单点登录认证零碎”关键字,发现以下的搜寻后果: 后果1 后果2 后果3 Authing(北京蒸汽记忆科技有限公司)旗下有产品和Dromara开源组织的MaxKey单点登录认证零碎属于竞争关系,Authing知法犯法,误导了MaxKey单点登录认证零碎的客户,侵害了Dromara开源组织的权利,触犯了《中华人民共和国著作权法》。 2021年11月21日,分割Authing的负责人告诉其进行整改 2021年11月28日问题并未失去解决。 2021年11月29日,通过邮件《10910-对于maxkey单点登录认证零碎关键字搜寻的问题》告知百度公司存在的问题,同时依照百度要求提交软件著作权并申请百度品牌爱护,爱护的品牌为MaxKey单点登录认证零碎(MaxKey单点登录)。 截至2021年12月15日问题还未失去解决,特发此通告。

December 15, 2021 · 1 min · jiezi

关于sso:单点登录SSO看这一篇就够了

背景在企业倒退初期,企业应用的零碎很少,通常一个或者两个,每个零碎都有本人的登录模块,经营人员每天用本人的账号登录,很不便。 但随着企业的倒退,用到的零碎随之增多,经营人员在操作不同的零碎时,须要屡次登录,而且每个零碎的账号都不一样,这对于经营人员 来说,很不不便。于是,就想到是不是能够在一个零碎登录,其余零碎就不必登录了呢?这就是单点登录要解决的问题。 单点登录英文全称Single Sign On,简称就是SSO。它的解释是:在多个利用零碎中,只须要登录一次,就能够拜访其余相互信任的利用零碎。 如图所示,图中有4个零碎,别离是Application1、Application2、Application3、和SSO。Application1、Application2、Application3没有登录模块,而SSO只有登录模块,没有其余的业务模块,当Application1、Application2、Application3须要登录时,将跳到SSO零碎,SSO零碎实现登录,其余的利用零碎也就随之登录了。这完全符合咱们对单点登录(SSO)的定义。 技术实现在说单点登录(SSO)的技术实现之前,咱们先说一说一般的登录认证机制。 如上图所示,咱们在浏览器(Browser)中拜访一个利用,这个利用须要登录,咱们填写完用户名和明码后,实现登录认证。这时,咱们在这个用户的session中标记登录状态为yes(已登录),同时在浏览器(Browser)中写入Cookie,这个Cookie是这个用户的惟一标识。下次咱们再拜访这个利用的时候,申请中会带上这个Cookie,服务端会依据这个Cookie找到对应的session,通过session来判断这个用户是否登录。如果不做非凡配置,这个Cookie的名字叫做jsessionid,值在服务端(server)是惟一的。 同域下的单点登录一个企业个别状况下只有一个域名,通过二级域名辨别不同的零碎。比方咱们有个域名叫做:a.com,同时有两个业务零碎别离为:app1.a.com和app2.a.com。咱们要做单点登录(SSO),须要一个登录零碎,叫做:sso.a.com。 咱们只有在sso.a.com登录,app1.a.com和app2.a.com就也登录了。通过下面的登陆认证机制,咱们能够晓得,在sso.a.com中登录了,其实是在sso.a.com的服务端的session中记录了登录状态,同时在浏览器端(Browser)的sso.a.com下写入了Cookie。那么咱们怎么能力让app1.a.com和app2.a.com登录呢?这里有两个问题: Cookie是不能跨域的,咱们Cookie的domain属性是sso.a.com,在给app1.a.com和app2.a.com发送申请是带不上的。sso、app1和app2是不同的利用,它们的session存在本人的利用内,是不共享的。 那么咱们如何解决这两个问题呢?针对第一个问题,sso登录当前,能够将Cookie的域设置为顶域,即.a.com,这样所有子域的零碎都能够拜访到顶域的Cookie。咱们在设置Cookie时,只能设置顶域和本人的域,不能设置其余的域。比方:咱们不能在本人的零碎中给baidu.com的域设置Cookie。 Cookie的问题解决了,咱们再来看看session的问题。咱们在sso零碎登录了,这时再拜访app1,Cookie也带到了app1的服务端(Server),app1的服务端怎么找到这个Cookie对应的Session呢?这里就要把3个零碎的Session共享,如图所示。共享Session的解决方案有很多,例如:Spring-Session。这样第2个问题也解决了。 同域下的单点登录就实现了,但这还不是真正的单点登录。 不同域下的单点登录同域下的单点登录是巧用了Cookie顶域的个性。如果是不同域呢?不同域之间Cookie是不共享的,怎么办? 这里咱们就要说一说CAS流程了,这个流程是单点登录的规范流程。 上图是CAS官网上的规范流程,具体流程如下: 用户拜访app零碎,app零碎是须要登录的,但用户当初没有登录。跳转到CAS server,即SSO登录零碎,当前图中的CAS Server咱们对立叫做SSO零碎。SSO零碎也没有登录,弹出用户登录页。用户填写用户名、明码,SSO零碎进行认证后,将登录状态写入SSO的session,浏览器(Browser)中写入SSO域下的Cookie。SSO零碎登录实现后会生成一个ST(Service Ticket),而后跳转到app零碎,同时将ST作为参数传递给app零碎。app零碎拿到ST后,从后盾向SSO发送申请,验证ST是否无效。验证通过后,app零碎将登录状态写入session并设置app域下的Cookie。至此,跨域单点登录就实现了。当前咱们再拜访app零碎时,app就是登录的。接下来,咱们再看看拜访app2零碎时的流程。 用户拜访app2零碎,app2零碎没有登录,跳转到SSO。因为SSO曾经登录了,不须要从新登录认证。SSO生成ST,浏览器跳转到app2零碎,并将ST作为参数传递给app2。app2拿到ST,后盾拜访SSO,验证ST是否无效。验证胜利后,app2将登录状态写入session,并在app2域下写入Cookie。这样,app2零碎不须要走登录流程,就曾经是登录了。SSO,app和app2在不同的域,它们之间的session不共享也是没问题的。 有的同学问我,SSO零碎登录后,跳回原业务零碎时,带了个参数ST,业务零碎还要拿ST再次拜访SSO进行验证,感觉这个步骤有点多余。他想SSO登录认证通过后,通过回调地址将用户信息返回给原业务零碎,原业务零碎间接设置登录状态,这样流程简略,也实现了登录,不是很好吗? 其实这样问题时很重大的,如果我在SSO没有登录,而是间接在浏览器中敲入回调的地址,并带上伪造的用户信息,是不是业务零碎也认为登录了呢?这是很可怕的。 总结单点登录(SSO)的所有流程都介绍完了,原理大家都分明了。总结一下单点登录要做的事件: 单点登录(SSO零碎)是保障各业务零碎的用户资源的平安 。各个业务零碎取得的信息是,这个用户能不能拜访我的资源。单点登录,资源都在各个业务零碎这边,不在SSO那一方。 用户在给SSO服务器提供了用户名明码后,作为业务零碎并不知道这件事。 SSO轻易给业务零碎一个ST,那么业务零碎是不能确定这个ST是用户伪造的,还是真的无效,所以要拿着这个ST去SSO服务器再问一下,这个用户给我的ST是否无效,是无效的我能力让这个用户拜访。

May 23, 2021 · 1 min · jiezi

关于sso:SSO的通用标准OpenID-Connect

简介OpenID Connect简称为OIDC,已成为Internet上单点登录和身份治理的通用规范。 它在OAuth2上构建了一个身份层,是一个基于OAuth2协定的身份认证标准协议。 OAuth2实际上只做了受权,而OpenID Connect在受权的根底上又加上了认证。 OIDC的长处是:简略的基于JSON的身份令牌(JWT),并且齐全兼容OAuth2协定。 明天咱们将会介绍一下OIDC的具体原理。 OpenID Connect是什么OpenID Connect公布于2014年,是建设在OAuth 2.0协定之上的简略身份层,它容许客户端基于受权服务器或身份提供商(IdP)进行的身份验证来验证最终用户的身份,并取得用户的相干信息。 OpenID Connect提供了RESTful HTTP API,并应用Json作为数据的传递格局。 之前咱们讲到了基于XML格局的SAML协定,而OpenID Connect因为其更加简洁的数据交换格局,被越来越多的利用应用,曾经成为事实上的规范。 咱们看一下OpenID connect的根本流程: RP(client)发送一个认证申请到 OpenID Provider(OP)。OP对End User进行认证并取得相应的受权。OP返回一个ID Token或者access Token给RP。RP应用access token向UserInfo Endpoint申请用户信息。UserInfo Endpoint返回相应的用户信息给RP。ID TokenID Token就像是一个用户的身份证,它是以JWT格局存在的,并且由OP进行签名,保障它的安全性。 获取ID Token的形式就是向OP发送认证申请。 因为ID Token是以JWT格局存在的,JWT能够分为三个局部,别离是Header,Payload和Signature。 这里咱们次要关注一下Payload的json内容: { "sub" : "alice", "iss" : "https://openid.flydean.com", "aud" : "client-12345", "nonce" : "n-0S6_WzA2Mj", "auth_time" : 1311280969, "acr" : "c2id.loa.hisec", "iat" : 1311280970, "exp" : 1311281970}sub = Subject Identifier:必须。iss提供的EU的惟一标识;最长为255个ASCII个字符;iss = Issuer Identifier:必须。提供认证信息者的惟一标识。个别是Url的host+path局部;aud = Audience(s):必须。标识ID-Token的受众。必须蕴含OAuth2的client_id;nonce:RP发送申请的时候提供的随机字符串,用来减缓重放攻打,也能够来关联ID-Token和RP自身的Session信息。auth_time = AuthenticationTime:EU实现认证的工夫。如果RP发送认证申请的时候携带max_age的参数,则此Claim是必须的。acr = Authentication Context Class Reference:可选。示意一个认证上下文援用值,能够用来标识认证上下文类。iat = Issued At Time:必须。JWT的构建的工夫。exp = Expiration time:必须。ID-Token的过期工夫;下面的是ID Token的规范Claims。 ...

December 15, 2020 · 2 min · jiezi

关于sso:单点登录认证系统-MaxKey-v230GA-发布

MaxKey(马克思的钥匙)单点登录认证零碎(Single Sign On System),寓意是最大钥匙,是业界当先的企业级IAM身份治理和身份认证产品,反对OAuth 2.0/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议,提供简略、规范、平安和凋谢的用户身份治理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限治理和资源管理等。 官方网站 官方网站 | 官方网站二线 邮箱EMAIL: maxkeysupport@163.com 代码托管 GitHub | 码云(Gitee) 什么是单点登录(Single Sign On),简称为SSO? 用户只须要登录认证核心一次就能够拜访所有相互信任的利用零碎,无需再次登录。 次要性能: 1.所有利用零碎共享一个身份认证零碎 2.所有利用零碎可能辨认和提取ticket信息 产品个性规范认证协定:序号协定反对1.1OAuth 2.0/OpenID Connect高1.2SAML 2.0高1.3JWT高1.4CAS高1.5FormBased中1.6TokenBased(Post/Cookie)中1.7ExtendApi低1.8EXT低登录反对序号登录形式2.1动静验证码 字母/数字/算术2.2双因素认证2.3短信认证 腾讯云短信/阿里云短信/网易云信2.4Google/Microsoft Authenticator/FreeOTP/反对TOTP或者HOTP2.5Kerberos/SPNEGO/AD域2.6社交账号 微信/QQ/微博/钉钉/Google/Facebook/其余提供规范的认证接口以便于其余利用集成SSO,平安的挪动接入,平安的API、第三方认证和互联网认证的整合。提供用户生命周期治理,反对SCIM 2协定,基于Apache Kafka代理,通过连接器(Connector)实现身份供应同步。认证核心具备平台无关性、环境多样性,反对Web、手机、挪动设施等, 如Apple iOS,Andriod等,将认证能力从B/S到挪动利用全面笼罩。多种认证机制并存,各利用零碎可保留原有认证机制,同时集成认证核心的认证;利用具备高度独立性,不依赖认证核心,又可用应用认证核心的认证,实现单点登录。基于Java平台开发,采纳Spring、MySQL、Tomcat、Apache Kafka、Redis等开源技术,反对微服务,扩展性强。许可证 Apache License, Version 2.0,开源、平安、自主可控。界面MaxKey认证 登录界面   主界面   MaxKey治理 拜访报表   用户治理   利用治理   下载以后版本百度网盘下载, 历史版本 版本日期下载地址提取码v 2.3.0 GA2020/11/11链接下载h3zwRoadmap1.动静用户组实现(基于用户属性或机构) 2.主任职机构和兼职机构 3.MaxKey Cloud(微服务版)-2021年 4.零信赖场景整合 版本阐明MaxKey v 2.3.0 GA 2020/11/11 (MAXKEY-200901) 基于spring session的集群会话共享性能 (MAXKEY-200902) 单点登记性能,利用能够配置为NONE/BACK_CHANNEL/FRONT_CHANNEL三种形式,反对CAS/SAML/Default(MAXKEY-200903) 用户在线实时更新性能(MAXKEY-200904) 定制用户模板,实现批量Excel用户导入性能(MAXKEY-200905) 定制机构模板,实现批量Excel机构导入性能(MAXKEY-200906) 用户注册性能(MAXKEY-200907) 用户状态批改(MAXKEY-200908) 用户详情显示问题(MAXKEY-200909) 利用批改时数字大于4为长度格式化问题(MAXKEY-200910) 登记后,点击从新登陆跳转问题(MAXKEY-200911) 减少SP登录跳转性能,反对knox的认证(MAXKEY-200912) 构建脚本的优化和更新(MAXKEY-200913) 管理员权限管制 RoleAdministrators (MAXKEY-200914) 社交账号登录优化(MAXKEY-200915) 列表界面中未”抉择“状况下,弹出界面谬误(MAXKEY-200916) jib(docker) 反对 ,感激https://github.com/alanland(MAXKEY-200917) 登录过程的优化(MAXKEY-200918) 认证的优化,反对@Principal的注入(MAXKEY-200919) 利用单点登录时,用户拜访权限管制(MAXKEY-200920) maxkey-mgt 我的项目配置文件的验证码启用不启用配置未失效(MAXKEY-200921) 登录图标改良(MAXKEY-200922) 官方网站的优化(MAXKEY-200923) 依赖jar援用、更新和降级 druid 1.2.1 JustAuth 1.15.8 simple-http 1.0.3 spring-session 2.3.1.RELEASE druid-spring-boot-starter 1.2.1 xmlbeans 3.0.1 commons-compress 1.20 poi 4.1.2 commons-collections4 4.4

November 12, 2020 · 1 min · jiezi

关于sso:第三阶段-Day16-用户模块跳转-SSO单点登录-JSONPcors跨域方式-用户登录校检

1.实现用户模块跳转1.1 需要阐明阐明:当用户点击登录/注册按钮时 须要跳转到指定的页面中.url地址1.:http://www.jt.com/user/regist...url地址2: http://www.jt.com/user/login.... 1.2 编辑UserController`package com.jt.controller;import org.springframework.stereotype.Controller;import org.springframework.web.bind.annotation.PathVariable;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RestController;@Controller //须要进行页面跳转@RequestMapping("/user")public class UserController { /** * 实现用户模块页面跳转 * url1: http://www.jt.com/user/login.html 页面:login.jsp * url2: http://www.jt.com/user/register.html 页面:register.jsp * 要求:实现通用页面跳转 * restFul形式: 1.动静获取url中的参数,之后实现通用的跳转. */ @RequestMapping("/{moduleName}") public String module(@PathVariable String moduleName){ return moduleName; }}` 1.3 页面成果展示 2 JT-SSO我的项目创立2.1 创立我的项目 2.2 增加继承/依赖/插件`<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <artifactId>jt-sso</artifactId> <!--默认的打包形式就是jar 不写也没有关系--> <packaging>jar</packaging> <parent> <artifactId>jt</artifactId> <groupId>com.jt</groupId> <version>1.0-SNAPSHOT</version> </parent> <!--2.增加依赖信息--> <dependencies> <!--依赖本质依赖的是jar包文件--> <dependency> <groupId>com.jt</groupId> <artifactId>jt-common</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <!--3.增加插件--> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build></project>` 2.3 编辑User的POJO对象`@TableName("tb_user")@Data@Accessors(chain = true)public class User extends BasePojo{ @TableId(type = IdType.AUTO)//设定主键自增 private Long id; //用户ID号 private String username; //用户名 private String password; //明码 须要md5加密 private String phone; //电话号码 private String email; //临时应用电话代替邮箱}` 2.4 测试JT-SSO我的项目用户通过sso.jt.com/findUserAll 获取user表中的信息 json返回代码构造如下: ...

November 9, 2020 · 3 min · jiezi

关于sso:SSO-实现单点登录-回显退出

实现单点登录Controller 将用户登录信息保留在cookie中 /** * 实现用户登录操作 */@RequestMapping("doLogin")@ResponseBodypublic SysResult doLogin(User user, HttpServletResponse response){ String ticket=dubboUserService.doLogin(user);//用户秘钥 if(StringUtils.isEmpty(ticket)){ return SysResult.fail(); } else { /* Cookie cookie=new Cookie("JT_TICKET",ticket); cookie.setMaxAge(7*24*60*60);//设定cookie有效期 cookie.setPath("/");//设定cookie的范畴 cookie.setDomain("jt.com");//设定cookie共享的域名,是实现单点登录的必备因素 response.addCookie(cookie);*/ CookieUtil.addCookie("JT_TICKET",ticket,7*24*60*60,"jt.com",response); return SysResult.success(); }}实现层 用户登录后会生成ticket, 将用户信息保留在redis中 @Overridepublic String doLogin(User user) { //1.将明文加密 String md5Pass= DigestUtils.md5DigestAsHex(user.getPassword().getBytes()); user.setPassword(md5Pass);//把用户明码进行加密 QueryWrapper<User>queryWrapper=new QueryWrapper<>(user); //依据对象中不为null的属性当做where条件 User userDB=userMapper.selectOne(queryWrapper); if (userDB==null){ //用户名或明码谬误 return null; }else {//用户名和明码正确,实现单点登录操作 String ticket= UUID.randomUUID().toString();//生成随机ticket //如果将数据保留到第三方 个别须要脱敏解决 userDB.setPassword("123456");//查问到的用户 设置明码 String userJSON= ObjectMapperUtil.toJson(userDB); jedisCluster.setex(ticket,7*24*60*60,userJSON);//将用户信息保留在redis中 return ticket; }}CookieUtil工具类public class CookieUtil { //新增cookie public static void addCookie(String cookieName, String cookieValue, Integer seconds, String domain, HttpServletResponse response){ Cookie cookie=new Cookie(cookieName,cookieValue); cookie.setMaxAge(seconds); cookie.setDomain(domain); cookie.setPath("/"); response.addCookie(cookie); } //依据name查value值 public static String getCookieValue(HttpServletRequest request, String cookieName ) { Cookie[] cookies = request.getCookies(); if (cookies.length > 0 && cookies != null) { for (Cookie cookie : cookies ) { if (cookieName.equals(cookie.getName())) { return cookie.getValue(); } } } return null; } //删除cookie public static void deleteCookie(HttpServletResponse response, String cookieName, String domain){ addCookie(cookieName,"",0,domain,response); }}将用户信息回显/** * 1.用户通过cookie信息查问用户数据 */@RequestMapping("/user/query/{ticket}")public JSONPObject findUserByTicket(@PathVariable String ticket, HttpServletResponse response,String callback){ String userJson = jedisCluster.get(ticket); //LRU算法清空了数据、他人随便篡改cookie信息 if(StringUtils.isEmpty(userJson)){ //有误 应该删除cookie信息 /*Cookie cookie=new Cookie("JT_TICKET","") ; cookie.setMaxAge(0); cookie.setDomain("jt.com"); cookie.setPath("/"); response.addCookie(cookie);*/ CookieUtil.deleteCookie(response,"JT_TICKET","jt.com"); return new JSONPObject(callback,SysResult.fail()); }return new JSONPObject(callback,SysResult.success(userJson));}用户退出操作如果用户点击退出操作, 首先应该删除Redis中的数据 其次删除Cookie中的数据 之后重定向到零碎首页.Controller ...

October 23, 2020 · 2 min · jiezi

单点登录认证系统-MaxKey-v-200GA

MaxKey(马克思的钥匙)用户单点登录认证零碎(Sigle Sign On System),寓意是最大钥匙,是业界当先的企业级IAM身份治理和身份认证产品,反对OAuth 2.0/OpenID Connect、SAML 2.0、JWT、CAS等标准化的凋谢协定,提供简略、规范、平安和凋谢的用户身份治理(IDM)、身份认证(AM)、单点登录(SSO)、RBAC权限治理和资源管理等。 MaxKey 官网文档 | GitHub | 码云(Gitee) QQ交换群:434469201 | 邮箱EMAIL: shimingxy@163.com 什么是单点登录(Single Sign On),简称为SSO? 用户只须要登录认证核心一次就能够拜访所有相互信任的利用零碎,无需再次登录。 次要性能: 1.所有利用零碎共享一个身份认证零碎 2.所有利用零碎可能辨认和提取ticket信息 规范认证协定: 序号协定反对1OAuth 2.0/OpenID Connect高2SAML 2.0高3JWT高4CAS高5FormBased中6TokenBased(Post/Cookie)中7ExtendApi低8EXT低登录反对 序号登录形式1动静验证码 字母/数字/算术2双因素认证3短信认证 腾讯云短信/阿里云短信/网易云信4Google/Microsoft Authenticator/FreeOTP/反对TOTP或者HOTP5Kerberos/SPNEGO/AD域6社交账号 微信/QQ/微博/钉钉/Google/Facebook/其余提供规范的认证接口以便于其余利用集成SSO,平安的挪动接入,平安的API、第三方认证和互联网认证的整合。 提供用户生命周期治理,反对SCIM 2协定,基于Apache Kafka代理,通过连接器(Connector)实现身份供应同步。 认证核心具备平台无关性、环境多样性,反对Web、手机、挪动设施等, 如Apple iOS,Andriod等,将认证能力从B/S到挪动利用全面笼罩。 多种认证机制并存,各利用零碎可保留原有认证机制,同时集成认证核心的认证;利用具备高度独立性,不依赖认证核心,又可用应用认证核心的认证,实现单点登录。 基于Java平台开发,采纳Spring、MySQL、Tomcat、Apache Kafka、Redis等开源技术,反对微服务,扩展性强。 许可证 Apache License, Version 2.0,开源收费。 界面MaxKey认证 登录界面  主界面   MaxKey治理 拜访报表  用户治理   利用治理 下载百度网盘下载 版本日期下载地址提取码v 2.0.0 GA2020/07/13链接下载xfrrv 1.4.0 GA2020/05/01链接下载f3fsv 1.3.0 GA2020/04/04链接下载20bjv 1.2.1 GA2020/02/29链接下载yutqv 1.2.0 GA2020/01/18链接下载6bdav 1.0.0 GA2019/12/06链接下载g17zRoadmapSCIM 2 Support-System for Cross-domain Identity Management ...

July 13, 2020 · 1 min · jiezi

系统的讲解-SSO单点登录

概念SSO 英文全称 Single Sign On,单点登录。 在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。 比如:淘宝网(www.taobao.com),天猫网(www.tmall.com),聚划算(ju.taobao.com),飞猪网(www.fliggy.com)等,这些都是阿里巴巴集团的网站。在这些网站中,我们在其中一个网站登录了,再访问其他的网站时,就无需再进行登录,这就是 SSO 的主要用途。 好处用户角度用户能够做到一次登录多次使用,无需记录多套用户名和密码,省心。 系统管理员角度管理员只需维护好一个统一的账号中心就可以了,方便。 新系统开发角度新系统开发时只需直接对接统一的账号中心即可,简化开发流程,省时。 技术实现流程图 流程介绍如果没这个介绍,看上图肯定是懵懵的。 系统A和系统B都是前后端分离的,比如前端框架用的 React / Vue / Angular,都是通过 NPM 编译后独立部署的,前后端完全通过HTTP接口的方式进行交互,也有可能前后端项目的域名都不一样。 SSO认证中心不是前后端分离的,就是前端代码和后端代码部署在一个项目中。 为什么用这两种情况呢? 其实就是为了,在流程图上出现这两种情况,这样的清楚了,后期改成任何一种就都清楚了。 试想一下: 三个系统都是前后端分离的情况,流程图应该怎么调整? 三个系统都不是前后端分离的情况,流程图应该怎么调整? 对外接口系统A和系统B:用户退出接口。 SSO 认证中心:用户退出接口和token验证接口。 登录如上述流程图一致。 系统A和系统B:使用token认证登录。 SSO 认证中心:使用会话认证登录。 前后端分离项目,登录使用token进行解决,前端每次请求接口时都必须传递token参数。 退出 上图,表示的是从某一个系统退出的流程图。 退出,还可以从SSO认证中心退出,然后调取各个系统的用户退出接口。 当用户再进行操作的时候,就会跳转到SSO的登录界面。 Token 生成方式创建全局会话可以使用session,将session存储到redis中。 令牌的生成可以使用JWT。 PHP JWT参考地址:https://github.com/lcobucci/jwt 当然还可以自定义token的生成方式。 小结讲解了什么是SSO,以及SSO的用途与好处,同时根据流程图一步步进行梳理,基本上就可以实现了。 期间遇到任何问题,都可以关注公众号和我进行交流。 扩展SSO与OAuth的区别谈到SSO很多人就想到OAuth,也有谈到OAuth想到SSO的,在这里我简单的说一下区别。 通俗的解释,SSO是处理一个公司内的不同应用系统之间的登录问题,比如阿里巴巴旗下有很多应用系统,我们只需要登录一个系统就可以实现不同系统之间的跳转。 OAuth是不同公司遵循的一种授权方案,也是一种授权协议,通常都是由大公司提供,比如腾讯,微博。我们常用的QQ登录,微博登录等,使用OAuth的好处是可以使用其他第三方账号进行登录系统,减少了因用户懒,不愿注册而导致用户流失的风险。 现在一些支付业务也用OAuth,比如微信支付,支付宝支付。 还有一些开放平台也用OAuth,比如百度开放平台,腾讯开放平台。 SSO与RBAC的关系如果企业有多个管理系统,现由原来的每个系统都有一个登录,调整为统一登录认证。 那么每个管理系统都有权限控制,吸取统一登录认证的经验,我们也可以做一套统一的RBAC权限认证。 本文欢迎转发,转发请注明作者和出处,谢谢!

May 10, 2019 · 1 min · jiezi

基于Spring-Security-Oauth2的SSO单点登录JWT权限控制实践

概 述在前文《基于Spring Security和 JWT的权限系统设计》之中已经讨论过基于 Spring Security和 JWT的权限系统用法和实践,本文则进一步实践一下基于 Spring Security Oauth2实现的多系统单点登录(SSO)和 JWT权限控制功能,毕竟这个需求也还是蛮普遍的。 代码已开源,放在文尾,需要自取理论知识在此之前需要学习和了解一些前置知识包括: Spring Security:基于 Spring实现的 Web系统的认证和权限模块OAuth2:一个关于授权(authorization)的开放网络标准单点登录 (SSO):在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统JWT:在网络应用间传递信息的一种基于 JSON的开放标准((RFC 7519),用于作为JSON对象在不同系统之间进行安全地信息传输。主要使用场景一般是用来在 身份提供者和服务提供者间传递被认证的用户身份信息要完成的目标目标1:设计并实现一个第三方授权中心服务(Server),用于完成用户登录,认证和权限处理目标2:可以在授权中心下挂载任意多个客户端应用(Client)目标3:当用户访问客户端应用的安全页面时,会重定向到授权中心进行身份验证,认证完成后方可访问客户端应用的服务,且多个客户端应用只需要登录一次即可(谓之 “单点登录 SSO”)基于此目标驱动,本文设计三个独立服务,分别是: 一个授权服务中心(codesheep-server)客户端应用1(codesheep-client1)客户端应用2(codesheep-client2)多模块(Multi-Module)项目搭建三个应用通过一个多模块的 Maven项目进行组织,其中项目父 pom中需要加入相关依赖如下: <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.0.8.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>io.spring.platform</groupId> <artifactId>platform-bom</artifactId> <version>Cairo-RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Finchley.SR2</version> <type>pom</type> <scope>import</scope> </dependency></dependencies>项目结构如下: 授权认证中心搭建授权认证中心本质就是一个 Spring Boot应用,因此需要完成几个大步骤: pom中添加依赖<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-oauth2</artifactId> </dependency></dependencies>项目 yml配置文件:server: port: 8085 servlet: context-path: /uac即让授权中心服务启动在本地的 8085端口之上 创建一个带指定权限的模拟用户@Componentpublic class SheepUserDetailsService implements UserDetailsService { @Autowired private PasswordEncoder passwordEncoder; @Override public UserDetails loadUserByUsername(String s) throws UsernameNotFoundException { if( !"codesheep".equals(s) ) throw new UsernameNotFoundException("用户" + s + "不存在" ); return new User( s, passwordEncoder.encode("123456"), AuthorityUtils.commaSeparatedStringToAuthorityList("ROLE_NORMAL,ROLE_MEDIUM")); }}这里创建了一个用户名为codesheep,密码 123456的模拟用户,并且赋予了 普通权限(ROLE_NORMAL)和 中等权限(ROLE_MEDIUM) ...

May 7, 2019 · 2 min · jiezi

C++ string的SSO

C++的string相对于C语言的string完善了很多,通过运算符重载可以很直观的进行字符串的拼接等操作。GCC 5.0以后的版本采用了__SSO__(短字符串优化)的策略替换了原本的__COW__优化,我写了几段代码来验证了一下新的实现的一些细节。PS:这里的所有的内容只是特定平台特定编译器的特定行为。平台: Windows 64位 MinGW 7.3.0#include <iostream>using namespace std;int main(int argc, char* argv[]){ string a = “123456789abcde”; //15个char string s(“this is the edge”); //16个char string longstr(“Scaramouche, scaramouche will you do the Fandango”); //长串 在heap分配 cout << &a << " " << (void*)a.c_str() << endl; cout << &s << " " << (void*)s.c_str() << endl; cout << &longstr << " " << (void*)longstr.c_str() << endl; cout << sizeof(char*) << endl; cout << sizeof(s) << endl; return 0;}0x62fde0 0x62fdf00x62fdc0 0x7d17d00x62fda0 0x7d1b40832在这里我通过c_str打印串开始的地址。从输出我们可以看出来string占32个字节,其中16个字节实际上用于存储字符。我们创建出来的三个对象地址相差0x20(32)个字节,后两个的指针地址于对象的地址相差很远,应该是在堆上动态分配的内存,而第一个字符串的存储地址(0x62fdf0)于对象的起始地址(0x62fde0)只差__0x10__,而对象大小__0x20__,所有这个串实际上就是存储在这个程序栈中.上文的 SSO 实际上值得就是短的字符串(strlen(s)<15,即最多包含15个char和'0’)直接存储在对象里,更长的串再存储在堆上开辟的空间里。C++的string与xstring和sds在很多情况下很相像。 ...

March 8, 2019 · 1 min · jiezi

统一认证 - Apereo CAS 客户端的集成以及小结

前两篇介绍了Apereo CAS以及服务器端的安装,但还不够完整,服务端还没有Application真正用起来呢!这篇文章将介绍怎么用起来集成的目的客户端我们想要与Apereo CAS做什么集成呢?回顾一下Apereo CAS是做什么的?Apereo CAS的一个功能就是单点登录,统一的登录登出接口与页面,让系统中的模块只需要关注在业务点,而把安全认证的功能交给统一认证来做。所以客户端的集成主要是单点登录的集成,客户端指定需要做安全认证的页面,然后Apereo CAS的安全包检测校验用户登录情况,并自动与CAS登录页面进行跳转交互。客户端的配置Apereo CAS提供了Springboot的包,可以让我们的集成些微方便了那么一丢丢!首先我们创建一个Springboot的application,里面带了Apereo CAS start的依赖<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-cas</artifactId></dependency>同时在application.properties文件里面指定启动的端口 server.port = 9000有了Apereo CAS的包之后,我们就可以进行代码的配置。客户端的配置按照SpringSecurity的安全检验流程进行的:用户尝试打开一个受保护的url,比如/admin/userAuthenticationEntryPoint被触发了,把用户重定向到配置好的CAS登录页面https://localhost:6443/cas用户输入用户名密码,登录成功后, CAS会跳转回application指定的回调url http://localhost:9000/login/cas, 并带上ticket作为查询参数CasAuthenticationFilter一直在监听/login/cas这个路径,当发现有请求后,它会触发CasTicketValidator,由CasTickerValidator检验ticket的有效性当ticket也验证成功后,用户将会被跳转回原来请求的受保护url下面代码大致描述了这个过程:@Beanpublic ServiceProperties serviceProperties() { ServiceProperties serviceProperties = new ServiceProperties(); serviceProperties.setService(“http://localhost:9000/login/cas”); serviceProperties.setSendRenew(false); return serviceProperties;} @Bean@Primarypublic AuthenticationEntryPoint authenticationEntryPoint( ServiceProperties sP) { CasAuthenticationEntryPoint entryPoint = new CasAuthenticationEntryPoint(); entryPoint.setLoginUrl(“https://localhost:6443/cas/login”); entryPoint.setServiceProperties(sP); return entryPoint;} @Beanpublic TicketValidator ticketValidator() { return new Cas30ServiceTicketValidator( “https://localhost:6443/cas”);} @Beanpublic CasAuthenticationProvider casAuthenticationProvider() { CasAuthenticationProvider provider = new CasAuthenticationProvider(); provider.setServiceProperties(serviceProperties()); provider.setTicketValidator(ticketValidator()); provider.setUserDetailsService( s -> new User(“casuser”, “Mellon”, true, true, true, true, AuthorityUtils.createAuthorityList(“ROLE_ADMIN”))); provider.setKey(“CAS_PROVIDER_LOCALHOST_9000”); return provider;}@EnableWebSecurity@Configurationpublic class SecurityConfig extends WebSecurityConfigurerAdapter { private AuthenticationProvider authenticationProvider; private AuthenticationEntryPoint authenticationEntryPoint; private SingleSignOutFilter singleSignOutFilter; private LogoutFilter logoutFilter; @Autowired public SecurityConfig(CasAuthenticationProvider casAuthenticationProvider, AuthenticationEntryPoint eP, LogoutFilter lF , SingleSignOutFilter ssF ) { this.authenticationProvider = casAuthenticationProvider; this.authenticationEntryPoint = eP; this.logoutFilter = lF; this.singleSignOutFilter = ssF; } // … @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.authenticationProvider(authenticationProvider); } @Override protected AuthenticationManager authenticationManager() throws Exception { return new ProviderManager(Arrays.asList(authenticationProvider)); } @Bean public CasAuthenticationFilter casAuthenticationFilter(ServiceProperties sP) throws Exception { CasAuthenticationFilter filter = new CasAuthenticationFilter(); filter.setServiceProperties(sP); filter.setAuthenticationManager(authenticationManager()); return filter; }}下面这个文件配置了application中所有/secured/,login的URL都是受保护资源,都要经过CAS认证过才可以访问:@EnableWebSecurity@Configurationpublic class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .regexMatchers("/secured.", “/login”) .authenticated() .and() .authorizeRequests() .regexMatchers("/") .permitAll() .and() .httpBasic() .authenticationEntryPoint(authenticationEntryPoint); } // …}服务端Apereo CAS的配置跟所有统一认证平台一样,所有application想要跟CAS做集成的,都需要在CAS配置相应的参数才可以使用。Apereo CAS提供了很多配置的方式,有YML,JSON, MongoDB以及其他(可查官网)。但高度自由的CAS一如既往的,没有提供可视化操作的界面。比如我们采用JSON的方式。首先我们需要通知Apereo CAS我们采用的是JSON的方式,并通知JSON文件的路径在哪里cas.serviceRegistry.initFromJson=truecas.serviceRegistry.config.location=classpath:/services然后我们在这个目录里面,创建一个对应的JSON文件,保存我们的客户端信息,为了方面管理,建议文件名为 application_id.json, 比如"secureApp_9991.json", 内容如下:{ “@class” : “org.apereo.cas.services.RegexRegisteredService”, “serviceId” : “^http://localhost:9000/login/cas”, “name” : “CAS Spring Secured App”, “description”: “This is a Spring App that usses the CAS Server for it’s authentication”, “id” : 19991, “evaluationOrder” : 1}第一次配置从JSON加载客户端配置的话,需要重启Apereo CAS。之后再加新的客户端的话就不用再重启,Apereo CAS会自动监测这个文件夹的变动小结至此我们对于Apereo CAS就有了一个稍微完整一点点的了解,从服务端安装部署,到配置,以及客户端如何集成等。但从这个短时间的学习来看,如果企业已经重度使用了Apereo CAS,那相信它可以很好地服务支撑企业的应用。但如果是新的项目,特别是项目周期比较紧张的项目,并且团队之前没有对统一认证有技术积累的话,不是很建议采用Apereo CAS,这些细微的配置以及无所不在的隐藏功能,会让你给项目经理催死的! 后面我会介绍另外一个统一认证的框架,个人感觉能弥补Apereo CAS的短板的 ...

February 23, 2019 · 2 min · jiezi