IdentityServer i odświeżanie wartości claims

Kiedyś czytałem o DBA pracującym w jednym z banków. Przychodził on codziennie rano do pracy, przeważnie wcześnie, przed innymi. Robił sobie kubek gorącej kawy. Włączał monitor i komputer, kładł kurtkę na ramionach krzesła. Gorącą kawę stawiał przy klawiaturze. Kiedy inni przychodzili widzieli biurku osoby „pracującej”. To co zaś robił nasz główny bohater, to wychodził z pracy, szedł dosłownie na drugą stronę ulicy do innego banku. Logował się tam do swojego komputera i odstawiał podobną sztukę w drugim banku. Dwa pełne etaty, w dwóch bankach, jako DBA… żyć nie umierać ;)

Czy historia jest prawdziwa ciężko mi powiedzieć, skończyła się co prawda źle dla DBA, po kilku miesiącach go złapano i oskarżono oraz nałożono kary finansowe.

Aktualizacja Claims w ADFS

Na szczęście nie zawsze musi być tak źle, kilka lat temu pisałem o tym jak wymusić odświeżenie claims w aplikacji z wykorzystaniem ADFS. Ogólnie chodzi o to, że w naszym systemie jedna osoba może poddawać się za kilka firm. Będąc firmą X może działać z imienia i upoważnienia tej firmy. Będąc w firmie Y robi to samo bez wglądu do danych firmy Y.

Można to tak rozwiązać jak to zrobił Teams ;) zakładać konta w danej organizacji, jednak to nie jest idealne rozwiązanie. W szczególności, że osoba która może zmieniać firmy przeważnie może prowadzić firmę dającą pewną konkretną usługę którą musi świadczyć w imieniu firmy X lub Y. Zaś sama firma może mieć wielu pracowników robiących to.

Szukamy więc rozwiązania które umożliwi jednemu kontowi działać jako inne i ten kontekst można zmieniać. Zmiana zaś powinna być… niezauważalna i nie odczuwalna prawie dla użytkownika końcowego.

Aktualizacja Claims w IdentityServer

Jako że mieliśmy już działające rozwiązanie i ludzie od niego przywykli ciężko jest to teraz od tak zmienić. Przy migracji do IdentityServer v4, musieliśmy więc zachować funkcjonalność opisaną w zalinkowanym artykule.

To znaczy, że użytkownik nie powinien się musieć ponownie logować przy wykonaniu zmiany acting as. Dosłownie zmiana acting as to zmiana w bazie danych pola, które jest pobierane i następnie wrzucane jako claim.

By to zrobić, w IdentityServer trzeba przejść przez proces odświeżania tokenu. Dokładniej trzeba ustawić zmienną dla aplikacji UpdateAccessTokenClaimsOnRefresh a następnie po odświeżeniu tokenu pobrać na nowo claims dla danego profilu i zaktualizować nasze ciasteczko. W przeciwnym wypadku zmiana nie zostanie uwzględniona. Dodatkowo potrzebujemy jeszcze GrantType który umożliwi nam na odświeżenie tokenu z poziomu kodu, myśmy poszli z HybridAndClientCredentials.

Kod który umożliwia pobranie nowych claims wygląda następująco:

[Route("update-claims")]
public async Task<IActionResult> UpdateClaims(string uid)
{
    if (!User.Identity.IsAuthenticated)
    {
        return NoContent();
    }
    var currentUid = User.FindFirst(EdenClaimTypes.UserId)?.Value ?? "";
    if (!string.Equals(currentUid, uid, StringComparison.Ordinal))
    {
        return NoContent();
    }

    var disco = await _discoveryCache.GetAsync();
    if (disco.IsError) 
    {
        throw new Exception(disco.Error);
    }

    var opt = _options.Value;

    var rt = await HttpContext.GetTokenAsync("refresh_token");
    var tokenClient = _httpClientFactory.CreateClient("discovery");
    using var refreshToken = new RefreshTokenRequest
    {
        Address = disco.TokenEndpoint,
        ClientId = opt.ClientId,
        ClientSecret = opt.ClientSecret,
        RefreshToken = rt
    };

    var tokenResult = await tokenClient.RequestRefreshTokenAsync(refreshToken);

    if (tokenResult.IsError)
    {
        return NoContent();
    }

    var new_access_token = tokenResult.AccessToken;
    var new_refresh_token = tokenResult.RefreshToken;
    var expiresAt = ApplicationTime.Current + TimeSpan.FromSeconds(tokenResult.ExpiresIn);

    var info = await HttpContext.AuthenticateAsync("Cookies");

    info.Properties.UpdateTokenValue("refresh_token", new_refresh_token);
    info.Properties.UpdateTokenValue("access_token", new_access_token);
    info.Properties.UpdateTokenValue("expires_at", expiresAt.ToString("o", CultureInfo.InvariantCulture));
    using var uir = new UserInfoRequest
    {
        Address = disco.UserInfoEndpoint,
        ClientId = opt.ClientId,
        ClientSecret = opt.ClientSecret,
        Token = new_access_token
    };

    var claims = await tokenClient.GetUserInfoAsync(uir);

    var currentIdentity = info.Principal.Identity as ClaimsIdentity;
    var distinctClaimTypes = claims.Claims.Select(x => x.Type).Distinct();
    foreach (var claimType in distinctClaimTypes)
    {
        var currentCount = currentIdentity.Claims.Count(x => x.Type == claimType);
        if (currentCount > 0)
        {
            var currentClaims = currentIdentity.Claims.Where(x => x.Type == claimType).ToList();
            foreach (var currentClaim in currentClaims)
            {
                currentIdentity.RemoveClaim(currentClaim);
            }
        }

        currentIdentity.AddClaims(claims.Claims.Where(x => x.Type == claimType));
    }

    await HttpContext.SignInAsync("Cookies", info.Principal, info.Properties);

    return NoContent();
}

Po słowie

Może kod się Tobie przyda. Jest to jednak hack i osobiście wolałbym go nie robić, zamiast tego wymusić ponowne logowanie się na użytkowniku, które można bardzo fajnie za pomocą front-channel zaimplementować.

PS.: Koniecznie przeczytajcie komentarze, w szcególności Tomka – przy innych wymaganiach i innym systemie, to była by dobra droga.