无法解密索赔COOKIE从.NET 4.5到.NET 3.5NET、COOKIE

2023-09-07 10:24:14 作者:陌若惜ヽ

我一直在试图让下面的情况下,为一个星期左右,现在有没有运气的工作。我有2个应用程序,一个.NET 4.5应用程序,要求启用,这是工作得很好(可与其他.NET 4及以上的应用);并使用的WebForms .NET 3.5的传统内联网系统构建的。传统应用程序无法升级到.NET的更高版本(会容易得多)。

我希望发生的是,当我登录在.NET 4.5的应用程序,我需要当我访问了.NET 3.5应用程序进行身份验证。我已经确保了应用程序之间的cookie名称是相同的,并且在web.config中的machineKey值相同(我使用MachineKeySessionSecurityTokenHandler以确保encyrpted cookie的值是相同的,即使在一个Web场方案);然而,什么情况是,当我移动到.NET 3.5应用程序我从SymmetricEncryptionFormatter级以下错误:

  

ID0006:输入字符串参数为null或empty.Parameter名称:值

我试图改变将machineKey键(decryptionkey /的validationKey /验证/ decryptiom),以各种不同的组合(确保它们是2站点之间一致)。我可以看到相同的Cookie,具有相同的cookie值是可见的,当我去到了2点。我认为,这个问题可能与之间的.NET 3.5安培的Crytographic变化; .NET 4.5(见这里[http://blogs.msdn.com/b/webdev/archive/2012/10/23/cryptographic-improvements-in-asp-net-4-5-pt-2.aspx])

没有人有任何想法什么可能会导致此?

键条目从.NET 4.5应用程序的Web.config:

 < system.identityModel>
< identityConfiguration>
< securityTokenHandlers>
<删除TYPE =System.IdentityModel.Tokens.SessionSecurityTokenHandler,System.IdentityModel,版本= 4.0.0.0,文化=中性公钥= b77a5c561934e089/>
<加上TYPE =System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,System.IdentityModel.Services,版本= 4.0.0.0,文化=中性公钥= b77a5c561934e089/>
< / securityTokenHandlers>
< / identityConfiguration>
< /system.identityModel>

<身份验证模式=无/>
 

 < system.identityModel.services>
< federationConfiguration>
<的CookieHandler requireSsl =假NAME =测试名/>
< wsFederation passiveRedirectEnabled =真发行人=HTTP://本地主机:51318 /的境界=HTTP://本地主机:57083 /persistentCookiesOnPassiveRedirects =真正的requireHttps =FALSE/>
< / federationConfiguration>
< /system.identityModel.services>
 

键条目从.NET 3.5应用程序的Web.config:

 <身份验证模式=无/>

< machineKey中decryptionKey =CC510DF4 ......的validationKey =BEAC835EEC ....../>

< microsoft.identityModel>
<服务>
  < securityTokenHandlers>
    <! - 替换SessionSecurityTokenHandler与我们自己的。 - >
    <删除TYPE =Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler,Microsoft.IdentityModel,版本= 3.5.0.0,文化=中性公钥= 31bf3856ad364e35/>
    <加上TYPE =MachineKeySessionSecurityTokenHandler,APP_ code/>
  < / securityTokenHandlers>
< /服务>
< /microsoft.identityModel>

< microsoft.identityModel.services>
< federationConfiguration>
< wsFederation passiveRedirectEnabled =真发行人=HTTP://本地主机:51318 /的境界=HTTP://本地主机:57083 /requireHttps =FALSE/>
<的CookieHandler requireSsl =假NAME =测试名/>
< / federationConfiguration>
< /microsoft.identityModel.services>
 
Internet选项这么设置了,还是无法记录cookie,每次登陆百度,新浪微博,人人网等都要重新填写帐号密码

解决方案

该cookie的内部格式已经WIF和.NET 4.5之间变化。该版本之间不能共享它们。

颇有点这两个应用程序,以同样的STS,并让每个应用程序使用自己的会话cookie。

I have been trying to get the following scenario to work for around a week now with no luck. I have 2 applications, a .NET 4.5 application that is claims enabled, which is working perfectly well (works with other .NET 4 and up applications); and a legacy Intranet system built using WebForms .NET 3.5. The legacy application CANNOT be upgraded to a later version of .NET (would be so much easier).

What I want to happen is that when I login on the .NET 4.5 application, I need to be authenticated when I visit the .NET 3.5 application. I have ensured that the Cookie Names between the applications are the same, and that the machineKey values in the web.config are the same (I am using MachineKeySessionSecurityTokenHandler to ensure that the encyrpted cookie values are the same even in a Web Farm scenario); however what happens is that when I move to the .NET 3.5 application I get the following error from the SymmetricEncryptionFormatter class:

ID0006: The input string parameter is either null or empty.Parameter name: value

I have tried changing the MachineKey keys (decryptionkey/validationkey/validation/decryptiom) to a variety of different combinations (ensuring that they are consistent between the 2 sites). I can see that the same cookie, with the same cookie value is visible when I go to the 2 sites. I think that the issue may be related to the Crytographic changes between .NET 3.5 & .NET 4.5 (see here [http://blogs.msdn.com/b/webdev/archive/2012/10/23/cryptographic-improvements-in-asp-net-4-5-pt-2.aspx])

Does anyone have any ideas as to what may be causing this?

Key entries from .NET 4.5 application Web.config:

<system.identityModel>
<identityConfiguration>
<securityTokenHandlers>
<remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />  
</securityTokenHandlers>
</identityConfiguration>
</system.identityModel>

<authentication mode="None" />

<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="false" name="TestName" />
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:51318/" realm="http://localhost:57083/" persistentCookiesOnPassiveRedirects="true" requireHttps="false" />
</federationConfiguration>
</system.identityModel.services>

Key entries from .NET 3.5 application Web.config:

<authentication mode="None"/>

<machineKey decryptionKey="CC510DF4..." validationKey="BEAC835EEC..." />

<microsoft.identityModel>
<service>
  <securityTokenHandlers>
    <!-- Replace the SessionSecurityTokenHandler with our own. -->
    <remove type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add type="MachineKeySessionSecurityTokenHandler, App_Code"/>
  </securityTokenHandlers>
</service>
</microsoft.identityModel>

<microsoft.identityModel.services>
<federationConfiguration>
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:51318/" realm="http://localhost:57083/" requireHttps="false"/>
<cookieHandler requireSsl="false" name="TestName"/>
</federationConfiguration>
</microsoft.identityModel.services>

解决方案

The internal format of the cookie has changed between WIF and .NET 4.5. You can't share them between the versions.

Rather point both apps to the same STS and let each app use their own session cookie.