Как реализовать несколько IdentityServers

Question

Мы создаем приложение с несколькими арендаторами, которое будет размещаться в нескольких центрах обработки данных (Azure) по всему миру. Это приложение также выведет API (а не только веб-приложение MVC).

Чтобы справиться с аутентификацией/авторизацией, мы планировали реализовать Owin OAuth, но затем мы столкнулись с «Thinktecture IdentityServer3», который соответствует нашему счету.

Кроме того, если арендатор имеет учетную запись в любом региональном экземпляре (например, «NA1.ourwebsite.com»), он должен не только войти в систему через «NA1.ourwebsite.com», но также должен иметь возможность войдите через централизованный сервер экземпляров/идентификаторов 'ourwebsite.com'.

NA1.ourwebsite.com - Северная Америка Экземпляр

EA1.ourwebsite.com - Восточная Азия Instance

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

Я не уверен, как одно приложение может иметь несколько серверов идентификации (я не знаю, нужно ли мне выбирать федеративные серверы).

SalesForce.com делает то же самое, но я не знаю, как это сделать. Может ли кто-нибудь помочь мне в этом?

Заранее спасибо.

Answer 1

Для обработки аутентификации/авторизации мы планировали внедрить Owin OAuth, но затем мы столкнулись с «Thinktecture IdentityServer3», который соответствует нашему счету.

Это действительно так.Thinktecture IdentityServer3 - это реализация OpenID Connect, а OpenID Connect - OAuth с добавлением «уровня идентификации». Вы все еще можете использовать OAuth для авторизации (доступ к защищенным ресурсам), поскольку поставщик OpenID обычно возвращает access_token. Он также возвращает id_token для аутентификации (проверка личности).

Кроме того, если арендатор имеет счет в любом региональном инстанции (например, «NA1.ourwebsite.com»), не только он должен быть в состоянии войти в систему через «NA1.ourwebsite.com», но он также должен быть возможность входа в систему через централизованный сервер экземпляров/идентификаторов 'ourwebsite.com'.

Это вариант использования, который поддерживает OpenID Connect. Вы сможете предоставить конечному пользователю возможность войти в систему с NA1.ourwebsite.com с нашим сайтом ourwebsite.com или с любым другим провайдером OpenID Connect. Например, я могу войти в одну учетную запись StackExchange, используя несколько поставщиков.

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

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

Существует множество подходов, которые вы можете предпринять, двигаясь вперед. Вы хотите различать информацию пользователя, относящуюся только к вашему приложению, от пользовательской информации, относящейся к аутентификации. Вы не можете разумно ожидать, что все поставщики OpenID Connect будут хранить всю информацию о пользователе, которую требуется вашему приложению. Что касается информации о пользователе, он сможет подтвердить вашу личность пользователя и предоставить информацию о профиле, которую пользователь уже хранит у поставщика (например, материал, который находится в их учетной записи Twitter.)

Я не уверен, как одно приложение может иметь несколько серверов идентификации (я не знаю, нужно ли мне выбирать федеративные серверы).

Это похоже на то, как один аэропорт может принимать несколько видов идентификации: свидетельство о рождении, счет за электричество, паспорт, водительские права. Трудно понять, но как только вы почувствуете, что id_token похож на кусок доверенной идентификации, вы можете начать его оценивать. Как реальный пример мира - свидетельство о рождении. В этом случае правительство является поставщиком удостоверений, а свидетельство о рождении - id_token. Приложение может выбрать, какие поставщики удостоверений, которые он принимает.

SalesForce.com делает то же самое, но я не знаю, как это сделать. Может ли кто-нибудь помочь мне в этом?

В дополнение к salesforce.com, как указано выше, stackexchange.com также делает это. Диаграмма из спецификации OpenID Connect поможет немного.

+--------+         +--------+ 
|  |         |  | 
|  |---------(1) AuthN Request-------->|  | 
|  |         |  | 
|  | +--------+      |  | 
|  | |  |      |  | 
|  | | End- |<--(2) AuthN & AuthZ-->|  | 
|  | | User |      |  | 
| RP | |  |      | OP | 
|  | +--------+      |  | 
|  |         |  | 
|  |<--------(3) AuthN Response--------|  | 
|  |         |  | 
|  |---------(4) UserInfo Request----->|  | 
|  |         |  | 
|  |<--------(5) UserInfo Response-----|  | 
|  |         |  | 
+--------+         +--------+ 

1. РП (клиент) посылает запрос на провайдера OpenID (OP).
2. OP аутентифицирует конечного пользователя и получает авторизацию.
3. OP отвечает идентификатором ID и обычно является токеном доступа.
4. RP может отправить запрос с помощью токена доступа в конечную точку UserInfo.
5. Конечная точка UserInfo возвращает претензии о конечных пользователях.

OP является провайдером соединений OpenID. Я думаю, это то, что вы подразумеваете под «серверами идентификации». Вы можете принимать токены от любых поставщиков, которым ваше приложение решает довериться. Конечный пользователь может выбрать, какой провайдер будет использовать при входе в систему (вы часто увидите это как возможность входа в Twitter, Facebook, Google, Microsoft ...). Одним из таких вариантов может быть наш веб-сайт.

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

Шаги (1) - (3) выше почти точно такие же, как поток авторизации OAuth, в котором конечный пользователь подписывается провайдером выбора, а поставщик отвечает токеном. Разница с OpenID Connect заключается в том, что на этапе (3) ответ обычно содержит id_token в дополнение к access_token.

access_token представляет конечные пользователи авторизация. Это токен марки OAuth. Ваше приложение включает в себя запросы на защищенные ресурсы. Эти защищенные ресурсы могут включать информацию о пользователе, хранящуюся в поставщике OpenID Connect. См. Шаги (4) и (5).

id_token представляет конечную пользователей аутентификацию и содержит претензии как к конечному пользователю, так и к поставщику Open ID Connect. Заявка iss идентифицирует поставщика OpenID, заявка sub однозначно идентифицирует конечного пользователя, заявка aud идентифицирует доверяющую сторону (ваше приложение). Другие стандартные претензии включают в себя: name, given_name, family_name, middle_name, , website, email, phone_number аутентифицированного конечного пользователя.

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

OpenID Connect сложный и занимает некоторое время, чтобы в полной мере оценить. Ваше упорство будет окупаться, потому что оно идеально соответствует вашему прецеденту. Thinktecture IdentityServer3 выглядит как твердый вариант. Еще одна аналогичная оценка - AspNet.Security.OpenIdConnect.Server.

Ссылки

OpenID Connect in a nutshell. Написанный одним из авторов OpenID Connect, этот пост содержит два особенно полезных раздела: «Выполнение запроса OpenID Connect» и «Получение ответа OpenID Connect».

OpenID Connect Core 1.0 incorporating errata set 1 Один из документов спецификации, содержащий полезную диаграмму, опубликованную в этом ответе.

The OAuth 2.0 Authorization Framework: Bearer Token Usage OAuth RFC, который объясняет, как использовать access_token в запросе на защищенный ресурс.