2015-10-06 4 views
1

Я настроил проверку подлинности для моего приложения, используя/OAuth 2 потока Azure Rest API, следуя инструкциям, изложенным здесь:Провайдеры Ограничение Azure Идентичность

https://ahmetalpbalkan.com/blog/azure-rest-api-with-oauth2/

Я создал ActiveDirectory приложение в Azure, которая связанный с экземпляром ActiveDirectory.

Внутри моего приложения я настроил его, чтобы отправить к следующему Azure OAuth конечной точки:

https://login.windows.net/<<MY-AD-TENANT-ID>>/oauth2/authorize?client_id=<<GUID>>&response_type=code 

Это все работает отлично. Я могу проверить подлинность против моей ActiveDirectory с помощью электронной почты вида

[email protected]<myDomain>.com 

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

[email protected] 

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

[email protected]<myDomain>.com 

Я просмотрел документацию, но до сих пор не повезло.

ответ

0

Благодаря подсказке Томаса Эберта я выяснил, как решить мою проблему. Я не знаю, поможет ли это кому-то еще, но ...

В основном, когда мое приложение получает токен от Azure, прежде чем передать его клиенту, я могу декодировать JWT и просто посмотреть поле email ,

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

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

1

Механика маркеров Validation

Что это на самом деле означает: для проверки маркера? Она сводится к трем вещам, на самом деле:

  1. Убедитесь, что он хорошо сформирован
  2. Убедитесь, что она исходит от предполагаемого органа
  3. Убедитесь, что она предназначена для текущего приложения

Ваша проблема в том, что вы не выполняете проверку номера 3.

Вы, наверное, что-то вроде этого не хватает в вашем приложении, в котором выполняется проверка маркера:

app.UseWindowsAzureActiveDirectoryBearerAuthentication(
    new WindowsAzureActiveDirectoryBearerAuthenticationOptions 
    { 
     Audience = ConfigurationManager.AppSettings["ida:Audience"], 
     Tenant = ConfigurationManager.AppSettings["ida:Tenant"], 
    }); 
+0

Привет благодарю за ответ. У меня есть несколько вопросов: 1) Я использую Scala для написания всего этого, и я не использовал ранее существовавшую библиотеку для OAuth, я только что внедрил все это, так что вы могли бы рассказать мне, фрагмент кода? (Является ли это C#?) 2) Я, пожалуй, наивно полагал, что мне не нужно будет проверять токен, который я получаю от Azure, но могу ли я предположить из вашего ответа, что нет способа удалить адрес электронной почты microsoft/hotmail из действительных поставщиков удостоверений по конфигурации в Azure, и что я должен сделать проверку себя в своем коде? – bobbyr

+0

1. это C# и из библиотеки OWIN/Katana. 2. Да, вам нужно будет проверить его на стороне сервера, чтобы убедиться, что это легальный токен. – Aram

1

В настоящее время у меня такая же проблема, и пытаются выяснить решение. Вот что я узнал:

После аутентификации вы получаете веб-токен JSON (см. Эту страницу https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). После его декодирования имеется несколько доступных данных. Но я не уверен, кто из них мог бы убедиться, что разрешил вход в систему только указанного Active Directory.

@Aram относится к значениям аудитории (aud) и арендатора (tid). К сожалению, аудитория всегда настроена на app_id, заданную с запросом, и арендатор всегда настроен на идентификатор арендатора на лазурном арендаторе, хотя вы используете, например, учетную запись live.com.

И наконец, я придумал, чтобы проверить наличие oid (»Идентификатор объекта (ID) объекта пользователя в Azure AD.«, https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). Я надеюсь, что этот будет установлен только в том случае, если пользователь является частью Active Directory, выдающего авторизацию.

В результате, я могу установить приложение, чтобы сделать следующее: Если в расшифрованной версии id_token в маркер доступа ответ нет oid собственности комплект - Логин-запрос будет отклонен.

Проблема заключается в следующем: я не могу подтвердить, что мой подход работает, потому что у меня нет второго Azure AD и я не могу проверить, не будут ли доступны только пользователи live/hotmail/... oid, но и пользователей из разных AD. Может быть, @bobbyr вы можете попробовать и сообщить?

+0

Привет, Томас, спасибо. Приятно знать, что не только я борюсь с этим :) Не могли бы вы рассказать мне, как вы декодируете JWT? – bobbyr

+0

Хорошо, проигнорируйте последний вопрос об декодировании. Я вижу, что существует стандартизованный метод для декодирования тонов JWT. – bobbyr

+0

@bobbyr. Ссылаясь на ваш ответ: это похоже на хороший второй вариант, если подход 'oid' окажется плохим. Благодаря! В общем, есть некоторые странные «ошибки» о API Azure OAuth/REST, которые абсолютно отсутствуют в многочисленных обширных документах или блогах Microsoft. (этот вопрос и, например, _resource_ вещь http://stackoverflow.com/questions/26762441/office-365-rest-api-auth/.) –

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