2015-10-19 4 views
0

Как ISV, я хочу предоставить нескольким клиентам моей (и Google) возможность собирать данные из API каталогов. Поскольку наше приложение безголовое, кажется, что для того, чтобы клиенты авторизовались в нашем приложении, нам нужна поддержка домена, но мне кажется, что он создает дыру в безопасности. Если наше приложение (опять же, безголовое) имеет право на учетную запись клиента А, а также на клиента Б, что помешает клиенту видеть (собирать) данные клиента В и наоборот?Безопасность и поддержка доменов

Поскольку единственная аутентификация в этом случае является нашим приложением к API, какой рекомендуемый подход предотвратить эту ситуацию? Идентификатор клиента для каждого клиента? Разве это не означает, что у каждого клиента также должна быть учетная запись Google Developer? Или мы сталкиваемся с необходимостью вручную создавать отдельную учетную запись службы для каждого клиента?

(Мое приложение работает отлично, кстати, как раз кажется небезопасным для меня)

+0

Чтобы было ясно, только администратор получит доступ ко всем данным клиентов. Если Клиент А авторизует ваше приложение, его не тот клиент B может получить доступ к информации клиента A. Например, если A поделился файлом доступа к диску с вашим приложением, доступ к нему будет доступен только администратору приложения. Если A не делится информацией с B или администратором, он получает доступ к нему. Вы также можете контролировать информацию, которую запрашивает ваше приложение, установив соответствующие области. – SGC

+0

@SGC Спасибо за ответ. Я остаюсь неубежденным, поэтому мне придется проверить мою теорию, когда я смогу найти партнера для тестирования своего приложения и посмотреть, могу ли я собирать их данные без какого-либо доступа к их учетной записи. Учитывая, как работает API, и как работает работа с доменом, я не вижу ничего, что помешало бы умному клиенту, который знает о другом клиенте, собирать свои данные - единственную «аутентификацию», выполняемую в API, кроме приложения client ID/key - это так называемый «пользовательский адрес электронной почты», то есть адрес электронной почты администратора в целевом домене. – MushyMiddle

ответ

1

Чтобы ответить на мой собственный вопрос, после тестирования этого на счет GfW другого клиента, это так же небезопасно, как я думал, что это было. У меня не было проблем с сбором данных с использованием одних и тех же учетных записей службы из двух разных учетных записей, единственным «секретным», являющимся адресом электронной почты администратора для каждой учетной записи.

Это недостающая часть в документации Google: Делегация домена не должна использоваться с использованием тех же учетных данных учетной записи службы на нескольких учетных записях, или эти учетные записи смогут получать доступ к данным друг друга. Таким образом, если вы планируете доставлять приложение клиентам, которым необходим доступ без доступа к API, используйте либо что-то вроде потока веб-сервера OAuth, либо создайте отдельный набор учетных данных учетной записи службы для каждого клиента.

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

+0

Я беспокоился о том же, это кажется настолько произвольным для Google. Либо вы можете использовать пользователя для аутентификации токенов (каждый час), либо вы должны авторизовать сервер/приложение для полного использования любых разрешений, которые он дает, - во всем домене! Единственной спасительной изюминкой, по-видимому, является то, что для документов и электронных таблиц вы не можете получить к ним доступ, не зная их заранее. – jQwierdy

Смежные вопросы