Как защитить веб-службу .NET для использования приложением iPhone?

Question

У меня есть веб-служба, написанная на .NET, которая предоставляет данные для приложения iPhone. Это также позволит приложению сделать «бронирование».

В настоящее время все это внутри корпоративной сети, но, очевидно, когда приложение iPhone будет опубликовано, мне нужно будет обеспечить внешнюю доступность веб-службы.

Как мне обеспечить безопасность веб-службы?

Есть два аспекта, которые я изучаю:

• Аутентификация для доступа к веб-сервису
• Защита передаваемых данных

Меня не беспокоит передача данных туда-сюда, так как они все равно будут доступны для просмотра в приложении (которое будет бесплатным). Ключевой вопрос для меня - это запрет на доступ пользователей к веб-службе и резервирование самостоятельно.

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

Answer 1

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

Answer 2

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

Если вы не можете сделать это, вы можете использовать AES для подписи сообщений с iphone на сервер, используя общий секрет, известный только серверу и iphone, но никогда не передается простым текстом:

подпись = AES (данные + iphone udid + общий секрет) (или что-то на этот счет)

Вы должны выбрать способ распространения секрета. что позволяет проверить другую часть.

Answer 3

Я бы предпочел оба варианта шифрования (Base64 / AES) + HTTPS. oData, oAuth-аутентификация также может быть использована.