单点登录SSO详解Word下载.docx
- 文档编号:21609709
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:27
- 大小:324.63KB
单点登录SSO详解Word下载.docx
《单点登录SSO详解Word下载.docx》由会员分享,可在线阅读,更多相关《单点登录SSO详解Word下载.docx(27页珍藏版)》请在冰豆网上搜索。
∙49%的人写下了其密码,而67%的人很少改变它们
∙每79秒出现一起身份被窃事件-资料来源:
NationalSmallBusinessTravelAssoc
∙全球欺骗损失每年约12B-资料来源:
CommFraudControlAssoc
∙到2007年,身份管理市场将成倍增长至$4.5B-资料来源:
使用“单点登录”整合后,只需要登录一次就可以进入多个系统,而不需要重新登录,这不仅仅带来了更好的用户体验,更重要的是降低了安全的风险和管理的消耗。
请看下面的统计数据:
∙提高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、找到下列文字<
authenticationmode="
Windows"
/>
把它改成:
<
Forms"
>
formsloginUrl="
Login.aspx"
name="
.ASPXAUTH"
/forms>
/authentication>
3、找到<
authorization>
<
allowusers="
*"
/authorization>
换成
denyusers="
?
"
/deny>
这里没什么好说的,只要拷贝过去就行。
虽说如此,但还是有人会弄错,如下:
.APSX"
若要问是谁把<
放入<
authentication>
中的,我会很荣幸地告诉你,那是N年前的我:
与<
都是以auth字母开头又都是以ation结尾,何其相似;
英文单词背不下来的我以为他们是一伙的……
三、编写.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久才找到的
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"
configuration>
system.web>
/>
/system.web>
/configuration>
终于切入正题了,不容易呀。
根据“覆盖”原则,我们知道上述Web.config将替代根目录Web.config中的<
节点设置,即:
替换<
注解:
“allow”允许的意思;
“*”表示所有用户;
“deny”拒绝的意思;
“?
”表示匿名用户;
因此,处于Public目录下的文件,允许所有人浏览,包括未验证的用户。
把Register.aspx拖进来吧,再也不会有人阻止你浏览啦。
除了注册页面,我们还提到一个审核页面(Auditing.aspx),审核权限一般都在管理员或主管手里,并不想让其他人浏览此页面(真理往往掌握在少数人的手里,这也是没法子的事),怎么办?
“办法是人想出来滴”呵呵……新建一个管理员的目录ManageSys,在此目录下再新增一个Web.config。
内容如下:
现在的问题就是怎么才能知道谁是“Admin”呢,这个问题就有点象“我的鞋底有个洞”——天不知地知,你不知我知。
闲话少说,大家还记得我在第一部分的结尾吗?
什么,忘啦!
罚你回去看一百遍,记住了再回来。
站住,回来!
一想到你的记性,我就不放心,第一部分的浏览网址是,回到此处的网址是
好了,不管那些记不好的家伙了,大伙继续往下看。
//通过验证,发放Cookie
之前我曾强调,要注意,第一个参数很重要,重要到什么程度?
说到这,恐怕地球人都知道了——它就是allow与deny的依据。
假如此处用户填写的是“Admin”即this.Txt_UserName.Text="
;
那么进入系统后,他就能访问ManageSys目录下的网页了,其它闲杂人等一律拒之门外。
为巩固上述内容,给大伙留个课外作业:
此项目有两部门使用,其中每个部门分别都有些特定的页面仅供本部门用户浏览使用,请问该如何使用Web.config达到效果?
同样,答案在第三部分揭晓
七、分散与集中
乍看之下,就象是马克思列宁主义、毛泽东思想、邓小平理论中的辩证关系,大伙放心,偶是学理科的,只明白“高举程序员的伟大旗帜,以编写代码为中心”。
停……
到目前为此,我们的测试项目“FormTest”已经拥有两个目录三个Web.config,伴随用户需求的多样化,Web.config也会越来越多,比如常用的文件上传功能等等。
众多的Web.config分布在不同的目录里面,维护起来肯定比较烦人。
能不能集中起来管理呢,应该咋办哩?
“办法是……”哟,有人先说出来啦。
不错,“办法的确是人想出来滴”,我不说,你是不是只有在一边凉伴?
开玩笑的,为了让更多的人记住这句话,我打算告诉你集中管理的办法。
要想集中管理,不得不用到<
location>
节点与path属性。
在本项目中,我们将目录Public与ManageSys下的设置放在根目录下的Web.config里面,如下:
locationpath="
Public"
/location>
ManageSys"
!
--这里放置原来根目录Web.config的内容,就不列出来了-->
需要提醒的是
1、<
节点的位置是在<
的一个子节点,它与原有的<
属于并列关系
2、<
节点只需要放入对应子目录Web.config中的<
的节点内容
八、额外的保护
第二部分就要结束了,现在时间已是凌晨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中的<
节点的path属性可以是一张具体页面的相对URL路径,如下:
ManageSys/Auditing.aspx"
好了,接下来就要揭开“比根目录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 详解
![提示](https://static.bdocx.com/images/bang_tan.gif)