Мне нужно предоставить авторизацию и аутентификацию для моих API REST, реализованных с использованием стандарта JAX-RS, которые предназначены для потребления от мобильных клиентов и некоторых устройств. У меня есть несколько устройств с уникальной идентификацией устройства, которые могут POST некоторые данные. Мобильные клиенты просто используют запросы GET для отображения этих данных. Меня больше беспокоит часть POST, где я хочу аутентифицировать клиентов. Кроме того, я хотел бы, чтобы это было просто. Я имею в виду использование простой базовой HTTP-авторизации через HTTPS с ключом API. Мой вопрос: как я могу сгенерировать этот ключ API?
Стратегия генерации ключа API REST
Ответ 1
Нашел несколько хороших статей, которые очистили мои сомнения относительно генерации ключей API и их использования для аутентификации:
http://restcookbook.com/Basics/loggingin/ http://www.smartjava.org/content/protect-rest-service-using-hmac-play-20
Ответ 2
Вы можете взглянуть на Сиро: http://shiro.apache.org Это очень хорошая инфраструктура для "защищенных" API (авторизация, аутентификация и другие вещи для обеспечения безопасности). Вы можете реализовать "базовую аутентификацию" для "входа" своих пользователей (через имя пользователя/пароль), а затем предоставить им ключ API, который вы можете использовать для выполнения "аутентификации маркера на предъявителя", чтобы позволить им получить доступ к ресурсам ваш API. Для этого вы бы определили, что siro называет "фильтры", которые определены через ресурсы API... это определено в "shiro.ini" следующим образом:
[main]
authcBasicRealm = com.yourapp.shiro.UserAuthenticatorRealm
tokenValidatorFilter = com.yourapp.shiro.BearerAuthenticationTokenFilter
tokenValidatorRealm = com.yourapp.shiro.BearerAuthenticationTokenRealm
[urls]
/rest/hello/login/** = ssl[8443], noSessionCreation, authcBasic
/rest/hello/hello = ssl[8443], noSessionCreation, tokenValidatorFilter
Вам необходимо реализовать/расширить некоторые фильтры по умолчанию Shiro, чтобы заставить их работать с вашей БД, чтобы получить данные аутентификации пользователя и т.д. Приятно, что они предоставляют множество инструментов для решения проблем безопасности, например: для создания API ключи, соль и шифрование и т.д. Взгляните на их учебники, они в целом очень хорошие.
Существуют и другие структуры, а именно Java EE имеет поддержку безопасности, а также Spring обеспечивает поддержку безопасности. Взгляните на эту очень приятную презентацию Мата Райди, где он представляет и демонстрирует эти три рамки: http://www.slideshare.net/mraible/java-web-application-security-denver-jug-2013
Ответ 3
Для этого вы можете использовать UUID. UUID выглядит следующим образом:
550e8400-e29b-41d4-a716-446655440000
Существуют библиотеки для генерации UUID, доступных на каждом языке программирования.
Ответ 4
Я также рассматриваю это на моем конце, если я хочу полагаться на стандарты JAX-RS и поддерживать приложение "чистым", я бы использовал систему аутентификации по умолчанию, которая поставляется с контейнером (обычно это BASIC auth).
Это означает, что контейнеру необходимо будет выполнить авторизацию на уровне авторизации и уровня курса, например приложения Java EE, которые следуют стандартным и не строят обходные пути (т.е. с использованием Shiro).
Однако, если вы хотите использовать концепцию маркеров API и таких, не сохраняя при этом ваше приложение без внедрения системы аутентификации, вам необходимо реализовать эту работу в другом месте, то есть в контейнере.
К сожалению, аутентификация на основе контейнера должна быть специфичной для контейнера. JAAS не описывает стандартный API-интерфейс контейнера для выполнения областей аутентификации. Даже их учебник http://docs.oracle.com/javaee/6/tutorial/doc/bnbxj.html рассказывает о конкретной конфигурации Glassfish.
Если ваша организация достаточно велика, DataPower также поддерживает OAuth http://www.ibm.com/developerworks/websphere/library/techarticles/1208_rasmussen/1208_rasmussen.html, поэтому вы, вероятно, можете использовать ее для управления аутентификацией и прохождения надлежащего учетные данные для вашего приложения. Однако. вам все равно нужно сделать что-то конкретное для конкретного поставщика.
Это не плохо, но я предпочел бы сделать этот подход, а не загрязнять приложение своей собственной системой аутентификации, тем самым делая вещи негибкими, если система аутентификации изменится. например SonarQube имеет собственную систему аутентификации, которая не поддерживает сертификаты на стороне клиента.