Аутентификация и авторизация для простого веб-сайта

Question

Я борюсь с этими понятиями и затрудняюсь найти хорошие ресурсы в Интернете.

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

Наш сценарий выглядит следующим образом:

• Простой веб-сайт (может быть приложение в близком будущем)
• пользователь должен войти в систему или иным образом получить доступ (т.е. нет «гость» содержание или другие вещи, которые вы можете сделать в качестве гостя)
• Сайт использует свои собственные веб-службы (REST и/или SOAP) на бэкэнд, но он может использовать сторонние веб-службы или предоставляет свои собственные услуги в качестве сторонних услуг для других приложения
• Аутентификация может быть выполнена с помощью внешнего провизора der: пользователи имеют смарт-карту, и мы хотели бы иметь одного простого поставщика удостоверений, который считывает информацию смарт-карты и отправляет ее обратно на мой простой веб-сайт (поэтому я знаю, кто такой пользователь и какова его роль)
• Другие сайты могут использовать другие методы аутентификации (например, простое имя пользователя/пароль), поэтому нам может понадобиться настраиваемый поставщик услуг?

В настоящее время я смотрел на OAuth (2) осуществлять разрешающих использование наших REST Services (это также полезно для SOAP?) На нашем веб-сайте, может быть, с помощью простого «учетных данных клиента Grant» типа.

Но для аутентификации я все еще не мудрее. Существует OpenID, но достаточно ли легко создать собственный поставщик идентификаторов OpenID? Существует Shibboleth, но он, похоже, имеет крутую кривую обучения для создания пользовательских материалов. И я смотрел только что-то построенное с нуля на основе протокола запроса аутентификации SAML с привязкой HTTP-сообщения. Есть ли другие варианты?

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

Answer 1

Если это еще полезно, я лично подумал о том, чтобы сделать это сам, а затем обнаружил кучу третьих лиц. Я сравнил (5/18/2015):

• Auth0
• AuthRocket
• UserApp
• DailyCred

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

Вот полная история сравнения: https://medium.com/@bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c