Механизм аутентификации для игрового клиента java/mysql db

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

Безопасность имеет первостепенное значение, мне нужно убедиться, что данные, передаваемые по сети, зашифрованы, поэтому я буду использовать SSL (первоначально я думал о шифровании на уровне сообщений с использованием ws-security, но я думаю, что это слишком много накладных расходов).

Что мне действительно нужно выяснить, так это какой механизм аутентификации я должен предоставить. Эти пользователи будут предоставлять имена пользователей и пароли, а также отправлять веб-запрос к службе.

Я еще не решил, должна ли служба быть традиционной веб-службой SOAP или RESTful. Вся идея отдыха состоит в том, чтобы сделать сервер без состояния, и, поскольку клиент в основном будет устанавливать сеанс со службой, я не вижу смысла использовать здесь REST.

Сказав все это, мне действительно нужно понять, как именно выполнить рукопожатие и как сохранить сеанс.

Существуют ли какие-либо популярные фреймворки, которые предоставляют API для работы с базой данных mySQL?

Снова клиент предложит серверу UN / PW, который должен их расшифровать (об этом должен позаботиться SSL), аутентифицировать их по информации учетной записи, хранящейся в базе данных mysql, а затем вернуть какой-то хэш или что-то подобное так что сеанс пользователя может сохраняться или пользователю больше не нужно входить в систему, чтобы выдавать дополнительные запросы.

Может ли кто-нибудь порекомендовать фреймворк/некоторые материалы для чтения, чтобы я мог их просмотреть?


authentication c++ java handshake
person Zachary Carter    schedule 18.01.2012    source источник
comment
Клиент НЕ должен обращаться к базе данных напрямую, особенно для конкретного поставщика. Во-первых, если у них есть возможность выполнять произвольные операторы SELECT, они могут остановить всю вашу систему. Но в основном это помешает вам проводить техническое обслуживание в будущем. В идеале вы предоставляете программную услугу, которая случайно использует базу данных, о которой они ничего не знают. Помимо этого... обратите внимание на Spring, одну из самых популярных сред JavaEE, которая удовлетворит практически все ваши потребности. Написано правильно, не важно на чем написан клиент.   -  person Clockwork-Muse    schedule 18.01.2012
comment
@ X-Zero - Ты же читал OP, верно? Включая ту часть, где написано and will be issuing a web request to a service?   -  person cdeszaq    schedule 18.01.2012
comment
@cdeszaq - я сделал, но мне было немного неясно, для чего OP предназначал фреймворк - использовать его как реальную веб-службу или просто предоставить клиенту какую-то инфраструктуру аутентификации для прямого запуска операторов SQL.   -  person Clockwork-Muse    schedule 18.01.2012
comment
Нет, сервис будет действовать как средний уровень между ними.   -  person Zachary Carter    schedule 18.01.2012

Ответы (3)


arrow_upward
1
arrow_downward

Держите вещи как можно проще.

HTTP уже не имеет состояния, и идея входа в систему с последующим продолжением сеанса хорошо зарекомендовала себя (сеансовый файл cookie). Используйте эту парадигму, и у вас не будет никаких проблем.

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

REST также означает, что вы можете легко использовать один и тот же сервер с другими клиентами.

person cdeszaq    schedule 18.01.2012

arrow_upward
1
arrow_downward

Я бы посмотрел на oauth:

http://developers.sun.com/identity/reference/techart/restwebservices.html

Хорошо зарекомендовавший себя шаблон: 1. войти в систему и получить токен oauth 2. сохранить токен в базе данных с внутренним идентификатором пользователя (и любыми другими данными, такими как время истечения срока действия токена, которое вы хотите сохранить). 3. отправить токен клиенту, клиент сохраняет токен 4. клиент отправляет токен для всех будущих запросов 5. сервер извлекает информацию о пользователе из токена

Этот метод должен хорошо работать с любым языком клиента и любым внутренним хранилищем данных.

person Mason Bryant    schedule 18.01.2012
comment
oauth великолепен, но если вам нужно сделать больше, чем просто аутентификация, часто это может быть больше работы, чем его ценность, если вам нужно сделать больше, чем просто аутентификация, и вам не нужно разрешать другие службы, которые одно приложение аутентифицирует против него . Кроме того, легко использовать другую систему аутентификации, если она понадобится вам позже. - person cdeszaq; 18.01.2012
comment
Это стандарт, имеет хорошую библиотечную поддержку, хорошо сочетается с остальными. Я не уверен, в чем проблема. Вы можете легко наложить сеанс поверх него. Я думаю, я не уверен, где трудность. - person Mason Bryant; 18.01.2012

arrow_upward
0
arrow_downward

Я бы рекомендовал использовать REST. В качестве фреймворка авторизации вы можете использовать jdbc стандартного контейнера или файловые области на JAAS. Если пара логин/пароль успешна, сохраните их на стороне клиента. После этого вы можете выполнять запросы с учетными данными для аутентификации, предоставленными для каждого запроса. Я использовал джерси клиента для этого. Для [де]сериализации из/в библиотеку XML/json XStream "сделайте всю эту математику". Хорошего дня.

person Jura M    schedule 18.01.2012