单点登录SSO详解.docx
- 文档编号:8473469
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:27
- 大小:324.63KB
单点登录SSO详解.docx
《单点登录SSO详解.docx》由会员分享,可在线阅读,更多相关《单点登录SSO详解.docx(27页珍藏版)》请在冰豆网上搜索。
单点登录SSO详解
单点登录SSO详解
2013-03-22和鸣605楼整理,大四没学生正好整理了,呵呵!
1什么是单点登陆
单点登录(SingleSignOn),简称为SSO,是目前比较流行的企业业务整合的解决方案之一。
SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
较大的企业内部,一般都有很多的业务支持系统为其提供相应的管理和IT服务。
例如财务系统为财务人员提供财务的管理、计算和报表服务;人事系统为人事部门提供全公司人员的维护服务;各种业务系统为公司内部不同的业务提供不同的服务等等。
这些系统的目的都是让计算机来进行复杂繁琐的计算工作,来替代人力的手工劳动,提高工作效率和质量。
这些不同的系统往往是在不同的时期建设起来的,运行在不同的平台上;也许是由不同厂商开发,使用了各种不同的技术和标准。
如果举例说国内一著名的IT公司(名字隐去),内部共有60多个业务系统,这些系统包括两个不同版本的SAP的ERP系统,12个不同类型和版本的数据库系统,8个不同类型和版本的操作系统,以及使用了3种不同的防火墙技术,还有数十种互相不能兼容的协议和标准,你相信吗?
不要怀疑,这种情况其实非常普遍。
每一个应用系统在运行了数年以后,都会成为不可替换的企业IT架构的一部分,如下图所示。
随着企业的发展,业务系统的数量在不断的增加,老的系统却不能轻易的替换,这会带来很多的开销。
其一是管理上的开销,需要维护的系统越来越多。
很多系统的数据是相互冗余和重复的,数据的不一致性会给管理工作带来很大的压力。
业务和业务之间的相关性也越来越大,例如公司的计费系统和财务系统,财务系统和人事系统之间都不可避免的有着密切的关系。
为了降低管理的消耗,最大限度的重用已有投资的系统,很多企业都在进行着企业应用集成(EAI)。
企业应用集成可以在不同层面上进行:
例如在数据存储层面上的“数据大集中”,在传输层面上的“通用数据交换平台”,在应用层面上的“业务流程整合”,和用户界面上的“通用企业门户”等等。
事实上,还用一个层面上的集成变得越来越重要,那就是“身份认证”的整合,也就是“单点登录”。
通常来说,每个单独的系统都会有自己的安全体系和身份认证系统。
整合以前,进入每个系统都需要进行登录,这样的局面不仅给管理上带来了很大的困难,在安全方面也埋下了重大的隐患。
下面是一些著名的调查公司显示的统计数据:
∙用户每天平均16分钟花在身份验证任务上-资料来源:
IDS
∙频繁的IT用户平均有21个密码-资料来源:
NTAMonitorPasswordSurvey
∙49%的人写下了其密码,而67%的人很少改变它们
∙每79秒出现一起身份被窃事件-资料来源:
NationalSmallBusinessTravelAssoc
∙全球欺骗损失每年约12B-资料来源:
CommFraudControlAssoc
∙到2007年,身份管理市场将成倍增长至$4.5B-资料来源:
IDS
使用“单点登录”整合后,只需要登录一次就可以进入多个系统,而不需要重新登录,这不仅仅带来了更好的用户体验,更重要的是降低了安全的风险和管理的消耗。
请看下面的统计数据:
∙提高IT效率:
对于每1000个受管用户,每用户可节省$70K
∙帮助台呼叫减少至少1/3,对于10K员工的公司,每年可以节省每用户$75,或者合计$648K
∙生产力提高:
每个新员工可节省$1K,每个老员工可节省$350-资料来源:
Giga
∙ROI回报:
7.5到13个月-资料来源:
Gartner
另外,使用“单点登录”还是SOA时代的需求之一。
在面向服务的架构中,服务和服务之间,程序和程序之间的通讯大量存在,服务之间的安全认证是SOA应用的难点之一,应此建立“单点登录”的系统体系能够大大简化SOA的安全问题,提高服务之间的合作效率。
2单点登陆的技术实现机制
随着SSO技术的流行,SSO的产品也是满天飞扬。
所有著名的软件厂商都提供了相应的解决方案。
而是对SSO技术本身进行解析,并且提供自己开发这一类产品的方法和简单演示。
单点登录的机制其实是比较简单的,用一个现实中的例子做比较。
颐和园是北京著名的旅游景点。
在颐和园内部有许多独立的景点,例如“苏州街”、“佛香阁”和“德和园”,都可以在各个景点门口单独买票。
很多游客需要游玩所有德景点,这种买票方式很不方便,需要在每个景点门口排队买票,钱包拿进拿出的,容易丢失,很不安全。
于是绝大多数游客选择在大门口买一张通票(也叫套票),就可以玩遍所有的景点而不需要重新再买票。
他们只需要在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。
单点登录的机制也一样,如下图所示,当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录
(1);根据用户提供的登录信息,认证系统进行身份效验,如果通过效验,应该返回给用户一个认证的凭据--ticket
(2);用户再访问别的应用的时候(3,5)就会将这个ticket带上,作为自己认证的凭据,应用系统接受到请求之后会把ticket送到认证系统进行效验,检查ticket的合法性(4,6)。
如果通过效验,用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
从上面的视图可以看出,要实现SSO,需要以下主要的功能:
∙所有应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。
认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。
另外,认证系统还应该对ticket进行效验,判断其有效性。
∙所有应用系统能够识别和提取ticket信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。
应用系统应该能对ticket进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
上面的功能只是一个非常简单的SSO架构,在现实情况下的SSO有着更加复杂的结构。
有两点需要指出的是:
∙单一的用户信息数据库并不是必须的,有许多系统不能将所有的用户信息都集中存储,应该允许用户信息放置在不同的存储中,如下图所示。
事实上,只要统一认证系统,统一ticket的产生和效验,无论用户信息存储在什么地方,都能实现单点登录。
∙统一的认证系统并不是说只有单个的认证服务器,如下图所示,整个系统可以存在两个以上的认证服务器,这些服务器甚至可以是不同的产品。
认证服务器之间要通过标准的通讯协议,互相交换认证信息,就能完成更高级别的单点登录。
如下图,当用户在访问应用系统1时,由第一个认证服务器进行认证后,得到由此服务器产生的ticket。
当他访问应用系统4的时候,认证服务器2能够识别此ticket是由第一个服务器产生的,通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信息,仍然能够完成SSO的功能。
3WEB-SSO的实现(ASP.NET安全认证)
ASP.NET的安全认证,共有“Windows”“Form”“Passport”“None”四种验证模式。
“Windows”与“None”没有起到保护的作用,不推荐使用;“Passport”我又没用过,唉……所以我只好讲讲“Form”认证了。
我打算分三部分:
第一部分——怎样实现From认证;
第二部分——Form认证的实战运用;
第三部分——实现单点登录(SingleSignOn)
3.1第一部分——怎样实现From认证;
一、新建一个测试项目
为了更好说明,有必要新建一个测试项目(暂且为“FormTest”吧),包含三张页面足矣(Default.aspx、Login.aspx、UserInfo.aspx)。
啥?
有人不会新建项目,不会新增页面?
你问我咋办?
我看这么办好了:
拖出去,打回原藉,从幼儿园学起……
二、修改Web.config
1、双击项目中的Web.config(不会的、找不到的打PP)
2、找到下列文字
3、找到
">
这里没什么好说的,只要拷贝过去就行。
虽说如此,但还是有人会弄错,如下:
"> 若要问是谁把 ">放入 三、编写.cs代码——登录与退出 1、登录代码: a、书本上介绍的 privatevoidBtn_Login_Click(objectsender,System.EventArgse) { if(this.Txt_UserName.Text=="Admin"&&this.Txt_Password.Text=="123456") { System.Web.Security.FormsAuthentication.RedirectFromLoginPage(this.Txt_UserName.Text,false); } } b、偶找了N久才找到的 privatevoidBtn_Login_Click(objectsender,System.EventArgse) { if(this.Txt_UserName.Text=="Admin"&&this.Txt_Password.Text=="123456") { System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false); Response.Redirect("Default.aspx"); } } 以上两种都可发放验证后的Cookie,即通过验证,区别: 方法a)指验证后返回请求页面,俗称“从哪来就打哪去”。 比如: 用户没登录前直接在IE地址栏输入http: //localhost/FormTest/UserInfo.aspx,那么该用户将看到的是Login.aspx? ReturnUrl=UserInfo.aspx,输入用户名与密码登录成功后,系统将根据“ReturnUrl”的值,返回相应的页面 方法b)则是分两步走: 通过验证后就直接发放Cookie,跳转页面将由程序员自行指定,此方法多用于Default.aspx使用框架结构的系统。 2、退出代码: privatevoidBtn_LogOut_Click(objectsender,System.EventArgse) { System.Web.Security.FormsAuthentication.SignOut(); } 四、如何判断验证与否及获取验证后的用户信息 有的时候,在同一张页面需要判断用户是否已经登录,然后再呈现不同的布局。 有人喜欢用Session来判断,我不反对此类做法,在此我只是想告诉大家还有一种方法,且看下面代码: if(User.Identity.IsAuthenticated) { //你已通过验证,知道该怎么做了吧? } 3.2第二部分Form认证的实战运用 五、Web.config的作用范围 新建项目时,VS.Net会在项目根目录建立一个内容固定的Web.config。 除了在项目根目录,你还可以在任一目录下建立Web.config,条件就是应用程序级别的节点只能在根目录的Web.config中出现。 至于哪些是应用程序级别节点呢,这个问题嘛,其实我也不太清楚,呵呵。 电脑不是我发明的,微软不是我创建的,C#更不是我说了算的,神仙也有不知道的,所以我不晓得是正常的。 话虽如此,只要它不报错,那就是对的。 关于Web.config设置的作用范围,记住以下两点: 1、Web.config的设置将作用于所在目录的所有文件及其子目录下的所有东东(继承: 子随父姓) 2、子目录下的Web.config设置将覆盖由父目录继承下来的设置(覆盖: 县官不如现管) 给大家提个问题: 有没有比根目录Web.config的作用范围还大的配置文件呢? 看完第三部分便知分晓。 六、学会拒绝与巧用允许 回到我们在第一回合新建的测试项目“FormTest”,既然要进行验证,按国际惯例,就得有用户名与密码。 那,这些用户是管理员自己在数据库建好呢,还是用户注册、管理员审核好呢。 只要不是一般的笨蛋,都知道选择后者。 你们还别说,我公司还真有个别项目是管理员连到数据库去建帐号的,属于比较特殊的笨蛋,咱们不学他也罢,还是老老实实添加两个页面吧——注册页面(Register.aspx)与审核页面(Auditing.aspx)。 问题终于就要浮出水面啦,当你做好Register.aspx时,想访问它的时候突然觉得不对劲,怎么又回到了登录页面? 你仔细瞧瞧网址,是不是成了: Login.aspx? ReturnUrl=Register.aspx。 怎么办,用户就是因为没有帐号才去访问注册页面的呀? (这句纯属废话,有帐号谁还跑去注册。 )我时常对我的同事说: “办法是人想出来滴! ! ” 1、新建一个目录Public,用于存放一些公用的文件,如万年历、脚本呀…… 2、在“解决方案资源管理器”中右击点击目录Public,新增一个Web.config 3、把上述Web.config的内容统统删除,仅留以下即可: xmlversion="1.0"encoding="utf-8"? > 终于切入正题了,不容易呀。 根据“覆盖”原则,我们知道上述Web.config将替代根目录Web.config中的 "> 注解: “allow”允许的意思;“*”表示所有用户; “deny”拒绝的意思;“? ”表示匿名用户; 因此,处于Public目录下的文件,允许所有人浏览,包括未验证的用户。 把Register.aspx拖进来吧,再也不会有人阻止你浏览啦。 除了注册页面,我们还提到一个审核页面(Auditing.aspx),审核权限一般都在管理员或主管手里,并不想让其他人浏览此页面(真理往往掌握在少数人的手里,这也是没法子的事),怎么办? “办法是人想出来滴”呵呵……新建一个管理员的目录ManageSys,在此目录下再新增一个Web.config。 内容如下: xmlversion="1.0"encoding="utf-8"? > 现在的问题就是怎么才能知道谁是“Admin”呢,这个问题就有点象“我的鞋底有个洞”——天不知地知,你不知我知。 闲话少说,大家还记得我在第一部分的结尾吗? 什么,忘啦! 罚你回去看一百遍,记住了再回来。 站住,回来! 一想到你的记性,我就不放心,第一部分的浏览网址是,回到此处的网址是 好了,不管那些记不好的家伙了,大伙继续往下看。 System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false);//通过验证,发放Cookie 之前我曾强调,要注意,第一个参数很重要,重要到什么程度? 说到这,恐怕地球人都知道了——它就是allow与deny的依据。 假如此处用户填写的是“Admin”即this.Txt_UserName.Text="Admin";那么进入系统后,他就能访问ManageSys目录下的网页了,其它闲杂人等一律拒之门外。 为巩固上述内容,给大伙留个课外作业: 此项目有两部门使用,其中每个部门分别都有些特定的页面仅供本部门用户浏览使用,请问该如何使用Web.config达到效果? 同样,答案在第三部分揭晓 七、分散与集中 乍看之下,就象是马克思列宁主义、毛泽东思想、邓小平理论中的辩证关系,大伙放心,偶是学理科的,只明白“高举程序员的伟大旗帜,以编写代码为中心”。 停…… 到目前为此,我们的测试项目“FormTest”已经拥有两个目录三个Web.config,伴随用户需求的多样化,Web.config也会越来越多,比如常用的文件上传功能等等。 众多的Web.config分布在不同的目录里面,维护起来肯定比较烦人。 能不能集中起来管理呢,应该咋办哩? “办法是……”哟,有人先说出来啦。 不错,“办法的确是人想出来滴”,我不说,你是不是只有在一边凉伴? 开玩笑的,为了让更多的人记住这句话,我打算告诉你集中管理的办法。 要想集中管理,不得不用到 在本项目中,我们将目录Public与ManageSys下的设置放在根目录下的Web.config里面,如下: xmlversion="1.0"encoding="utf-8"? > --这里放置原来根目录Web.config的内容,就不列出来了--> 需要提醒的是 1、 2、 八、额外的保护 第二部分就要结束了,现在时间已是凌晨4点50分,我容易嘛我。 认证的目的就是为了防止他人非法浏览页面,或未经许可使用某些功能。 当然,世上没有绝对的安全,如今MD5加密都被我们国人给破解了,就是最好的例证。 细心的人可能早就发现ASP.NET的安全认证只针对.aspx、.ascx……等ASP.NET文件起作用,而对普通页面与文件却“视而不见”,如.htm、.js、.jpg等。 通过以下步骤你就可以保护你想保护的文件类型。 1、 打开Internet信息服务(IIS)管理器→右击本项目虚拟→属性,如下图 2、 点击按钮“配置”,出现如下对话框: 3、 双击.aspx的应用程序扩展→查看对话框内容,如下图: 4、 复制“可执行文件”的全路径名称后→点击“取消”返回上一层对话框→点击按钮“添加” 5、 粘贴刚才复制的内容(我的系统装在D盘,所以内容为D: /WINDOWS/Microsoft.NET/Framework/v1.1.4322/aspnet_isapi.dll)→填写后缀名为.htm→填写动作限制为“GET,HEAD,POST,DEBUG”(为方便省事你可选全部) 6、 最后点击“确定”→往项目中添加HtmlPage1.htm→在IE浏览器的地址栏直接输入http: //localhost/FormTest/HtmlPage1.htm→观看测试效果 3.3第三部分实现单点登录(SingleSignOn) Web.config中的 好了,接下来就要揭开“比根目录Web.config的作用范围还大的配置文件”之谜啦,它就是藏匿在Windows系统目录下,支配整个.NetFramework配置的传说中的Machine.config! ! 下面请大家以热烈的掌声,欢迎我们这位神秘侠客的闪亮登场…… 九、Machine.config Machine.config,性别不详,年龄未知,家庭出身: XML。 深藏于“云深不知处”的操作系统目录下的某某地方(注: C: \WINDOWS【或WINNT】\Microsoft.NET\Framework\v1.1.4322【或v1.0.3705】\CONFIG),控制着“更上一层楼”的.NETFramework的本机配置。 接下来简要的讲解一下它的内容,以及它与
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 单点 登录 SSO 详解