Idenity Server 4 Injection zusätzlicher Ansprüche in IAuthorizeInteractionResponseGenerator

Question

Ich versuche, Code von IdentityServer3 zu portieren, die PreAuthenticate verwendet, um einen temporären Identitätswechsel eines Benutzers in einer Clientanwendung für unsere Administratoren bereitzustellen.

Nach dem Thread in here überschreibe ich ProcessInteractionAsync in einem benutzerdefinierten IAuthorizeInteractionResponseGenerator. Das funktioniert gut und ich habe alles funktioniert, ABER, ich kann nicht einen zusätzlichen Anspruch hinzufügen, um zurück an die Client-Anwendung gesendet werden, so dass es weiß, dass dies ein imitiertes ID_Token ist. Beim Ersetzen des Betreffs für ValidatedAuthorizeRequest in meiner Überschreibung, füge ich einen zusätzlichen Anspruch hinzu, der den Benutzer angibt, der den Identitätswechsel gestartet hat, aber dieser Anspruch wird nicht im id_token oder dem Zugriffstoken ausgeführt. Hier ist meine Überschreibung:

public override async Task<InteractionResponse> ProcessInteractionAsync(ValidatedAuthorizeRequest request, ConsentResponse consent = null) 
{ 
    string impersonatedUserName = request.GetPrefixedAcrValue("Impersonate:"); 
    if (!string.IsNullOrWhiteSpace(impersonatedUserName)) 
    { 
     if (request.Client.AllowedScopes.Contains(Constants.ClaimTypes.Impersonation)) 
     { 
      var currentUser; 
      var impersonatedUser; 

      //Omited code to verify eligibility to impersonate user 

      if (impersonatedUser != null) 
      { 
       IEnumerable<string> requestedClaimTypes = request.Client.AllowedScopes; 

       IdentityServerUser idSrvUser = new IdentityServerUser(impersonatedUser.Id.ToString()) 
       { 
        AuthenticationTime = Clock.UtcNow.UtcDateTime, 
        DisplayName = impersonatedUser.UserName, 
        IdentityProvider = !string.IsNullOrEmpty(impersonatedUser.PasswordHash) ? IdentityServerConstants.LocalIdentityProvider : "external" 
       }; 

       ProfileDataRequestContext context = new ProfileDataRequestContext(
        idSrvUser.CreatePrincipal(), 
        request.Client, 
        nameof(AuthorizeInteractionResponseGenerator), 
        requestedClaimTypes); 

       await Profile.GetProfileDataAsync(context); 

       //Need this claim to flow through to client 
       context.IssuedClaims.Add(new Claim(Constants.ClaimTypes.Impersonation, currentUser.UserName)); 

       foreach (Claim claim in context.IssuedClaims) 
       { 
        idSrvUser.AdditionalClaims.Add(claim); 
       } 

       ClaimsPrincipal newSubject = idSrvUser.CreatePrincipal(); 

       request.Subject = newSubject; 

       Logger.LogInformation("Impersonation set, returning response"); 

       return new InteractionResponse(); 
      } 
      else 
      { 
       Logger.LogWarning("Invalid attempt to impersonate user"); 
       return new InteractionResponse { Error = "Invalid attempt to impersonate user" }; 
      } 
     } 
     else 
     { 
      Logger.LogWarning("Client does not support impersonation!"); 
      return new InteractionResponse { Error = "Client does not support impersonation" }; 
     } 
    } 

    return await base.ProcessInteractionAsync(request, consent); 
} 

Ich fügte einen Bereich für diesen speziellen Anspruch hinzu, den der Client anfordert, aber es wird immer noch nicht aufgenommen. Ich habe das Gefühl, dass etwas offensichtlich ist, dass ich hier vermisse. Wie füge ich einen zusätzlichen Anspruch auf einen der Token hinzu? Oder gibt es eine bessere Möglichkeit, dem Kunden zu signalisieren, wer den Identitätswechsel gestartet hat?

Answer 1

Also nahm ich einen etwas anderen Weg als ich in Identity Server 3, um diese Anforderung zu lösen. Anstatt den Benutzernamen in Identity Server anzuhängen, speichere ich den Benutzernamen des Benutzers, der den Identitätswechsel auf dem Client gestartet hat, in einem temporären Cookie. Dann überprüfe ich in der AuthorizationCodeReceived-Benachrichtigung nach dem Cookie-Wert und füge den Anspruch an den Principal an, der dort erstellt wird.

Nicht ganz so narrensicher wie das Anfügen des Anspruchs in Identity, aber da alle wichtigen Sicherheitschecks immer noch passieren und die Dinge, die ich wissen wollte, wer es als impersonierter Benutzer tat, scheitern ohne den Cookie, das wird funktionieren. Wenn jemand darüber stolpert und herausfinden kann, wie man den Claim im Identity Server anhängt, antworten Sie und ich gebe Ihnen die Antwort