ASP.Net и WIF только одна претензия доступна, но другие претензии отображаются на трассе

Question

Эта проблема вызывает недоумение. Я просто не могу получить заявку на идентификатор имени в моем коде C# после того, как пользователь выполнил аутентификацию. Это веб-сайт .Net 4.5. Единственное требование, которое я могу получить, это http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Легко перебирать формулы, и есть только один доступный. Глядя на трассировку, ясно, что существует идентификатор имени, однако он просто недоступен в моем коде при итерации через ClaimsPrincipal.Current.Claims или ClaimsPrincipal.Current.Identities []. Claims.

Вот пример трассировки:

<TraceRecord xmlns="http://schemas.microsoft.com/2009/10/IdentityModel/TraceRecord" Severity="Information"> 
 
<Description>Setting Thread.CurrentPrincipal from session token.</Description> 
 
<AppDomain>/LM/W3SVC/2/ROOT/qat-5-131009300157520403</AppDomain> 
 
<ClaimsPrincipalTraceRecord xmlns="http://schemas.microsoft.com/2009/06/IdentityModel/ClaimsPrincipalTraceRecord"> 
 
<ClaimsPrincipal Identity.Name="Adfs"> 
 
<ClaimsIdentity Name="Adfs" Label="" RoleClaimType="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" NameClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"> 
 
<Claim Type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" ValueType="http://www.w3.org/2001/XMLSchema#string" Value="something"/> 
 
<Claim Type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" ValueType="http://www.w3.org/2001/XMLSchema#string" Value="Adfs"/> 
 
<Claim Type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" ValueType="http://www.w3.org/2001/XMLSchema#string" Value="Adfs.email@somewhere"/> 
 
<Claim Type="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod" ValueType="http://www.w3.org/2001/XMLSchema#string" Value="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"/> 
 
<Claim Type="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant" ValueType="http://www.w3.org/2001/XMLSchema#dateTime" Value="2016-02-26T01:53:04.289Z"/> 
 
</ClaimsIdentity> 
 
</ClaimsPrincipal> 
 
</ClaimsPrincipalTraceRecord> 
 
</TraceRecord>

Мой код может вернуть Идентичность и одну претензию на имя. Но роль, которая содержит адрес электронной почты и идентификатор имени, просто отсутствует. Существует только одно требование.

Я прошел через все. Мое приложение - это просто одностраничное тестовое приложение. Ничего интересного, ничто не могло отбросить некоторые претензии или что-то еще.

Может ли кто-нибудь предложить, где я должен выглядеть или что-нибудь, что я могу сделать, чтобы получить идентификатор имен (или любые другие претензии).

Я не могу понять, почему они отображаются в трассировке, но недоступны в моем приложении. Я думал, что они просто попадут в одну из коллекций Claims, доступных в разделе ClaimsPrincipal.Current или в одном из элементов ClaimsPrincipal.Current.Identities (есть только одно удостоверение, соответствующее результату трассировки).

Любая помощь действительно ценится У меня осталось немного волос! Заранее спасибо.

Answer 1

Я отвечу на свой вопрос. После этого у меня не осталось много волос. Проблема, возможно, собирается поймать других.

При использовании нижеследующего для доступа к ClaimsPrincipal я использовал пространство имен System.IdentityModel. Это давало мне только одно требование. Несмотря на то, что с включенной трассировкой WIF я мог видеть, что многие заявки поданы в мое приложение.

using System.IdentityModel; 
... 
ClaimsPrincipal claimsPrincipal = ClaimsPrincipal.Current; 

Решение было просто использовать вместо следующего:

using Microsoft.IdentityModel.Claims; 
... 
IClaimsPrincipal claimsPrincipal = (IClaimsPrincipal)Thread.CurrentPrincipal; 

Затем вдруг все остальные претензии были доступны. Обнаружив это, я немного исследовал и нашел несколько статей о переполнении стека о различиях между этими двумя. Один парень mentioned here, что пространство имен Microsoft предназначено для расширений к стандартным пространствам имен, которые имеют дело с функциями Microsoft и объяснят это. Также this answer имеет для меня больше всего смысла.