Вопрос

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

Добавлена ​​информация:Это для карты CAC, и на рабочих станциях есть ActivIdentity и Tumbleweed.Также при необходимости я мог бы добавить сервис на рабочие станции.Все браузеры IE7.Веб-сервер — IIS 6, а страницы написаны на ASP.NET (в основном).

Это было полезно?

Решение

Здесь задействовано несколько разных программ.

Во-первых, сама карта. Чтобы выполнить цифровую подпись, CAC должен быть в «проверен» состояние, то есть PIN-код был введен после того, как карта была вставлена. Кроме того, у каждого ключа на карте есть флаг, который указывает на необходимость ввода PIN-кода при каждом использовании ключа. Я не проверял, но я думаю, что это установлено для " электронной почты " пара ключей на CAC. Таким образом, вам нужно будет найти, какие ключи имеют это «всегда проверять». установите флажок и настройте валидатор пути в службе для приема только этих ключей. Возможно, вам потребуется конкретный OID при использовании расширенного ключа или исключить некоторые промежуточные сертификаты DoD из построения пути (возможно, пометив их как отозванные).

Промежуточное программное обеспечение на машине, взаимодействующей с картой, также может кэшировать ПИН-код и предоставлять его на карту всякий раз, когда карта указывает, что ей требуется ПИН-код до того, как она завершит операцию. Я думаю, что ActivClient делал это с помощью функции кэширования PIN-кода до версии 6, но в версии 7 эта опция, похоже, пропала. Я не нашел ничего подобного во встроенной поддержке Windows PIV. Эта " функция " может поставить под угрозу безопасность, поэтому я предполагаю, что она была намеренно удалена, и не было бы никаких взломов реестра или иным образом для восстановления поведения. Это то, что вы не можете контролировать, если не управляете машинами пользователей; нет заголовка HTTP или опции TLS, которую можно использовать для принудительного ввода PIN-кода. Но с более новыми системами это не должно быть проблемой.

На стороне сервера должно произойти полное рукопожатие, чтобы клиент выполнил аутентификацию. Аутентификация клиента не произойдет, если будет действительный сеанс TLS. Поэтому вам нужно найти способ сделать недействительным сеанс TLS (а не сеанс приложения, который, вероятно, связан с HTTP-cookie) перед запросом аутентификации, или перенаправить запрос аутентификации на другой интерфейс, для которого сеансы не включены.

Другие советы

Существует два способа аутентификации клиента по смарт-карте в Интернете:стандартный TLS/SSL или специальные плагины для браузера.Я предполагаю, что вы говорите о стандартных веб-браузерах (IE/FF/Safari) и аутентификации SSL.

Для запроса PIN-кода важны две вещи:

  • SSL Session и SSL -кэш в браузере
  • состояние аутентификации на карте соответствующего закрытого ключа
  • способ реализации промежуточного программного обеспечения.

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

Если сеанс в кеше браузера не может быть повторно использован или когда соединение устанавливается, промежуточное ПО смарт-карты (PKCS#11 в Linux, модуль CryptoAPI/BaseCSP в Windows или Tokend в OSX) должно взаимодействовать с ключами. на карте.Если состояние аутентификации на карте требует ввода PIN-кода, браузер обычно инициирует обратный вызов.Или, если промежуточное программное обеспечение знает, что ему понадобится PIN-код, оно запросит его перед обращением к карте.

Между вводом PIN-кода и фактической повторной аутентификацией прав доступа к закрытому ключу и повторной аутентификацией сеанса SSL не существует соотношения 1:1.

При использовании стандартного SSL вы зависите от того, как SSL реализован в браузерах, и не можете иметь 100% надежную «повторную аутентификацию путем ввода PIN-кода» на стороне клиента.

Если вы используете Linux, то с помощью OpenSC (который, AFAIK, может использовать карты CAC) вы можете установить для «transaction_reset» в opensc.conf значение true, что приведет к сбросу карты после каждой транзакции (каждое согласование сеанса SSL) и таким образом вы можете быть уверены, что всякий раз, когда вы открываете новый сеанс SSL, пользователю придется снова вводить PIN-код.Однако это конфигурация на стороне клиента, а не функция, инициируемая сервером.

Вы можете использовать функцию javascript, чтобы заставить браузер забыть о существующем кеше SSL в нескольких браузерах:

function logout() {
    // clear browser authentication cache
    // IE specific
    try
    {
        document.execCommand("ClearAuthenticationCache", "false");
    }
    catch(e)
    {
        // do nothing
    }

    // clear for firefox or any browser that supports window.crypto API
    if (window.crypto && typeof window.crypto.logout === "function") {
        window.crypto.logout();
    }
}

Вы можете использовать метод setTimeout Javascript, чтобы вызвать вышеуказанную функцию выхода из системы и, возможно, перенаправить их на страницу logout.aspx, чтобы заставить клиента ввести новый PIN-код.

Но он использует JavaScript, а код зависит от браузера и работает не для всех браузеров.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top