Thread.CurrentPrincipal ist authentifiziert, aber "ClaimsPrincipal".Strom ist nicht

Ich bin mit anspruchsbasierte Autorisierung in meinen WebApi-Projekt und habe eine Methode, wo ich prüfe, ob die aktuelle Identität authentifiziert. Wenn ich ClaimsPrincipal.Current die aktuelle Identität ist nicht authentifiziert, aber wenn ich Thread.CurrentPrincipal es ist.

ClaimsPrincipal.Current.Identity.IsAuthenticated; //False
Thread.CurrentPrincipal.Identity.IsAuthenticated; //True

Dies scheint seltsam, vor allem, da die MSDN sagt "ClaimsPrincipal".Aktuelle nur die Renditen Thread.CurrentPrincipal:

Bemerkungen

Standardmäßig Thread.CurrentPrincipal zurückgegeben. Sie können dies ändern
Verhalten durch die Einstellung der ClaimsPrincipalSelector-Eigenschaft zum angeben eines
Delegaten aufgerufen werden, um zu bestimmen, den aktuellen Prinzipal.

Kann jemand bitte erklären Sie mir, warum ClaimsPrincipal ist nicht authentifiziert, während die beiden, in der Theorie, enthalten die gleiche Identität?

"Standardmäßig" impliziert für mich, dass einige andere Verhalten ist möglich - haben Sie entschieden, dass unsere?
Nein, die ClaimsPrincipalSelector null ist, so wird der Standardwert verwendet.

InformationsquelleAutor Jos Vinke | 2013-03-11

  1. 10

    Kurz gesagt, die Dokumentation ist falsch zu sagen, dass es gibt Thread.CurrentPrincipal standardmäßig.

    Was es tatsächlich gibt ist eine ClaimsPrincipal Verpackung Thread.CurrentPrincipal (wenn es nicht eigentlich schon ein ClaimsPrincipal), mit diesem Konstruktor:

    public ClaimsPrincipal(IPrincipal principal)
{
    this.m_version = "1.0";
    this.m_identities = new List<ClaimsIdentity>();
    if (principal == null)
    {
        throw new ArgumentNullException("principal");
    }
    ClaimsPrincipal principal2 = principal as ClaimsPrincipal;
    if (principal2 == null)
    {
        this.m_identities.Add(new ClaimsIdentity(principal.Identity));
    }
    else if (principal2.Identities != null)
    {
        this.m_identities.AddRange(principal2.Identities);
    }
}

    Diese wiederum, wie Sie hoffentlich sehen, ist wieder eine ClaimsIdentity dass wraps des Auftraggebers Identität (wieder, wenn es nicht eigentlich schon ein ClaimsIdentity).

    In der Konstruktion der ClaimsIdentity, der einzige Ort, ich kann sehen, wo es am Ende nicht die Einstellung die Art der Authentifizierung (und damit eine Identität zu erschaffen, die nicht authentifiziert) ist hier:

    if(identity is WindowsIdentity)
{
   try
   {
      this.m_authenticationType = identity.AuthenticationType;
   }
   catch(UnauthorizedAccessException)
   {
      this.m_authenticationType = null;
   }
}

    So, wenn die Identität, die Sie Zugriff über Thread.CurrentPrincipal.Identity ist eigentlich ein WindowsIdentity Instanz, und in dem Kontext, in dem Sie ausführen, Sie haben eingeschränkte Berechtigungen, die konstruiert ClaimsIdentity Instanz müssen IsAuthenticated als falsch.

    Thread.CurrentPrincipal enthält eine "ClaimsPrincipal" in meinem code. Aus dem code, den Sie geschrieben sehe ich, dass eine Liste zu bauen, aber es nicht mir erklären, warum IsAuthenticated auf false gesetzt ist. Ist es zum Beispiel, weil "ClaimsPrincipal" erfolgt eine zusätzliche Validierung, die fehlschlägt? Ich mochte wissen, warum es falsch ist, so kann ich entweder fix was ausfällt, oder legen Sie den "claimsprincipal", um authentifiziert zu wissen, warum es falsch ist, in den ersten Platz.
    Wenn es ein ClaimsPrincipal schon, dann alle der oben genannten ist strittig, da sollte es nur wieder die gleiche Instanz. Ist ReferenceEquals(ClaimsPrincipal.Current,Thread.CurrentPrincipal) wahr?
    Es gibt false zurück, in der Tat, der Unterschied ist, dass "ClaimsPrincipal".Strom ist ein System.Sicherheit.Ansprüche."ClaimsPrincipal" und "Thread".CurrentPrincipal ist Microsoft.IdentityModel.Ansprüche."ClaimsPrincipal". Aber ich Frage mich immer noch, warum es auf false festgelegt ist.
    in diesem Fall, Sie mischen WIF-code und neuer (gebacken, in den Kern -) Framework identity code. Es ist also sehr wahrscheinlich zu sein, etwas von der Verpackung, die ich oben beschrieben.
    Ich lief in ein descrepency zwischen Thread.CurrentPrincipal und "ClaimsPrincipal".Aktuelle als auch. In meinem Fall das Problem war unsere Verwendung von Windows-Authentifizierung, sondern mit einem Prozess, der hinzugefügte lokale Forderungen aus der Datenbank. Die daraus resultierende "ClaimsPrincipal".Strom war eine RolePrincipal, sondern weil RolePrincipal überschreibt die Identity-er war auf der Suche für Ansprüche aus seiner eigenen Identität statt aus der Basis von "claimsprincipal" - Identität. Die Lösung war, die ClaimsPrincipalSelector, um immer wieder ein neues "ClaimsPrincipal" - basierend auf den bestehenden Thread.CurrentPrincipal.Identität.

    InformationsquelleAutor Damien_The_Unbeliever

Schreibe einen Kommentar