Метод аутентификации для REST API Desire2Learn против SOAP

Question

Я надеюсь, что кто-то может рассказать мне о том, как работает аутентификация с новым D2L REST API. Из моего чтения и игры с примером кода «GetStarted» кажется, что вызовы основаны на «уровне идентичности пользователя» и «принятии пользователя».

Для нас это немного проблематично.

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

Насколько я понимаю из документации REST, больше нельзя использовать привилегированную учетную запись веб-служб, так как ей придется каждый раз входить в систему и соглашаться на использование инструмента. Учащийся, выполняющий задание, не будет иметь этой информации (и мы бы тоже этого не хотели), и уровень доступа студента не позволит ему обновить столбец зачетной книжки, поэтому мы также не сможем использовать его «Идентификацию пользователя». .

Единственная альтернатива, о которой я могу подумать, - это хранить все оценки где-либо еще. Затем, когда это уместно, преподаватель курса будет входить в систему и обновлять дневник, используя свои «Уровень идентификации пользователя» и «Принятие пользователем»?

Это правильно?

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

Answer 1

Дополнительный вход в систему вручную не требуется, и есть два варианта, которые я видел в этом сценарии.Оба используют тот факт, что система аутентификации Valence использует ключи и подписи.При использовании подписей вместо отправки токенов даже открытый текст apis не подлежит перехвату сеанса, и в результате ключи могут безопасно оставаться действительными в течение длительного времени.Этот период обычно устанавливается равным 30 дням, но, когда используются приложения, подобные описанному вами, лучше не устанавливать тайм-аут.Вы можете связаться со службой поддержки по поводу настройки этого тайм-аута для вашего сервера.(Ключи по-прежнему сбрасываются, если пароли сбрасываются или они явно аннулированы).

При использовании долгоживущих ключей возможны следующие сценарии без непосредственного получения или сохранения пользователем пароля пользователя (хранение ключей по-прежнему необходимо выполнять безопасно):

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

Контекст учетной записи: если в приложении нет инструктора, можно создать учетную запись с правами на обновление оценок.Этот подход часто используется с D2LWS, но с дополнительным шагом.В этом сценарии ключи для учетной записи утилиты устанавливаются вне диапазона (например, пример начала работы (http://docs.valence.desire2learn.com/samples/gettingStarted.html) отобразит ключи). В качестве альтернативы может быть создан процесс установки или тип конфигурации, который автоматически записывает ключи из утилитыПосле записи этих ключей дополнительные интерактивные сеансы не требуются.