Мы создаем приложение, которое (надеюсь) позволит пользователям проходить аутентификацию несколькими способами. Либо облачные сервисы (google, facebook и т. Д.) или, надеюсь, Active Directory их собственной компании.
Является ли их достаточно простым способом сделать это, не переусердствуя с тем, что клиент захочет сделать, чтобы это стало возможным?
На высоком уровне вы можете потратить некоторое время на размышления о том, как спроектировать уровень идентификации в вашем приложении. Как абстрагироваться от всех различных провайдеров аутентификации. Один из способов сделать это - использовать подход идентификации на основе утверждений. Вместо того, чтобы встраивать всю логику аутентификации / авторизации в приложение, у вас есть этот уровень, на котором вы конвертируете атрибуты пользователя, поступающие от поставщика аутентификации, в общее для них представление. Это называется "удостоверением на основе утверждений".
Вы можете скачать бесплатную книгу об этом подходе от Microsoft. Руководство по идентификации и контролю доступа на основе утверждений (2-е издание).
На более конкретном уровне реализация будет зависеть от того, какую платформу / язык вы используете и какие библиотеки доступны. Если вы хотите интегрироваться с поставщиками социальной идентификации, обычно используется протокол OAuth2 (Google, Facebook, LiveID) или OAuth1.0a (Twitter). В NET у вас есть такие библиотеки, как DotNetOpenAuth который будет реализовывать эти протоколы. Если вы хотите интегрироваться с чем-то вроде ADFS (Служба федерации Active Directory), используется протокол WS-Federation с токенами SAML или протокол SAML 2.0. В NET выбрана библиотека Windows Identity Foundation (WIF). Смешать и то, и другое в одном приложении непросто. Вот что я имел в виду, вкладывая средства в общий уровень абстракции.
Наконец, есть облачные сервисы, которые могут помочь. Это посредники между вашим приложением и поставщиками удостоверений. С точки зрения приложения вы реализуете одну библиотеку:
Служба контроля доступа Windows Azure (ACS): В качестве справки, вот руководство по интеграции ASP.NET с ACS. http://www.windowsazure.com/en-us/develop/net/how-to-guides/access-control
Auth0: В качестве справки вот руководство по интеграции ASP.NET с Auth0 https://docs.auth0.com/aspnet-tutorial (ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я работаю в Auth0)
Microsoft справляется с этим с помощью своего инструмента «DirSync», который основан на Forefront Identity Manager и ADFS для единого входа между их локальными каталогами и облачными каталогами. Так они получают единый вход для Office 365, Intune и Lync Online.
Скорее всего, вам нужно будет реализовать что-то подобное или убедить клиента открыть свой брандмауэр для ваших конкретных служб и выполнить LDAPS или что-то прямо против их AD.
У нас есть пара сторонних облачных систем, которым требуется доступ к нашей Active Directory для обеспечения единого входа.
Для обоих мы просто настроили правило публикации брандмауэра, заблокированное IP-адресом, чтобы только определенные серверы могли подключаться через Интернет к нашему контроллеру домена. Он также доступен только для зашифрованного трафика.
В зависимости от того, какой у вас брандмауэр, конфигурация будет отличаться, поэтому, если вы обновите свой вопрос с деталями, вы можете получить более конкретные ответы