下载应用:https://github.com/Azure-Samples/active-directory-java-webapp-openidconnect(普通项目,集成了特殊配置接入微软的注册中心) 1.注册登录:https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview 2.如图添加想要添加的应用 其中找到tenant 点击:Required permissions—>Requi

<Windows Azure Platform 系列文章目录> 本文介绍的是,在单一目录下,使用Azure AD Connect,打通本地Domain Controller 我们需要准备的环境有: 1.Azure China订阅 2.在本地或者在微软云端,创建1台Windows VM,安装Domain Controller域控制器服务. 这里我们的测试环境为在云端创建1台Domain Controller机器,命名为CorpDC,安装的Domain Name为:leicorp.biz 3.注册

基于Claim的身份标识是处理网站与 Web 服务的身份认证和访问一种简单而强大的方式,无论您是在本地工作还是面向云工作.您可以通过减少自定义实施和使用基于Claim的单一简化标识模型,创建更安全的应用程序.   Windows Identity Foundation (WIF)是一组 .NET Framework 类.它是用于在您的应用程序中实施基于Claim的标识的框架. 从架构上说,使用基于Claim的标识可以将应用程序从身份验证业务中脱离出来.单点登录变得更容易实现,您的应用程序不再负责

Hello 小伙伴们,我回来了~ 2017年底中招了流感,还得了结膜炎,我也是无奈的···但使命感驱使我还是要把文章更完(这么敬业还不点赞关注(*^__^*) ) 我们接着上一篇文章继续说,上一篇已经和大家介绍了安装Azure AD Connect的方法,现在我们可以开始同步Active Directory到Azure AD. 打开Azure AD Connect,选择“Customize synchronization Options”来自定义同步的选项. 输入 Office 365 管理员的

前言 第一篇文章我已经为大家分享了在在Azure上搭建域控服务器的方法,如果大家本地已经有了域环境,可以直接从这一篇文章开始阅读.Azure AD Connect的前身是DirSync,是专门用于目录同步和密码同步的工具,将用户位于本地Active Directory的用户名和密码同步到Azure AD中,使用与本地AD相同的密码登录Office 365服务.如果我们还额外配置了单点登录,就可以选择性的进行密码同步,并且用户使用本地AD的信息登录云服务,身份验证发生在本地域控服务器上,详细信息大

InvalidOperationException: ID1073: 尝试使用 ProtectedData API 解密 Cookie 时出现 CryptographicException (有关详细信息,请参见内部异常).如果使用的是 IIS 7.5,则这可能是由于应用程序池的 loadUserProfile 设置设成了 false.] 1.先说下这个问题 由于每个实例都有一个不同的密钥,因此默认的 cookie 加密机制(使用数据保护应用程序编程接口 (DPAPI))并不合适.这意味着由一个

Hello 小伙伴们, 2018新年快乐,作为2018年首篇文章,怎么能不给大家带来点干货呢?这篇文章其实我9月底的时候已经在MSDN上发布过了,为表诚意,我更新了这篇文章,并把它组成了一个系列,2.0版本的相信会对大家更有帮助. 在正式开始之前,我们有必要聊聊为什么要实现单点登录.单点登录简而言之,就是让用户使用一套ID和密码,就可以登录一个或多个系统的授权机制.用户只需要通过其中一个应用的安全认证之后,再访问同一服务器其他应用的资源时不需要再次输入账户和密码.那聊到Office 365实现单

目录 目录 1.介绍 1.1.什么是Crowd? 2.Crowd 的官网在哪里? 3.如何下载安装? 4.对 Crowd 进行配置 4.1.破解 Crowd 第一步 4.2.破解 Crowd 第二步,获取授权许可 4.2.Crowd 的安装 Crowd installation 4.3.数据库配置 Database configuration 4.4.Crowd 选项 Options 4.5.内部目录设置 Internal directory 4.6.设置默认管理员帐号 Default admi

安全申明标记语言(Security Assertion Markup Language (SAML))是一个基于 XML 的数据格式,允许各个软件平台通过identity provider (IdP)交换授权信息.最常用的情况是允许用户使用相同的的用户登录信息在不同的软件平台之间进行登录.这个就是我们常说的单点登录(SSO). 我们为 Confluence 数据中心连接到你的 IdP 提供了这个功能,这样你可以能够为你的用户提供 SSO 功能.这个仅仅能够处理授权.应用的访问和任何其他需要授权的

在同一个域名下有很多子系统 如:a.giant.com  b.giant.com   c.giant.com等 但是这些系统都是giant.com这个子域. 这样的情况就可以在不引用其它框架的情况下,直接基于Cookie实现同域单点登录SSO 注:用ID4,OAuth,其它SSO框架也同样可以实现.本文不讨论. 为了简单表示.在这里登录页只输入一个用户名,然后登录后台接收到登录名后,构建登录信息.然后登录代码如下: <form enctype="application/x-www-form

这是单点登录系列的最后一篇文章,前面4篇文章其实都是在为这篇文章的内容做准备,我把这四篇文章的链接放在下面,如果大家有需要,可以参考我以下的链接: Office 365实现单点登录系列(1)—域环境搭建 Office 365实现单点登录系列(2)—Azure AD Connect安装与配置 Office 365实现单点登录系列(3)—使用Azure AD Connect 进行目录同步 Office 365实现单点登录系列(4)—安装AD FS 话不多说,直接为大家演示实现单点登录的步骤~ 1.安

单一登录 (Single Sign-On)简而言之,就是让用户使用一套ID和密码,就可以登录一个或多个系统的授权机制.用户只需要通过其中一个应用的安全认证之后,再访问同一服务器其他应用的资源时不需要再次输入账户和密码. 我们已经使用Azure AD Connect进行了目录同步,为了实现单点登录,我们需要安装AD FS联合认证服务器.安全起见,一般情况下我们不会直接把AD FS暴露在公网,而会额外安装 AD FS代理服务器,同时考虑高可用性(至少两台以上的AD FS和AD FS代理服务器),由于

Hello 小伙伴们, 2018新年快乐,作为2018年首篇文章,怎么能不给大家带来点干货呢?这篇文章其实我9月底的时候已经在MSDN上发布过了,为表诚意,我更新了这篇文章,并把它组成了一个系列,2.0版本的相信会对大家更有帮助. 在正式开始之前,我们有必要聊聊为什么要实现单点登录.单点登录简而言之,就是让用户使用一套ID和密码,就可以登录一个或多个系统的授权机制.用户只需要通过其中一个应用的安全认证之后,再访问同一服务器其他应用的资源时不需要再次输入账户和密码.那聊到Office 365实现单

前言 本系列前三篇文章分别从ASP.NET Core认证的三个重要概念,到如何实现最简单的登录.注销和认证,再到如何配置Cookie 选项,来介绍如何使用ASP.NET Core认证.感兴趣的可以了解一下. ASP.NET Core Authentication系列(一)理解Claim, ClaimsIdentity, ClaimsPrincipal ASP.NET Core Authentication系列(二)实现认证.登录和注销 ASP.NET Core Authentication系列(

      SSO英文全称Single Sign On,单点登录.SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统.它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制.认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证:认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户.它是比较流行的企业业务整合的解决方案之一.       企业应用集成(EAI, Enterprise Application Integr

单点登录是我比较喜欢的一个技术解决方案,一方面他能够提高产品使用的便利性,另一方面他分离了各个应用都需要的登录服务,对性能以及工作量都有好处.自从上次研究过JWT如何应用于会话管理,加之以前的项目中也一直在使用CAS这个比较流行的单点登录框架,所以就一直在琢磨如何能够把JWT跟单点登录结合起来一起使用,尽量能把两种技术的优势都集成到项目中来.本文介绍我从CAS思考得出的SSO的实现方案. 前言 其实CAS这个方案很好,非常强大,它最新的版本已经集成JWT了,所以要是不想自己开发单点登录的服务的话

什么是SSO? 如果你已知道,请略过本节! SSO核心意义就一句话:一处登录,处处登录:一处注销,处处注销.即:在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统. 很多人容易把SSO与OAuth搞混.这里简单说明一下: OAuth也可简单总结为一句:基于各种懒和YY的原因,拿别人的登录系统来用. 至于官方说的,是一种授权协议,为网站用户授权第三方应用访问自己在网站…(此处省略N多字)可自行百度. SSO实现 SSO的实现方式虽然有很多种,但大的框架不会脱离下图结构的: 即所有

前言 由于公司内部的系统越来越多,为了方便用户使用,通过django进行了单点登录和统一认证的尝试,目前实现了django项目的单点登录和非django项目的统一认证,中间波折挺多,涉及的技术包括django\memcache\ldap等,如果有时间的话,后边会逐步更新博客分开介绍实现过程. sso的实现相对复杂,期间也调研了如cas+ldap,最后采取了一种学习成本较低的方式,即通过mc共享session方式实现单点登录.有兴趣并且懂java的同学可以自行了解cas.应该是一种更成熟的sso解

前言 参考本系列之前的文章,我们已经搭建了ldap并且可以通过django来操作ldap了,剩下的就是下游系统的接入了,现在的应用场景,我是分了2个层次,第一层次是统一认证,保证各个系统通过ldap来维护统一的用户名和密码,第二层次就是sso单点登录,即一个系统登录,其他系统即是登录状态,一个系统登出,其他系统也自动登出,也就是我们登录公司内部的N个系统,其实总共只需要登录一次即可. 目前,django的下游系统可以接入单点,理论上,只要语言支持memcache客户端,通过session维持登录

一.CAS是什么? CAS(Central Authentication Service)是 Yale 大学发起的一个企业级的.开源的项目,旨在为 Web 应用系统提供一种可靠的单点登录解决方法(支持WEB及客户端). CAS 开始于 2001 年, 并在 2004 年 12 月正式成为 JA-SIG 的一个项目. 二.主要特性  1.开源的.多协议的 SSO 解决方案: Protocols : Custom Protocol . CAS . OAuth . OpenID . RESTful A

前言 继上一篇博文:可跨域的单点登录(SSO)实现方案[附.net代码]虽然实现了单点登录,也存在很多不合理的地方.很多热心的朋友也给出了很多指导性的意见,特别是 LoveCoder提出的意见. 在很多亲自操刀过单点登录的朋友看来,单点登录很简单啊,不过如此.但是还有很多如我一样刚刚接触过或者没有接触过单点登录的朋友却不清楚单点登录具体该怎么做.虽然网上单点登录的教程很多很多,大都是实现思路.实现原理,真正涉及到代码级别的实现细节却很少. 单点登录产生的原因是为了解决多个子系统共享登录状态的问题