|
|
马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
你觉得学习.NET怎么样，我懂的少，问的可能很幼稚，见笑了啊：）团结平安的方针是供应在域间创建信托干系的机制，如许，用户经由过程本人所属域的身份考证后，就取得了受权能够会见其他域的使用程序和服务。这使单一登录如许的身份考证办法成为大概，接纳这类办法，无需针对多个使用程序和域为用户设置和办理反复帐户，从而光鲜明显下降将使用程序扩大到受信托方的本钱。 在团结平安模子中，身份标识供应程序(IdP)实行身份考证，并经由过程平安令牌服务(STS)发表平安令牌。这些令牌断言有关经由身份考证的用户的信息：用户身份标识和其他大概的信息（包含脚色和更细粒度的会见权限）。在团结手艺范畴，这些信息称为声明，基于声明的会见把持是团结平安模子的中心。在这一模子中，使用程序和服务依据来自受信托发表机构(STS)的声明，对特征和功效的会见举行受权。
WindowsIdentityFoundation(WIF)等平台工具年夜年夜下降了撑持这类团结身份考证的难度。WIF是一个身份标识模子框架，用于构建基于声明的使用程序和服务，撑持基于SOAP（自动）和基于扫瞄器（主动）的团结计划。在MSDN杂志2009年11月刊中的文章“经由过程WIF完成基于声明的受权”中，我重点先容了怎样在WindowsCommunicationFoundation(WCF)中利用WIF。在这篇文章中，我先容了怎样为WCF服务虚现基于声明的平安模子，和怎样迁徙到团结身份考证。
在本后续文章中，我将重点先容主动团结。我将申明主动团结的通讯流程，先容几种在ASP.NET使用程序中撑持团结的办法，会商基于声明的ASP.NET受权办法，然后先容单一登录和单一刊出计划。同时，我将先容撑持主动团结计划的基本WIF功效和组件。
主动团结基本
主动团结计划基于WS-Federation标准。该标准划定了怎样哀求平安令牌，怎样公布和猎取团结元数据文档，从而简化创建信托干系的历程。WS-Federation还划定了单一登录和刊出历程，和其他团结完成观点。
WS-Federation会商了有联系关系合的诸多细节，个中有一部分专门先容基于扫瞄器的团结，这类团结依托HTTPGET和POST、扫瞄重视定向和Cookie完成方针。
主动团结动静传送的某些方面次要基于WS-Trust标准。比方，在哀求STS的平安令牌时，主动团结接纳与扫瞄器兼容的“哀求平安令牌”(RST)和“RST呼应”(RSTR)情势。在主动团结计划中，我将RST称为登录哀求动静，将RSTR称为登录呼应动静。WS-Trust标准偏重于基于SOAP（自动）的团结，如Windows客户端与WCF服务的团结。
是一个复杂的主动团结计划。
复杂主动团结计划
用户在本人的域经由过程身份考证，依据其脚色取得Web使用程序会见权限。此身份考证计划中的介入者包含用户（主体）、Web扫瞄器（哀求者）、ASP.NET使用程序（依附方，即RP）、卖力在用户域中对用户举行身份考证的IdP，和属于用户域的STS(IP-STS)。一系列的扫瞄重视定向操纵能够确保用户在会见RP之前在本人的域内经由过程身份考证。
用户扫瞄至RP使用程序(1)，然后重定向到用户的IdP举行身份考证(2)。假如用户还没有在IdP经由身份考证，IP-STS大概举行质询，或将用户重定向到登录页面以搜集凭证(3)。用户供应本人的凭证(4)，然后由IP-STS(5)举行身份考证。此时，IP-STS依据登录哀求发表平安令牌，包括该令牌的登录呼应经由过程扫瞄重视定向发送到RP(6)。RP处置平安令牌，依据令牌照顾的声明授与会见权限(7)。假如乐成受权，则向用户显现其最后哀求的页面，而且前往会话Cookie(8)。
利用WIF和ASP.NET完成此主动团结计划只必要几个步骤：
创建RP和IdP(IP-STS)之间的信托干系
对ASP.NET使用程序启用主动团结
完成受权反省，以把持对使用程序功效的会见。在前面几节中，我将会商撑持主动团结的WIF功效，演示设置此复杂计划的步骤，然后会商此计划和其他计划在理论中应注重的事项。
撑持主动团结的WIF功效
在会商完成之前，我们回忆一下WIF公用于在ASP.NET使用程序中撑持团结身份考证的功效。起首，WIF供应以下有效的HTTP模块：
WSFederationAuthenticationModule(FAM)：撑持基于扫瞄器的团结，重定向到得当的STS以举行身份考证和令牌发表，处置天生的登录呼应，将已发表平安令牌创立为ClaimsPrincipal以举行受权。此模块还处置其他主要的团结动静，如刊出哀求。
SessionAuthenticationModule(SAM)：经由过程天生包括ClaimsPrincipal的会话平安令牌，办理经由身份考证的会话，将会话平安令牌写进Cookie，办理会话Cookie的保存期，假如Cookie已存在，则依据Cookie重修ClaimsPrincipal。此模块还包括一个当地会话令牌缓存。
ClaimsAuthorizatonModule：供应一个可扩大点，以便安装自界说ClaimsAuthorizationManager，后者关于会合会见反省十分有效。
ClaimsPrincipalHttpModule：依据附加到哀求线程确当前用户身份创立ClaimsPrincipal。别的，该模块还供应一个可扩大点来安装自界说ClaimsAuthenticationManager，后者用于自界说将附加到哀求线程的ClaimsPrincipal。
ClaimsPrincipalHttpModule最合适不利用主动团结的使用程序。您可将该模块看做一个有效的工具，在ASP.NET使用程序迁徙到主动团结之前，它可用来在使用程序内完成基于声明的平安模子。我在之前的文章中会商过这一WCF办法。
其他三种模块一般一同用于主动团结―不外ClaimsAuthorizationModule是可选的。演示这些中心模块怎样组成哀求管道，和这些模块在典范的团结身份考证哀求中的功效。
主动团结接纳的WIF组件和HTTP模块
请注重中的主动团结流程，当用户起首扫瞄至RP中的受回护页面时(1)，对使用程序的会见将被回绝。FAM处置还未受权的哀求，天生登录动静，然后将用户重定向到IP-STS(2)。IP-STS考证用户身份(3)，天生登录呼应（包括发表的平安令牌），然后重定向回RP使用程序(4)。
FAM处置登录呼应（确保呼应包括经由身份考证的用户的无效平安令牌），依据登录呼应创立ClaimsPrincipal(5)。这将为哀求线程和HttpContext设置平安主体。然后，FAM利用SAM将ClaimsPrincipal序列化为HTTPCookie(6)，在扫瞄器会话时代用于后续哀求。假如安装了ClaimsAuthorizationModule，该模块将挪用经由设置的ClaimsAuthorizationManager，以便在会见哀求的资本之前针对ClaimsPrincipal实行全局会见反省(7)。
只需哀求的资本存在，就能够完成会见把持，这一历程必要利用传统的ASP.NET登录控件、IsInRole反省和其他查询用户声明的自界说代码(8)。
举行后续哀求时，将利用该会话令牌和SAM之前写进的Cookie(9)。这时候，SAM会考证会话令牌，依据令牌从头创立ClaimsPrincipal(10)。仅当哀求是登录呼应、刊出哀求，大概哀求被回绝时（未供应会话令牌大概会话令牌已生效时，大概产生），FAM才举行考证。
除上述模块以外，主动团结中另有两个很有效的ASP.NET控件：
FederatedPassiveSignIn控件：在以下情形下可替换FAM：假如使用程序将一切未经受权的挪用重定向到登录页面，而登录页面只在必要身份考证时才承载此控件。这里假定用户将与登录历程举行交互，该历程在逐级身份考证计划中很有效，在这类计划中，将提醒用户供应凭证（多是除原始登录凭证以外，使用程序请求的其他凭证）。该控件处置到STS的重定向，处置登录呼应，依据呼应初始化ClaimsPrincipal，并使用FAM和SAM公然的功效创建平安会话。
FederatedPassiveSignInStatus控件：此控件供应交互体例，供用户登录RP使用程序或从中刊出，而且撑持团结刊出。
演示接纳FederatedPassiveSignIn控件时通讯流程是怎样变更的。使用程序利用窗体身份考证来回护资本，偏重定向到承载该控件的登录页面(1)。用户单击FederatedPassiveSignIn控件（或主动重定向到该控件），会触发到STS的重定向(2)。控件页面从STS吸收呼应，经由过程FAM和SAM处置登录呼应(3)，创立ClaimsPrincipal，然后写进会话Cookie(4)。当用户重定向到最后哀求的页面时(5)，SAM考证会话Cookie，并为登录哀求创立ClaimsPrincipal。此时，ClaimsAuthorizationModule和该页面能够实行受权反省，如所示。
利用FederatedPassive-SignIn控件的主动团结
FAM和SAM都经由过程得当的SecurityTokenHandler范例处置传进令牌。登录呼应抵达时，FAM轮回会见SecurityTokenHandlerCollection，查找准确的令牌处置程序来读取XML令牌。在团结计划中，这个令牌处置程序一般是Saml11SecurityTokenHandler或Saml2SecurityTokenHandler，经由过程增加自界说令牌处置程序，您也能够接纳其他令牌格局。SAM利用SessionSecurityTokenHandler处置预会话Cookie相干联的会话令牌。
关于主动团结流程而言，某些身份标识模子设置设置非常主要，这些设置用于初始化FAM、SAM和FederatedPassiveSignIn控件（固然，后者也会公然可在VisualStudio计划器中设置的属性）。您能够以编程体例供应Microsoft.IdentityModel.Configuration定名空间的ServiceConfiguration范例的实例，也能够在<microsoft.identityModel>节中供应声明性设置。总结了身份标识模子设置，本文前面几部分将对个中良多设置举行先容。
基础<microsoft.identityModel>元素汇总
节申明<issuerNameRegistry>指定受信托证书发表机构的列表。此列表次要用于考证令牌署名，以便回绝不受信托的证书所署名的令牌。<audienceUris>指定传进SAML令牌的无效会见者URI的列表。可经由过程禁用此项同意一切URI，但不倡议如许做。<securityTokenHandlers>自界说令牌处置程序的设置设置，或供应自界说令牌处置程序，用于把持对令牌举行考证、身份考证和序列化的体例。<maximumClockSkew>调剂令牌和使用程序服务器之间的同意工夫差，以举行令牌考证。默许偏向工夫为5分钟。<certificateValidation>把持证书的考证体例。<serviceCertificate>供应一个服务证书，用于对传进令牌举行解密。<claimsAuthenticationManager>供应一个自界说ClaimsAuthenticationManager范例，用于自界说或交换要附加到哀求线程的IClaimsPrincipal范例。<claimsAuthorizationManager>供应一个自界说ClaimsAuthorizationManager范例，用于从中央组件把持对功效的会见。<federatedAuthentication>供应特定于主动团结的设置。
启用主动团结
WIF简化了为ASP.NET使用程序设置主动团结的历程。STS应供应团结元数据（依照WS-Federation标准中的申明），WIF供应团结有用工具(FedUtil.exe)，该工具利用团结元数据创建RP和STS之间的信托（和对自动和主动团结计划都合用的其他功效）。经由过程在VisualStudio中右键单击RP项目，然后选择“增加STS援用”，大概经由过程命令行，都能够挪用FedUtil。
您将利用FedUtil导游完成以下复杂步骤：
在导游的第一页上，确认导游要修正的设置文件和RP使用程序URI。
在第二页上，指定将与RP创建信托干系的STS的团结元数据XML文档路径。
在第三页上，供应用于解密令牌的证书。
最初一页是STS供应的声明的列表，举例来讲，使用这个列表，您能够计划会见把持决议。
完成上述导游步骤后，FedUtil会修正项目，以便增加一个对Microsoft.IdentityModel程序集的援用。它还会修正web.config，以便安装FAM和SAM模块，并为这些模块供应身份标识模子设置设置。如今，使用程序就撑持主动团结了，会将未经受权的哀求重定向到受信托的STS。
这里存在一个假定，即STS事前晓得RP（因而会为实验会见RP的经由身份考证的用户发表令牌），而且具有RP请求STS在加密令牌时利用的公钥。这是对ASP.NET使用程序举行开端团结设置的烦琐办法。固然，这有助于了解怎样在必要调剂时重新入手下手举行设置，和怎样变动导游启用的基础设置。从如今起，我将重点先容“重新入手下手设置”办法。
假如不利用FedUtil，您必要手动增加一个对Microsoft.IdentityModel程序集的援用，然先手动设置FAM和SAM模块和需要的身份标识模子设置。HTTP模块应增加到两个部分：InternetInformationServices(IIS)6的system.web和IIS7的system.webServer。假定使用程序承载于IIS7中，WIF模块的设置以下：
<modules>
<!--other modules-->
<add name="SessionAuthenticationModule"
type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
preCondition="managedHandler" />
<add name="WSFederationAuthenticationModule"
type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
preCondition="managedHandler" />
</modules>
默许情形下，此设置仅回护扩大名举行了显式映照，以便由ASP.NET管道处置的资本（.aspx、.asax等等）。为了回护团结身份考证的其他资本，应将这些扩大名映照到IIS中的ASP.NET管道，或在模块设置中，将runAllManagedModulesForAllRequests设置为true（只合用于IIS7），以下所示：
<modules runAllManagedModulesForAllRequests="true">
为启动FAM，您还必需将ASP.NET身份考证形式设置为None，回绝匿名用户会见使用程序资本：
<authentication mode="None" />
<authorization>
<deny users="?" />
</authorization>
两种模块都利用所示的身份标识模子设置设置，典范示比方所示。这些设置年夜多半是由FedUtil天生的，但certificateValidation设置和federatedAuthentication中的某些设置除外。我一般保举利用PeerTrust证书考证形式，该形式必要将一切受信托证书（包含受信托发表机构的证书）显式增加到当地盘算机的TrustedPeople存储。
主动团结的身份标识模子设置
<microsoft.identityModel>
<service>
<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<trustedIssuers>
<add thumbprint="EF38A0A6D1274766093D3D78BFE4ECA77C62D5C3"
name="http://localhost:60768/STS/" />
</trustedIssuers>
</issuerNameRegistry>
<certificateValidation certificateValidationMode="PeerTrust"
revocationMode="Online" trustedStoreLocation="LocalMachine"/>
<audienceUris>
<add value="http://localhost:50652/ClaimsAwareWebSite2/" />
</audienceUris>
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true"
issuer="http://localhost:60768/STS/"
realm="http://localhost:50652/ClaimsAwareWebSite2/"
requireHttps="true" />
<cookieHandler requireSsl="true" name="FedAuth"
hideFromScript="true" path="/ClaimsAwareWebSite2" />
</federatedAuthentication>
<serviceCertificate>
<certificateReference x509FindType="FindByThumbprint"
findValue="8A90354199D284FEDCBCBF1BBA81BA82F80690F2"
storeLocation="LocalMachine" storeName="My" />
</serviceCertificate>
</service>
</microsoft.identityModel>
主动团结中一般必要HTTPS/SSL来回护发表的持有者令牌免受两头人的打击，而且必要对会话Cookie利用HTTPS/SSL。默许情形下，Cookie对剧本是埋没的，但它是一项主要设置，以是我在中对它举行了设置。
至于Cookie的称号和路径，称号默许为FedAuth，路径为使用程序目次。为Cookie指定独一称号大概很有效，特别是在办理计划中良多RP使用程序共享统一个域的情形下。相反，假如但愿统一个域中多个使用程序共享Cookie，您能够选择指定一个通用路径。
在接纳FAM和SAM的主动团结中，一般利用FedUtil设置ASP.NET使用程序，然后依据办理计划的请求调剂响应设置。您也能够利用PassiveFederationSignIn控件来取代FAM，如所示。您能够在microsoft.identityModel节中加载该控件的设置，也能够间接设置控件属性。
假如但愿将未经受权的哀求重定向到登录页面（用户能够在此经由过程单击该控件举行显式登录）而不是由FAM主动重定向到STS，控件办法会很有效。比方，假如用户属于多个身份标识供应程序（当地域），登录页面大概会供应一种机制，供用户在重定向到STS之前唆使其当地域。我稍后会会商当地域辨认。
主动令牌发表
如前所述，主动团结利用HTTPGET、POST和扫瞄重视定向，完成RP与STS之间的通讯。演示这一过程当中登录哀求和登录呼应中触及的次要哀求参数。
主动团结哀求中触及的次要登录哀求和呼应参数
STS吸收到登录哀求时，会依据它的已知RP域列表反省wtrealm参数，考证该RP是否是已知的。STS大概已有该RP的常识，即加密令牌所需的证书，和应包括在已发表令牌中的声明。假如该RP经由过程完全登录哀求供应可选的wreq参数，则能够唆使必要哪些声明，STS能够选择依据这个列表，也能够依据经由身份考证的用户自立决意对哪些声明受权。
在所示的复杂团结计划中，只要一个RP和一个IP-STS卖力用户身份考证。假如IP-STS针对Windows域举行用户身份考证，它大概发表脚色声明，如办理员、用户或宾客。条件是这些脚色关于RP受权是成心义的。鄙人一部分中，我假定这些脚色是成心义的，然后会商受权办法。在这以后，我将会商RP声明转换，依据必要将STS声明转换为关于受权加倍有效的内容。
基于声明的受权
我在之前的文章中提到过，.NETFramework中基于脚色的平安机制请求平安主体附加到每一个线程。平安主体（基于IPrincipal）在IIdentity完成中包装经由身份考证的用户的标识。WIF依据IClaimsPrincipal和IClaimsIdentity（终极由IPrincipal和IIdentity派生）供应ClaimsPrincipal和ClaimsIdentity范例。FAM处置登录呼应时，会为已发表平安令牌创立ClaimsPrincipal。一样，SAM也为会话Cookie创立ClaimsPrincipal。此ClaimsPrincipal是ASP.NET使用程序举行WIF受权的中心。
您可使用以下任何办法举行受权：
利用地位特定的受权设置限定对目次或各使用程序资本的会见。
利用ASP.NET登录控件（如LoginView控件）把持对功效的会见。
利用ClaimsPrincipal实行静态IsInRole反省（如静态埋没或显现UI元素）。
利用PrincipalPermission范例或PrincipalPermissionAttribute（假如声明性权限哀求看起来合用于某种特定办法）实行静态权限哀求。
供应自界说ClaimsAuthorizationManager，将会见权限反省会合在一个组件中，即便在加载哀求的资本之前也不破例。
在上述办法中，前三个必要利用ClaimsPrincipal范例公然的IsInRole办法。您必需选择一个合适于IsInRole反省的脚色声明范例，以便利用准确的声明把持会见。WIF的默许脚色声明范例为：
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
假如ClaimsPrincipal包括界说的声明，则脚色声明范例将与默许值婚配。稍后，我将会商声明转换高低文中的权限声明。利用这些声明时，应将权限声明范例指定为脚色声明范例，以便使IsInRole失效。
您可使用web.config文件对会见特定页面或特定目次举行全局把持。在使用程序根目次中供应一个地位标志，指定要回护的路径，同意可承受的脚色举行会见，回绝一切其他用户的会见。上面的代码只同意Administrators会见AdminOnly目次下的文件：
<location path="AdminOnly">
<system.web>
<authorization>
<allow roles="Administrators" />
<deny users="*"/>
</authorization>
</system.web>
</location>
别的，您还能够在任何子目次中安排web.config，用于指定受权划定规矩。将上面的设置安排到AdminOnly目次中，了局是一样的：
<configuration>
<system.web>
<authorization >
<allow roles="Administrators" />
<deny users="*"/>
</authorization>
</system.web>
</configuration>
要静态埋没或显现UI组件或把持对页面内功效的会见，可使用基于脚色的控件功效（如LoginView）。可是，年夜多半开辟职员更乐意在页面加载过程当中显式设置控件的会见把持属性，以取得更精密的把持。为此，您能够挪用ClaimsPrincipal公然的IsInRole办法。您能够经由过程Thread.CurrentPrincipal静态属性会见以后主体，以下所示：
if (!Thread.CurrentPrincipal.IsInRole("Administrators"))
throw new SecurityException("Access is denied.");
除在运转时显式反省IsInRole以外，还可使用PrincipalPermission范例写进传统的基于脚色的权限请求。还可使用所请求的脚色声明（第二个机关函数参数）初始化该范例，当挪用Demand时，将挪用以后主体的IsInRole办法。假如找不到该声明，则激发非常：
PrincipalPermission p =
new PrincipalPermission("", "Administrators");
p.Demand();
假如要在响应脚色不存在时回绝哀求并激发非常，此办法很有效。
会合处置一切被哀求资本的通用权限反省也是很有效的。偶然，假如有会见把持战略（如存储在数据库中的划定规矩），则可使用中央组件读取这些划定规矩，从而把持对特征和功效的会见。为此，WIF供应了一个能够扩大的ClaimsAuthorizationManager组件。我之前的文章中提到过，您能够在身份标识模子节设置这类自界说组件范例：
<microsoft.identityModel>
<service>
<!--other settings-->
<claimsAuthorizationManager
type="CustomClaimsAuthorizationManager"/>
</service>
</microsoft.identityModel>
演示一个自界说的ClaimsAuthorizationManager，它考证称号声明是不是存在，AdminsOnly目次内的被哀求资本是不是必要Administrators脚色声明。
自界说ClaimsAuthorizationManager完成
public class CustomClaimsAuthorizationManager:
ClaimsAuthorizationManager {
public CustomClaimsAuthorizationManager()
{ }
public override bool CheckAccess(
AuthorizationContext context) {
ClaimsIdentity claimsIdentity =
context.Principal.Identity as ClaimsIdentity;
if (claimsIdentity.Claims.Where(
x => x.ClaimType == ClaimTypes.Name).Count() <= 0)
throw new SecurityException("Access is denied.");
IEnumerable<Claim> resourceClaims =
context.Resource.Where(x=>x.ClaimType==ClaimTypes.Name);
if (resourceClaims.Count() > 0) {
foreach (Claim c in resourceClaims) {
if (c.Value.Contains("AdminOnly") &&
!context.Principal.IsInRole("Administrators"))
throw new SecurityException("Access is denied.");
}
}
return true;
}
}
CustomClaimsAuthorizationManager经由过程重写CheckAccess完成这一功效。此办法供应一个AuthorizationContext参数，该参数供应有关以下内容的信息：哀求操纵（关于主动团结来讲，是HTTP谓词，如GET或POST）、哀求的资本（一个URI）僧人未附加到哀求线程的ClaimsPrincipal。
声明转换
一般，IP-STS收回的声明对形貌经由身份考证的用户是有效的，但与RP的受权请求有关。IdP的义务不是懂得每一个RP的受权必要哪一种范例的脚色、权限或其他更细粒度的项，而是受权给身份标识供应程序域有关的声明，或IdP可针对经由身份考证的用户断言的声明。
因而，RP大概必要将声明从IP-STS转换为与受权加倍相干的项。这标明RP能够将用户标识映照（大概按用户称号或UPN）到RP声明集。假定IP-STS受权给默许脚色声明，列出了RP依照每一个传进脚色声明收回的大概权限声明集。权限声明范例能够是RP界说的自界说声明范例，如：
urn:ClaimsAwareWebSite/2010/01/claims/permission
自界说ClaimsAuthenticationManager很合适转换传进IP-STS声明。将以下代码增加到microsoft.identityModel节，能够安装自界说ClaimsAuthenticationManager：
<microsoft.identityModel>
<service>
<!--other settings-->
<claimsAuthenticationManager
type="CustomClaimsAuthenticationManager"/>
</service>
</microsoft.identityModel>
是一个示例CustomClaimsAuthenticationManager，它将IP-STS受权的传进脚色声明转换为与RP相干的权限声明。
将脚色声明转换为RP的权限声明
脚色声明权限声明AdministratorsCreate、Read、Update、DeleteUsersCreate、Read、UpdateGuestRead
RP自界说声明转换
public class CustomClaimsAuthenticationManager:
ClaimsAuthenticationManager {
public CustomClaimsAuthenticationManager() { }
public override IClaimsPrincipal Authenticate(
string resourceName, IClaimsPrincipal incomingPrincipal) {
IClaimsPrincipal cp = incomingPrincipal;
ClaimsIdentityCollection claimsIds =
new ClaimsIdentityCollection();
if (incomingPrincipal != null &&
incomingPrincipal.Identity.IsAuthenticated == true) {
ClaimsIdentity newClaimsId = new ClaimsIdentity(
"CustomClaimsAuthenticationManager", ClaimTypes.Name,
"urn:ClaimsAwareWebSite/2010/01/claims/permission");
ClaimsIdentity claimsId =
incomingPrincipal.Identity as ClaimsIdentity;
foreach (Claim c in claimsId.Claims)
newClaimsId.Claims.Add(new Claim(
c.ClaimType, c.Value, c.ValueType,
"CustomClaimsAuthenticationManager", c.Issuer));
if (incomingPrincipal.IsInRole("Administrators")) {
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Create"));
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Read"));
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Update"));
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Delete"));
}
else if (incomingPrincipal.IsInRole("Users")) {
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Create"));
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Read"));
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Update"));
}
else {
newClaimsId.Claims.Add(new Claim(
"urn:ClaimsAwareWebSite/2010/01/claims/permission",
"Read"));
}
claimsIds.Add(newClaimsId);
cp = new ClaimsPrincipal(claimsIds);
}
return cp;
}
}
为完成IsInRole反省（如前所述），您必需供应权限声明范例作为脚色声明范例。在中，这是在机关ClaimsIdentity时指定的，由于RP要创立ClaimsIdentity。
假如传进SAML令牌是声明的源，则能够向SecurityTokenHandler供应脚色声明范例。上面的代码申明怎样以声明体例设置Saml11SecurityTokenHandler，从而将权限声明范例用作脚色声明范例：
<microsoft.identityModel>
<service>
<!--other settings-->
<securityTokenHandlers>
<remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<samlSecurityTokenRequirement >
<roleClaimType
value= "urn:ClaimsAwareWebSite/2010/01/claims/permission"/>
</samlSecurityTokenRequirement>
</add>
</securityTokenHandlers>
</service>
</microsoft.identityModel>
SAML令牌处置程序包括samlSecurityTokenRequirement节，在该节中能够供应称号和脚色声明范例的设置，和与证书考证和Windows令牌相干的其他设置。
当地域辨认
在前文中，我已重点先容了包括单个IP-STS的复杂团结计划。假定RP一直重定向到特定IP-STS对用户举行身份考证。
不外，在团结手艺范畴，RP能够信托来自多个域的多个令牌发表机构。这类情形下，呈现了新的应战，由于RP必需断定应由哪一个IP-STS对哀求会见资本的用户举行身份考证。经由过程身份考证断定的用户所属的域是用户的主域，因而，这一历程称为主域辨认。
使用程序可使用良多机制举行主域辨认：
在本示例中，主域是事前已知的，因而，哀求一直重定向到特定IP-STS。
用户能够从其他出口扫瞄至RP，如许能够供应一个查询字符串，从该出口唆使用户的主域。
RP能够请求用户登录针对每一个主域的特定出口页。登录页面能够假定一个特定的主域。
RP能够依据哀求的IP地点或其他某种探索法断定主域。
假如RP没法经由过程上述办法断定主域，则能够显现一个UI，供用户选择主域或供应信息匡助RP断定主域。
假如RP撑持信息卡，则所选卡可以使用自动团结将身份考证驱动至响应的主域。
WS-Federation扼要划定了怎样完成主域辨认服务，但没有对此界说完整的标准。
不管怎样辨认主域，方针都是重定向用户，从而利用准确的IP-STS举行身份考证。有几种大概的计划。一个计划是，RP必要静态设置发表机构URI，以便将登录哀求发送到准确的IP-STS。这类情形下，RP必需在trustedIssuers节中列出一切受信托的IP-STS，如：
<trustedIssuers>
<add thumbprint="6b887123330ae8d26c3e2ea3bb7a489fd609a076"
name="IP1" />
<add thumbprint="d5bf17e2bf84cf2b35a86ea967ebab838d3d0747"
name="IP2" />
</trustedIssuers>
别的，您也能够重写由FAM公然的RedirectingToIdentityProvider事务，并利用相干探索法为STS断定准确的URI。为此，可将以下代码增加到Global.asax完成中：
void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
object sender, RedirectingToIdentityProviderEventArgs e) {
if (e.SignInRequestMessage.RequestUrl.Contains(
"IP1RealmEntry.aspx")) {
e.SignInRequestMessage.BaseUri =
new Uri("https://localhost/IP1/STS/Default.aspx");
}
else if (e.SignInRequestMessage.RequestUrl.Contains(
"IP2RealmEntry.aspx")) {
e.SignInRequestMessage.BaseUri = new Uri(
"https://localhost/IP2/STS/Default.aspx");
}
}
其他计划必要将主域参数(whr)随登录哀求一同传送给主STS。比方，RP大概有卖力声明转换的资本STS（R-STS或RP-STS）。RP-STS不合错误用户举行身份考证（它不是IdP），但它与一个或多个其他IdP有信托干系。
RP与RP-STS有信托干系，一直承认由RP-STS发表的令牌。RP-STS卖力将每一个哀求重定向到准确的IdP。RP-STS能够断定要重定向到的准确IP-STS（如后面的代码所示），不外RP还能够供应有关主域的信息，将主域参数中的这些信息传送到RP-STS。这类情形下，RP静态设置主域参数：
void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
object sender, RedirectingToIdentityProviderEventArgs e) {
if (e.SignInRequestMessage.RequestUrl.Contains(
"IP1RealmEntry.aspx")) {
e.SignInRequestMessage.HomeRealm =
"https://localhost/IP1/STS/Default.aspx";
}
else if (e.SignInRequestMessage.RequestUrl.Contains(
"IP2RealmEntry.aspx")) {
e.SignInRequestMessage.HomeRealm =
"https://localhost/IP2/STS/Default.aspx";
}
}
RP-STS利用此参数重定向到准确的IP-STS，然后将声明由IP-STS转换为与RP相干的声明。
单一登录和单一刊出
单一登录和单一刊出是团结身份考证的主要构成部分。经由过程单一登录功效，用户只需经由一次身份考证，就能够会见多个RP使用程序。望文生义，单一刊出是经由过程一次哀求就从一切RP使用程序和一切相干STS链中刊出。
在所示的复杂团结计划中，用户举行IP-STS身份考证，并依据发表的平安令牌取得RP受权。身份考证停止后，用户有一个STS会话Cookie和一个RP会话Cookie。如今，假如该用户扫瞄至其他RP，则会重定向到IP-STS举行身份考证（假定两个RP使用程序都信托统一个IP-STS）。由于该用户已有了一个IP-STS会话，以是该STS将为第二个RP发表一个令牌，而不提醒必要凭证。如今，用户取得了会见第二个RP的权限，而且有第二个RP的新会话Cookie。
后面已会商过，WIF供应SAM为经由身份考证的用户写出会话Cookie。默许情形下，此会话Cookie发表给域的绝对使用程序地点，其基础称号是FedAuth。由于团结会话Cookie大概较年夜，以是令牌一般拆分为两个（或更多）Cookie：FedAuth、FedAuth1等等。
假如统一个域中承载了多个使用程序，在团结计划中，默许举动是，扫瞄器针对每一个RP都有一个FedAuthCookie（请参阅0）。扫瞄器只为哀求发送与域和路径相干的Cookie。
0与每一个RP和STS联系关系的会话Cookie
一般情形下，都可使用此默许举动，不外，偶然必要针对每一个会话Cookie供应特定于每一个使用程序的独一称号，特别是这些使用程序承载于统一个域时。统一个域中的多个使用程序也大概共享一个会话Cookie，这类情形下，能够将Cookie路径设置为“/”。
假如会话Cookie到期，扫瞄器会从缓存中将它删除，用户将再次被重定向到STS举行身份考证。别的，假如预会话Cookie联系关系的已发表令牌已到期，WIF将重定向到STS请求新的令牌。
刊出更加明白，一般由用户自动实行。单一刊出是WS-Federation标准的可选功效，该功效倡议STS还应关照它发表过刊出哀求令牌的其他RP使用程序。如许，会从用户在单一登录会话时代扫瞄到的一切使用程序中删除会话Cookie。在更庞大的包括多个STS的计划中，吸收到刊出哀求的主STS还应关照其他STS实行不异的操纵。
为便于会商，我将侧重先容为完成团结单一刊出必要对RP实行的操纵。您能够将FederatedPassiveSignInStatus控件增加就任何必要撑持登录或刊出的页面，该控件将主动唆使其形态。登录以后，该控件会显现一个用于刊出的链接、按钮或图象。
单击该控件时，它将依据SignOutAction属性处置刊出，该属性能够是Refresh、Redirect、RedirectToLoginPage或FederatedPassiveSignOut。假如是前三个属性，则会删除使用程序的会话Cookie，但不会关照STS有存眷销哀求的信息。假如选择FederatedPassiveSignOut设置，该控件将挪用WSFederationAuthenticationModule的SignOut。这能够确保从使用程序中删除团结会话Cookie。别的，刊出哀求将发送到STS：
GET https://localhost/IP1/STS?wa=wsignout1.0
假如不利用FederatedPassiveSignInStatus控件，则能够间接挪用WSFederationAuthenticationModule.SignOut，以触发将刊出哀求重定向到STS的操纵。
单一刊出意味着用户从利用团结身份标识登录的一切使用程序刊出。假如STS撑持此功效，则应保留会话时代用户登录的RP使用程序列表，在哀求团结刊出时向每一个RP收回扫除哀求：
GET https://localhost/ClaimsAwareWebSite?wa=wsignoutcleanup1.0
在更庞大的计划中，一样的扫除哀求应发送到团结会话触及的一切其他STS。为此，STS必需事前晓得每一个RP和STS的扫除URI。要撑持单一刊出，RP应可以处置这些扫除哀求。FAM和FederatedPassiveSignInStatus控件都撑持此功效。假如利用FAM，可将扫除哀求发送到RP的任一URI，FAM将处置该哀求，扫除一切会话Cookie。假如利用FederatedPassiveSignInStatus控件，则必需将扫除哀求发送到包括该控件的页面。
现实上，除倡议的查询字符串和通讯流程，WS-Federation标准未具体划定怎样完成单一刊出和扫除举动。包管单一刊出对一切团结互助同伴无效，这其实不简单，但假如您具有如许的情况，并但愿到达此方针，它是的确可行的。
c＋＋是语言，其实C＋＋和java的应用范围根本就不一样的。在java应用的领域内，c＋＋是不合适的。所以微软才搞了C＃和Java对抗。 |
|
|Archiver|手机版|仓酷云
鄂ICP备14007578号-2
发表于 2015-1-16 22:20:35
收藏
转播
分享
淘帖
顶
踩
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜