В этом вопросе есть несколько разных вопросов.
Активный веб-сеанс для пользователя. В настоящее время аутентификация пользователей платформы D2L Valence не работает таким образом. LMS будет возвращать пару UserID/Key как часть процесса аутентификации только тогда, когда она может подтвердить, что у нее есть активный сеанс с пользователем:
Клиент, вызывающий API, отправляет запрос непосредственно в LMS для получения пары UserID/Key для пользователя.
а. Если LMS имеет активный сеанс с пользователем, (при необходимости сгенерируйте и) верните пару UserID/Key для этой пары приложение/пользователь.
б. Если в LMS нет активного сеанса с пользователем, выполните процесс входа в систему, настроенный для аутентификации пользователя: это может быть перенаправление вызывающего веб-запроса на собственную страницу входа пользователя в LMS. , или что перенаправление может проходить через стороннюю службу, которую LMS использует для аутентификации пользователей (например, настроенный SSO IDP).
Что это означает: если вы используете API для инициации процесса аутентификации для получения пары UserID/Key, вызывающий веб-браузер (как часть этого процесса) уже будет иметь активный веб-сеанс с LMS. Либо пользователю будет предложено войти в систему, используя любой процесс аутентификации, который LMS использует для этого, или пользователь уже сделал это, и вызывающий браузер будет знать об этом (поскольку он имеет состояние cookie, указывающее на активное сессия).
Программный вход. В настоящее время платформа D2L Valence не поддерживает прямое участие в процессе аутентификации пользователя: нет вызовов для аутентификации пользователя в LMS путем предоставления идентификатора пользователя/пароля или любого другого секрета, совместно используемого между пользователем и СУО. Модель безопасности Valence специально направлена на то, чтобы клиент, вызывающий API, не знал о секрете аутентификации, совместно используемом пользователем и LMS.
Клиент, использующий API Valence Learning Framework, должен:
Инициируйте процесс аутентификации, запросив пару UserID/Key у LMS (в этом случае LMS попытается аутентифицировать пользователя; см. предыдущий ответ)
Перестроить пользовательский контекст, используя действительную пару UserID/Key из кэшированного состояния, которое уже получено из LMS (что, в свою очередь, потребует аутентификации реального пользователя в LMS).
Срок действия пары UserID/ключ. Обратите внимание, что эти токены аутентификации, предоставляемые LMS вызывающему клиенту, должны быть долгоживущими. Они должны длиться дольше текущей веб-сессии, которую браузер будет иметь для пользователя. Таким образом, клиентское приложение должно рассматривать их как защищенные данные, особенно в сочетании с собственной парой идентификатор/ключ клиентского приложения (поскольку пара идентификатор/ключ пользователя связана с собственной парой идентификатор/ключ приложения). Хотя мы ожидаем, что клиентские приложения будут кэшировать эти токены проверки подлинности, мы также ожидаем, что они будут кэшироваться как конфиденциальная информация.
Срок действия пары идентификатор/ключ пользователя, сгенерированной для приложения, истечет, когда произойдет одно из следующих событий:
Прибытие времени истечения срока действия, связанного с парой ID/Key, когда LMS сгенерировала его (администраторы LMS могут гарантировать, что значение срока действия по умолчанию для этих токенов является «неопределенным»)
Пароль пользователя меняется (либо пользователем, либо администратором LMS, который сбрасывает его)
Администратор LMS вручную отменяет доступ к клиентскому приложению для пользователя.
person
Viktor Haag
schedule
19.02.2013
