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

Question

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

* 1002Поэтому разумно сделать так, чтобы вся моя бизнес-логика была перенесена на уровень сервисов, доступ к которому возможен через http.Этот уровень сервисов должен принимать запросы с пользовательским контекстом (идентификатором) и каким-то приятным способом последовательно выполнять авторизацию независимо от того, какой тип клиента связывается с ним (надеюсь?).

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

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

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

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

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

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

Наличие уровня сервисов (в WCF), который взаимодействует с различными клиентами, не входящими в .net, и требуетконтекст идентичности и авторизация так странно?Если вы построили что-то вроде этого, как вы подошли к этому?

Answer 1

Если у вас много устройств, один из способов заставить одно и то же решение работать на всех из них, это нацелить наименьший общий знаменатель.

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

• Иметь систему аутентификации на основе куки.
• Кэшировать всю информацию авторизации на стороне сервера, связанную с сеансом или ключом в файле 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

Answer 2

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

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

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

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

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

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

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

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

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

То, как я разрушаю федеративную идентификацию, примерно так:

1. Приложение (я) [Приложение (я)]
2. Служба (-ы) аутентификации [STS] *
3. Набор претензий [Заявка (и)]
4. Доверительные отношения (и) [Доверие (и)]
5. Способ (ы) транспорта [Транспорт (ы)]

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

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

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

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

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

** Переключение передач **

МЫЛО против ОТДЫХА

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

WS * против HTTP

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

SAML против SWT

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

** Возвращаясь к сути **

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

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

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

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

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

• Специалист по настройке, о котором вы упоминаете, должен произойти, вопрос заключается в том, кем и насколько он прозрачен.

  1. Дейв представляет совершенно достоверный пример одного способа выполнения настройки с помощью пользовательских настроек.code.
  2. ADFS предоставляет правила перевода, которые пытаются выполнить слияние и преобразование с помощью конфигурации.

• Идея предоставления услуг на различных платформах / устройствах / приложениях /и т. д. совсем не странно, это именно тот сценарий, по которому строится весь этот материал по адресу

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

Упомянутая вами служба Engage позволяет связывать пользователей вашего приложения с внешними источниками и может использоваться для аутентификации этих пользователей ... аля "Я вижу тебяаутентифицировался в Google как John@gmail.com, я знаю вас как Джона Уокера с идентификатором 4321, о, смотрите, вы изменилинаша любимая настройка цвета в google - синий ... продолжайте! "

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

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

1. Пользователь переходит к вашему приложению
2. Isперенаправлен на ваш STS
3. перенаправлен на Google
4. возвращен на ваш STS
5. Добавлены претензии по электронной почте и любимые цвета (для каждого google)
6. Списокдобавляются заявки на роли и ограничения на покупку (из хранилища данных вашего приложения)
7. Пользователь возвращается в приложение
8. Пользователь пытается купить фиолетовые виджеты за 10 000 долларов, и вы говорите: «Ну, вы можете купить только 5000 долларов»в кредит и ... вы уверены, что хотите фиолетовый, я слышал, что вы предпочитаете синий? "

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

В этой статье показано, как создать STS WCF, которая будет взаимодействовать с внешними клиентами с использованием этих протоколов. 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 {</p> <pre><code> 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's browser session) IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity; identity.Claims.Add(new Claim(ClaimTypes.Email, "dave@dave.com")); return incomingPrincipal; } }

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

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