2

Я работаю над web-сервисом webapi, который протестирован Azure Active Directory. Вебсервис сильно сокращается с Office 365 (SharePoint/Yammer) на основе подписанного пользователя.Интеграционные тесты для web api с Azure AD

Чтобы проверить конечные точки веб-api, я пишу консольное приложение, которое позволяет мне войти в систему с моими учетными данными AAD, а затем вызывает конечные точки. Он работает, но ищет что-то, чтобы заменить этот способ тестирования веб-api. Было бы здорово, если бы оно было более повторяемым и что мне не нужно каждый раз заполнять мои учетные данные. Я искал проект модульного тестирования, но не могу получить знак Azure AD для работы.

Любые советы, как сделать это проще?

ответ

0

Если вы не хотите «заполнять мои учетные данные каждый раз», одно обходное решение использует Resource Owner Password Credentials Grant flow. Этот поток позволяет легко получить токен. В Консольном приложении вы можете напрямую использовать учетную запись пользователя и пароль чтобы получить токен доступа для вашего защищенного веб-ави. Код ниже для справки:

static void Main(string[] args) 
    { 

     test().Wait(); 
    } 


    public static async Task test() 
    { 

     using (HttpClient client = new HttpClient()) 
     { 
      var tokenEndpoint = @"https://login.windows.net/a703965c-e057-4bf6-bf74-1d7d82964996/oauth2/token"; 
      var accept = "application/json"; 

      client.DefaultRequestHeaders.Add("Accept", accept); 
      string postBody = @"resource=https%3A%2F%2Fgraph.microsoft.com%2F //here could be your own web api 
      &client_id=<client id> 
      &grant_type=password 
      &[email protected] 
      &password=<password> 
      &scope=openid"; 

      using (var response = await client.PostAsync(tokenEndpoint, new StringContent(postBody, Encoding.UTF8, "application/x-www-form-urlencoded"))) 
      { 

       if (response.IsSuccessStatusCode) 
       { 
        var jsonresult = JObject.Parse(await response.Content.ReadAsStringAsync()); 
        var token = (string)jsonresult["access_token"]; 
       } 
      } 
     } 
    } 

Но проблема в том, что поток будет разоблачать имя пользователя и пароль непосредственно в коде, это приносит потенциальный риск атаки, а также и мы всегда будем избегать обработки учетных данных пользователя напрямую. Поэтому убедитесь, что вы просто используете этот поток для тестирования в безопасной среде. Для получения дополнительной информации вы можете обратиться к this article.

+0

Если вы идете по этому маршруту, обязательно прочтите сообщение в блоге Vittorio об ограничениях этого потока: http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate- пользователи-Сквозные usernamepassword / – dstrockis

0

Самый простой способ - определить тестовый бегун как приложение в Azure AD и вызвать его API с его собственным идентификатором клиента и тайной.

Для этого есть несколько вещей, которые вы должны были бы сделать:

  1. Добавить appRoles в свой API в своем манифесте в Azure AD. Это разрешения приложений.
  2. Определите свой тестовый бегун и им потребуются необходимые разрешения для вашего API.
  3. В своем тестовом бегуне теперь вы можете получить токен доступа с идентификатором клиента и секретом тестового бегуна, при этом не требуется аутентификация пользователя.

Некоторые настройки необходимы для разрешений приложений на стороне API, а также авторизация должна также искать утверждения о роли.

Вы можете найти пример определения прав доступа к приложениям и их обработки здесь: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/.

Подробнее об определении разрешений для приложения: https://stackoverflow.com/a/27852592/1658906.

Подробная информация о заявке на участие в AAD: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-manifest.

EDIT: Если вы должны совершать звонки от имени пользователя в API, то это, конечно, не сработает.

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

+1

Я не думаю, что это сработает. Я должен был подчеркнуть это больше, но SharePoint, похоже, не принимает подход аутентификации приложений; –

+1

Правильно, если вы должны делать звонки от имени пользователя, тогда единственным вариантом является создание учетной записи пользователя для тестирования. – juunas

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

  • Нет связанных вопросов^_^