Единая точка входа для веб-приложения
Я пытался понять, как эта проблема решена больше месяца теперь. Я действительно должен придумать общий подход та работа. У меня есть теория, но я просто не уверен, что это является самым легким (или корректным), подход, и я не смог найти, что любая информация поддерживает мои идеи.
Вот сценарий:
1) У Вас есть сложное веб-приложение, которое предлагает безопасное содержание на основе подписки.
2) Пользователи обязаны входить в систему Вашего приложения с именем пользователя и паролем.
3) Вы продаете крупным корпорациям, которые уже имеют корпоративную технологию аутентификации (например, Active Directory).
4) Требуется интегрироваться с корпоративным механизмом аутентификации, чтобы позволить их пользователям входить в систему веб-приложение, не имея необходимость вводить их имя пользователя и пароль.
Теперь, любое решение, которое Вы предлагаете, должно будет обеспечить механизм для:
- добавление новых пользователей
- удаление пользователей
- изменение информации о пользователе
- разрешение пользователям войти в систему
Идеально, все, они произошли бы "автоволшебно", когда корпоративный клиент внес соответствующие изменения в их собственную аутентификацию.
Теперь, у меня есть теория, что способ сделать это (по крайней мере, для Active Directory) было бы, чтобы я записал клиентское приложение, которое интегрируется с Active Directory клиента, чтобы отследить целенаправленные изменения и затем передать те изменения в моем веб-приложении. Я думаю что, если бы эта коммуникация была сделана через веб-сервисы, предлагаемые моим веб-приложением, то это поддержало бы unhackable уровень безопасности, которая, очевидно, будет требованием для этих корпоративных клиентов.
Я нашел некоторую информацию о продукте Microsoft названной Сервисом федерации Active Directory (ADFS), который может или не может быть правильным подходом для меня. Это, кажется, является немного большим и имеет некоторые требования, которые не могли бы работать на всех клиентов.
Для других существующих идентификационных сценариев (как Афины и Шибболет), я не думаю, что клиентское приложение необходимо. Это - вероятно, просто вопрос набрасывания на существующие идентификационные сервисы.
Я ценил бы любой совет, который любой имеет на чем-либо, что я упомянул здесь. В частности, если можно сказать мне, если моя теория корректна об обеспечении клиентского приложения, которое общается с веб-сервисами серверной стороны, или если я полностью вхожу в неправильное направление. Кроме того, если Вы могли бы указать на меня на какие-либо веб-сайты или статьи, которые объясняют, как сделать это, я был бы очень признателен за его. Мое исследование не поднялось очень до сих пор.
Наконец, если Вы могли бы сообщить мне каких-либо веб-приложений, которые в настоящее время предлагают эту услугу (особенно, как связано с корпоративным Active Directory), я был бы очень благодарен. Я задаюсь вопросом, предлагает ли другое веб-приложение B2B как salesforce.com или hoovers.com подобную услугу для их корпоративных клиентов.
Я очень не хочу быть в темноте и был бы очень признателен за любой свет, который можно пролить...
Jeremy
2 ответа
Shibboleth разработан для поддержки именно этого сценария. Однако он будет полагаться на компании ваших клиентов, реализующие механизмы поставщика удостоверений. На данный момент это действительно распространено только в университетах. Кроме того, если вам нужна информация о пользователе (не только псевдонимный идентификатор), вам необходимо, чтобы компания согласилась предоставить вам эти атрибуты.
Мне трудно поверить, что многие компании открыли бы вам свою корпоративную систему аутентификации только для того, чтобы обеспечить единый вход.
Возможно, вам будет лучше полагаться на OpenID или аналогичный, а также использовать cookie «запомнить меня», чтобы уменьшить потребность людей вводить пароли.
Одна из основных проблем вашего подхода заключается в том, что вы рассматриваете свое веб-приложение изолированно. Сотрудникам компании вашего клиента потребуется не только единый вход для вашего веб-приложения, но и некоторые / несколько / многие другие, и для расширения вашего подхода потребуется индивидуальная реализация для каждого из них, чтобы обеспечить доступ.
Отсюда повсеместное распространение OpenAthens и Shibboleth в академическом библиотечном сообществе для использования выданных на местном уровне учетных данных.Типичный средний / крупный университет может подписаться на различные продукты / услуги от более чем пятидесяти различных издателей, и, развернув OpenAthens / Shibboleth, они могут воспользоваться преимуществами открытого стандарта SAML (SAML - это протокол, который использует Shibboleth), который получает все большее распространение. не только в академическом, но и в коммерческом секторе.
Приведенный выше ответ Джона указывает на другую проблему: недавно появился ряд открытых стандартов, в том числе SAML и OpenID. Таким образом, провайдеры контента должны решить, хотят ли они реализовать некоторые или все из них изначально, но они используют отдельные технологические стеки, и поэтому затраты на внедрение и поддержку могут быть дублированы.
Несколько крупных издателей внедрили OpenAthens , поскольку он поддерживает Афины, SAML / Shibboleth и OpenID на единой платформе, с возможностью подключения других технологий или написания специального модуля, позволяющего внутреннюю приложение для подключения, например система выставления счетов или прав, регистрирующая, какие пользователи клиентов входят в систему.
Этот сектор управления доступом определенно движется в сторону открытых стандартов, поэтому создание вашего собственного метода лишит доступа к вашему приложению большое количество пользователей