.net n-уровень идентификации и авторизации в архитектуре обслуживания

Я создаю приложение, в котором требования кажутся стандартной проблемой (по крайней мере для меня)... У меня есть Web.UI на основе asp.net mvc и клиентов из iphone, andriod и blackberry.

Итак, разумная вещь - переместить всю мою бизнес-логику в уровень услуг, доступ к которому можно получить через http. Этот уровень сервиса должен принимать запросы с пользовательским контекстом (идентификатором) и каким-то хорошим способом выполнять авторизацию независимо от того, с каким типом клиента он общается (надеюсь?).

Более года назад я сделал 3-месячный концерт, на котором был W.I.F. (Windows Identity Foundation) в гибридной локальной и облачной архитектуре. Мне нравится. 3 вещи, которые поразили аккорд, были (1) экстернализация аутентификации и не забота о том, как это было сделано, (2) удаление логики авторизации из бизнес-логики, (3) авторизация на основе требований.

За последний год я слышал и смотрел все о Rest Services "новый классный способ хиппи". Поэтому, хотя я и прав, пусть попробует это. После того, как я начал играть и получать кодировку, я начал очень растерянно (и впоследствии прочитал около 10 часов вчера, не написав еще одну строку С#). Я все еще запутался во всех SOAP vs REST, WS. * Vs Http, SAML и SWT. Я действительно не хочу, чтобы этот поток был об этом, потому что этого достаточно, чтобы говорить о stackoverflow, но я чувствую, что у меня есть выбор между двумя лагерями, когда мне не кажется, что я хочу того или другого но бит из каждого?

Мне три очка, о которых я упоминал выше о WIF, не похожи на понятия, которые должны быть привязаны к WS. *? Но у меня возникает ощущение, что они или, по крайней мере, то, как WIF на данный момент делает их, без какой-либо экспертной настройки (например, я столкнулся с этим сообщением, написанным всего несколько дней назад - http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/).

Другими областями, о которых я мало что знаю, являются мои клиенты (iphone, andriod, blackberry), способные играть с WIF, это тот же самый STS, который бросает им токен SAML, и они ведут себя точно так же, как браузер и передать его обратно в заголовке, как и любой другой клиент? Да, мне нужно будет выяснить это, но если это разбойник с W.I.F, и я сразу узнаю об этом, то, по крайней мере, я могу сосредоточиться от него.

Наконец, чтобы добавить еще одну вещь в микс. Я не хочу об этом думать. Я хочу использовать сторонний поставщик аутентификации/идентификации - http://www.janrain.com/products/engage - который, я считаю, использует OpenID. Может ли это вписаться в W.I.F. или я просто создаю новый токен SAML из OpenID и с этого момента использую WIF.

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

Имеет ли сервисный уровень (в WCF), который говорит с разными клиентами не-NET, которые требуют, чтобы контекст идентификации и авторизация были настолько странными? Если вы создали что-то вроде этого, как вы к нему подошли?

Ответ 1

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

Предполагая, что все ваши клиенты поддерживают файлы cookie. Один из способов сделать это:

У вас есть система аутентификации, основанная на файле cookie.
Кэш всей информации авторизации на стороне сервера, связанной с сеансом или ключом в файле cookie
Для каждого запроса проверьте авторизацию

Не так элегантно, как использовать токены SAML, но он работает с кросс-платформой/устройствами.

IPhone поддерживает файлы cookie http://support.apple.com/kb/HT1675

Blackberry поддерживает файлы cookie http://docs.blackberry.com/en/developers/deliverables/11844/feature_cookie_storage_438273_11.jsp

Ответ 2

Я собираюсь взломать ответ на ваш вопрос несколько более абстрактно...

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

Две ссылки, которые я нашел очень полезными:

1) Руководство по идентификации и контролю доступа на основе утверждений

http://msdn.microsoft.com/en-us/library/ff423674.aspx

2) Программирование Windows Identity Foundation

Автор: Витторио Берточчи Доступно в печатной форме форматов

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

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

Как я сломаю федеративную личность вниз, грубо выглядит следующим образом:

Приложения (приложения) [App (s)]
Служба аутентификации [STS (s)]
Набор требований (заявок) [Заявка (ы)]
Доверительные отношения (доверительные отношения)]
Транспортный метод [Транспорт (ы)]

STS отвечает за проверку личности пользователя и поручение для некоторых претензий. Он делает это путем предоставления (1) подписанного блоба, содержащего формулы изобретения, или (2) уникального идентификатора, который сторонняя сторона может использовать для поиска претензий.

Приложение, которое хочет предоставить пользователю услугу, может "доверять" STS, чтобы предоставить ей претензии, которые она может использовать для работы с пользователем, соответственно, что облегчает ее ответственность за проверку пользователя (среди прочего, такое как сохранение централизованных метаданных, но я отвлекаюсь).

Существует также способность STS "доверять" другой STS, в основном говоря: "Если вы говорите, что этот человек - Джо Смит, у них есть роли X, Y и Z, тогда я буду ручаться за то, что вы говорите!"

Итак, перефразируем:

App (s) "доверять" STS {который может в свою очередь "доверять" другому STS}, чтобы предоставить ему/им заявку (ы)

** Коммутационные шестерни **

SOAP vs REST

В конце дня SOAP и REST являются типами сервисов, которые позволяют назвать их претензиями. Они оба хотят, чтобы кто-то дал им ведро, полное претензий, чтобы они могли выполнить свою работу и отправить некоторые вещи. Кроме того, оба типа услуг могут быть представлены претензиями по строке запроса с использованием токена (при условии, что служба может обрабатывать некоторую перерисовку URL) или через заголовок (HTTP для REST и SOAP для, ну, SOAP-сервисов). В любом случае цель та же: передать заявки или UID в приложение.

WS * vs HTTP

Эти (наряду с TCP/IP, SSL, секретными кольцами декодера и т.д.) являются методами передачи информации взад и вперед, хотя с разной степенью уверенности, что кто-то посередине не может найти способ олицетворять пользователя.

SAML vs SWT

Эти (наряду с кодировкой base 64, xml, простой текст и т.д.) - оба метода сериализации претензий. Эти два просто соответствуют стандартам, которые другие не так, чтобы каждый мог говорить на одном языке.

** Возвращаясь к точке **

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

Итак, если у меня есть приложение .Net, которому был подан набор претензий в SAML fomat по конвейеру WS *, конечным результатом является то, что приложение имеет [заявки в SAML].

При некоторой обработке они могут быть преобразованы в [заявки в SWT].

Новые претензии могут быть затем упакованы и отправлены через HTTP/SSL в приложение Java.

ЕСЛИ приложение Java "доверяет" той же STS (или STS, которая "доверяет".Net-приложениям STS), тогда она открывает претензии и выполняет свою работу.

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

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

Услуга Engage, о которой вы говорили, позволяет связать пользователей приложений с внешними источниками и может использоваться для аутентификации этих пользователей... ala "Я вижу, что вы прошли аутентификацию с помощью google как [email protected], я знаю, что вы как Джон Уокер с идентификатором 4321, о, смотрите, вы изменили свой любимый цвет в google на синий... продолжайте!"

То, что он не делает, это предоставить претензии к вашему приложению, которые являются специфическими для вашего приложения (если только все, что вам нужно знать, поступает из данных Google, и в этом случае вы, вероятно, создаете месиво, а не приложение LOB...

Другой сценарий:

Пользователь переходит в ваше приложение
перенаправляется на ваш STS
перенаправляется в Google
Возвращается на ваш STS
Добавления электронной почты и любимых цветов добавляются (за google)
Добавлен список ролей и заявлений о лимитах на покупку (из вашего конкретного хранилища данных)
Пользователь возвращается в приложение
Пользователь пытается купить фиолетовые виджеты за 10 000 долларов, и вы говорите: "Ну, вы можете купить только 5 000 долларов в кредит и... вы уверены, что хотите фиолетовый, я слышал, что вы предпочитаете синий?"

Другим местом, на которое я бы направил вас, является служба AppFabric Access Control, предлагаемая Microsoft. (Http://msdn.microsoft.com/en-us/library/ee732536.aspx) отказ от ответственности: я еще не использовал его, но похоже, что он выполняет те виды переводов, которые вы ищете, с большим количеством мяса, спрятанным для вас.

Ответ 3

Как WIF говорит WS-Trust/WS-Federation под капотом, вы можете подвергнуть аутентификации на основе утверждений на уровне служб.

В этой статье показано, как создать WCF STS, который будет разговаривать с внешними клиентами, используя эти протоколы. http://msdn.microsoft.com/en-us/library/ee748498.aspx

С точки зрения авторизации на уровне услуг вы можете использовать специальный диспетчер авторизации, чтобы проверить, что претензии были представлены. http://msdn.microsoft.com/en-us/library/ms731774.aspx

Чтобы подключить внешние службы идентификации, такие как OpenID, и добавить свои собственные заявки в те, которые генерируются WIF, вы можете подклассом из ClaimsAuthenticationManager следующим образом:

public class MyClaimsAuthenticationManager : ClaimsAuthenticationManager {

    public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal)
    {
        if (!incomingPrincipal.Identity.IsAuthenticated)
        {
            return incomingPrincipal;
        }

        //TODO: obtain user profile claims from external source, i.e. database, web service            
        // below code demonstrates how to custom claims to the current principal 
        // (which are then persisted for the lifecycle of the user browser session)            

        IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity;

        identity.Claims.Add(new Claim(ClaimTypes.Email, "[email protected]"));

        return incomingPrincipal;
    }
}

код >

Вам нужно указать WIF, чтобы использовать свой собственный менеджер заявок в файле Web.config, установив параметр конфигурации ClaimAuthenticationManager.

Надеюсь, что это поможет.

Ответ 4

Я подошел к аналогичной проблеме, используя spring + java; все концепции, которые он требует, находятся в .net, поэтому я упоминаю его здесь. Я нашел решение, которое spring-security переносит работу хорошо (для моих простых требований к авторизации). На моем уровне услуг методы, требующие определенных разрешений, объявляют это посредством аннотаций (либо на интерфейсе, либо на реализации):

@Secured(MyPermissions.READ, MyPermissions.WRITE)
void modifyPerson(PersonChanges changes);

@Secured(MyPermissions.READ)
Person readPerson();

В этом примере инфраструктура безопасности (spring) обертывает реализации службы динамическим прокси-сервером, который проверяет, что мой уровень авторизации поместил соответствующие роли/разрешения, связанные с потоком, в контексте, где оценивается метод службы, если нет генерируется исключение безопасности.

Я также счел полезным группировать службы, требующие разрешения по шаблонам URL-адресов, так что требование "требует аутентифицированного принципала" обрабатывается на самом высоком уровне: например, myapp/services/secure/personService - любой шаблон URL, требующий */secure, будет перенаправлен на страницу аутентификации, если информация аутентификации не существует.

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

Кроме того, он отлично работает для агрегированных сервисов - если одна служба вызывает другую, правила авторизации более низкого уровня по-прежнему применяются, если они не объявлены должным образом в составной службе.