2016-11-03 2 views
4

В ядре ASP.Net вы можете использовать реализацию IClaimsTransformer.Что такое использование IClaimsTransformer?

Вы регистрируете это следующим образом:

app.UseClaimsTransformation(o => o.Transformer = new MyClaimsTransformer()); 

Реализация

public class MyClaimsTransformer : IClaimsTransformer 
{ 
    public Task<ClaimsPrincipal> TransformAsync(ClaimsTransformationContext context) 
    { 
     var identity = context.Principal.Identity as ClaimsIdentity; 

     foreach (var claim in ci.Claims) 
     { 
      // you cannot modify claim.Type or claim.Value here 
     } 
    } 
} 

Однако ClaimsIdentity.Claims только для чтения свойство. Также Claim.Type, Claim.Value - только свойства readonly.

Это означает, что при реализации IClaimsTransformer вы можете добавлять только новые претензии. Вы не можете удалить или изменить существующие претензии.

Итак, каково реальное использование IClaimsTransformer?

ответ

2

Значение этого параметра заключается в том, что вы можете дополнить требования, превышающие то, что хранится в файле cookie аутентификации.

Это полезно, потому что только так много данных может попасть в файл cookie, если вы попытаетесь переложить слишком много, это будет усечено.

Так что если у вас много претензий или претензий с большой полезной нагрузкой, вы можете сохранить эти данные в сеансе и добавить их в формулу претензий с использованием преобразований претензий. Я не думаю, что он предназначен для удаления заявлений, которые были сохранены в файле cookie. Если вы хотите добавить или контролировать, какие претензии находятся в файле cookie, вы сделаете это в обычном стандарте IClaimsPrincipalFactory.

+0

Если я храню данные в сеансе, я могу просто прочитать его непосредственно из сеанса, поскольку сеанс доступен в HttpContext. Зачем мне претендовать и читать его из Претензий. Заявки – LP13

+0

могут использоваться для различных целей. одно общее использование удовлетворяет требованиям для политики авторизации. в большинстве случаев претензии не требуются, потому что в большинстве случаев вы можете избежать множества претензий или больших полезных нагрузок, но они есть, если вам это нужно. вам может и не понадобиться, но у этого есть использование, возможно, главным образом использование края. –

+0

@blowdart имеет лучший ответ, чем мой, наверняка –

4

Вы заметили возврат типа? Это ClaimsPrincipal.

Вы можете создать целый новый ClaimsPrincipal, добавив или изменив все, что вам нравится, из существующего и верните его.

+3

Будет ли это стандартным шаблоном? Например, я использую IdentityServer4 в качестве поставщика OIDC для аутентификации пользователя и предоставления id_token обратно в основное приложение ASPNET. Но моему приложению требуется, чтобы аутентифицированный пользователь имел претензии из бизнес-домена. Я использую трансформацию Claims Transformation для создания нового ClaimsPrincipal после запроса некоторого бизнес-сервиса для получения соответствующей информации. Предположительно, мне нужно будет кэшировать эту информацию, поскольку преобразование будет выполняться по каждому запросу. Существуют ли какие-либо руководства или рекомендации по этому вопросу? Спасибо заранее. – jcaddy

+1

@jcaddy ты спустился по этому маршруту? Вы нашли какое-нибудь руководство? – Larsi

+1

@ Larsi - все еще борется с этой концепцией. Трансформатор претензий в ядре aspnet не работает хорошо - похоже, дублирует претензии. Это довольно хороший способ разделить проблемы, так как приложение может просто полагаться на бизнес-требования и принимать решения об авторизации без чрезмерной работы.Другая проблема с IClaimsTransformer заключается в том, что вы не можете вводить зависимости, например. услугу или репозиторий для получения бизнес-требований. Если у вас есть какие-то идеи или передовая практика, мне было бы интересно услышать. https://github.com/aspnet/Security/issues/863 – jcaddy

Смежные вопросы