Взаимодействующие модульные средства сбора удостоверений и доступа

Взаимодействующие модульные средства сбора удостоверений и доступа

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится в общем к области машинного доступа, в частности к идентификации и аутентификации (установлению подлинности) объекта, пользователя или принципала (пользователя или процесса, имеющего учетную запись) с удостоверением для логического входа в локальную и/или удаленную машину, имеющую операционную систему.

Предшествующий уровень техники

На Фиг.1 показан иллюстративный традиционный процесс 100, позволяющий пользователю войти в систему инфраструктуры аутентификации операционной системы локальной машины. В данном случае термин «локальная машина» означает вычислительное устройство с операционной системой, такое как персональный компьютер, карманный компьютер, устройство «толстый» клиент, устройство «тонкий» клиент, персональное цифровое информационное устройство, экспертная система и т.д. Инфраструктура аутентификации производит аутентификацию пользователя с использованием удостоверения с целью предоставления доступа к вычислительному устройству посредством его операционной системы, такой как операционная система WINDOWS®, поставляемая корпорацией Майкрософт, Редмонд, Вирджиния, США. Аутентификация удостоверения здесь рассматривается как эквивалентная аутентификации пользователя, объекта или принципала с соответствующим удостоверением, причем эти понятия и концепции используются здесь как взаимозаменяемые.

На этапе 102 процесса 100 операционная система выполняет программу логического входа. Программа логического входа может передать управление только одному из трех (3) различных модулей аутентификации. Иными словами, локальная машина может иметь только один модуль аутентификации, с помощью которого может быть произведена аутентификация. В случае операционной системы (ОС) WINDOWS® модулем аутентификации по умолчанию является Графический модуль идентификации и аутентификации, обозначаемый здесь как 'GINA'. Модуль GINA в составе ОС WINDOWS® представляет собой динамически подключаемую библиотеку (*.dll), реализующую пользовательский интерфейс логического входа на дисплее в виде экрана с диалоговым окном логического входа, куда пользователь вводит имя пользователя и пароль. Модуль GINA осуществляет аутентификацию пользователя в операционной системе вычислительного устройства посредством использования удостоверений, предъявляемых пользователем. Удостоверения пользователя представлены набором информации, включающим в себя идентификацию и подтверждение идентификации, которые используются для получения доступа к локальным и сетевым ресурсам.

Примерами удостоверений являются имя пользователя и пароль, смарт-карты, биометрические удостоверения, цифровые сертификаты X.509 и другие виды сертификатов. Модуль GINA 104, показанный на Фиг.1, является стандартным модулем ОС WINDOWS® и требует традиционного интерактивного процесса логического входа, такого как предложение пользователю ввести имя пользователя и пароль в пользовательском интерфейсе 103. После выполнения GINA 104 управление передается модулю 106 локальных средств защиты безопасности (LSA). Модуль 106 LSA обращается к локальной базе данных менеджера (средства управления) 108a учетных записей системы безопасности (SAM), каждая из которых представляет собой локальное хранилище информации логического входа и безопасности для данного вычислительного устройства и/или релевантного окружения. База 108b данных удостоверений, которая может быть локальной или удаленной, может хранить такие удостоверения, как отпечатки пальцев, пароли, информацию о сетчатке глаза, информацию распознавания лиц и другую биометрическую информацию, которая может быть использована для аутентификации пользователя в соответствии с конкретным GINA. Модуль 106 LSA может также установить соединение для доступа к удаленной базе данных удостоверений, к службе удостоверений с маркерным протоколом, к службе удостоверений с протоколом запроса-ответа, и/или к Активному каталогу (AD) и центру 110 распределения ключей Kerberos (KDC). Kerberos представляет собой сетевой протокол аутентификации для идентификации пользователей, пытающихся осуществить логический вход в сеть, и для шифрования выполняемого ими обмена данными посредством криптографии с секретным ключом. Модуль AD использует технологию, позволяющую приложениям находить, использовать и управлять ресурсами каталогов (например, именами пользователей и полномочиями) в распределенной вычислительной среде. С помощью таких видов доступа производится идентификация и аутентификация пользователя согласно пользовательским удостоверениям с целью определения привилегий доступа пользователя в отношении логического входа в вычислительное устройство посредством операционной системы. При успешной идентификации и аутентификации пользователю будет разрешен логический вход, и управление будет возвращено модулю 102 логического входа ОС. После этого пользователь считается осуществившим логический вход и может начать использование вычислительного устройства.

Модуль 112 GINA опосредованной аутентификации первого типа, показанный на Фиг.1, является сторонним модулем идентификации и аутентификации, который может быть написан независимым производителем программного обеспечения, не разрабатывавшим операционную систему. Модуль 112 GINA опосредованной аутентификации первого типа взаимодействует с устройством 105 чтения смарт-карт, а также с используемым по умолчанию базовым модулем 114 GINA операционной системы. Модуль 112 GINA опосредованной аутентификации первого типа принимает удостоверения, считываемые устройством 105 чтения смарт-карт со вставленной в него смарт-карты. Сертификат, считываемый со вставленной в устройство 105 чтения смарт-карт смарт-карты, а также любые другие удостоверения, полученные от пользователя, могут быть использованы для идентификации и аутентификации пользователя по базе 108b данных удостоверений. В таком случае модуль 112 GINA опосредованной аутентификации первого типа позволяет вносить ограниченные изменения в процесс идентификации и аутентификации пользователя при поддержке процедуры идентификации и аутентификации, используемой по умолчанию, согласно интерфейсу базового модуля 114 GINA операционной системы.

Модуль 116 GINA опосредованной аутентификации второго типа представляет собой полную замену стандартного модуля 104 GINA операционной системы. Модуль 116 GINA опосредованной аутентификации второго типа взаимодействует с устройством 107 чтения отпечатков пальцев. Модуль 116 GINA опосредованной аутентификации второго типа получает удостоверения, считываемые устройством 107 считывания отпечатков пальцев, из оптически сканированного изображения пальцев. Оптически сканированное изображение пальцев, вставленных в устройство 107 считывания отпечатков пальцев, а также любые другие удостоверения, полученные от пользователя, могут быть использованы для идентификации и аутентификации пользователя по базе 108b данных удостоверений. Модуль 116 GINA опосредованной аутентификации второго типа является сторонним модулем идентификации и аутентификации, который не взаимодействует со стандартным модулем GINA ОС, а напрямую взаимодействует с LSA 106. В отличие от модуля 112 GINA опосредованной аутентификации первого типа, модуль 116 GINA опосредованной аутентификации второго типа допускает полное управление пользовательским интерфейсом, который пользователь видит при логическом входе. Типичной проблемой, как указывалось выше, является то, что только один из модулей GINA 104, модуль 112 GINA опосредованной аутентификации первого типа или модуль 116 GINA опосредованной аутентификации второго типа, может использоваться с операционной системой. Иными словами, никакой сторонний или стандартный модуль GINA не может сосуществовать с другим сторонним модулем GINA, посредством которого ОС могла бы предоставить пользователю доступ к вычислительному устройству или вычислительной среде.

В дополнение к изложенному могут возникнуть другие ограничения в использовании сторонних модулей GINA, например, применение любого нового механизма сбора удостоверений или изменение существующего (например, для биометрических данных, смарт-карт, маркеров и т.д.) для доступа к операционной системе вычислительного устройства. В этом случае сторонний модуль GINA накладывает на разработчика значительное бремя в части кодирования. Для применения нового или измененного механизма сбора удостоверений разработчик должен написать новую модель аутентификации для аутентификации пользователя, желающего получить доступ к вычислительному устройству. В случае ОС WINDOWS® разработчик должен написать полностью пересмотренный сторонний модуль GINA, включающий в себя сложные коды интерфейса и управления состояниями, чтобы сторонний модуль GINA мог взаимодействовать напрямую с системными компонентами ОС. Ненадлежащее кодирование стороннего модуля GINA может подорвать надежность ОС.

Замена стороннего или стандартного модуля GINA весьма чувствительна в том смысле, что это один из важнейших компонентов безопасности ОС. Некачественный модуль GINA может значительно ослабить надежность ОС и снизить ее функциональность. Сложность разработки заменяющего или стороннего модуля GINA может также потребовать от разработчика получения базовых исходных кодов стандартного модуля GINA ОС. Более того, инсталляция стороннего модуля GINA означает замену стандартного модуля GINA, так как два способа сбора удостоверений (например, GINA) не могут сосуществовать в одном компьютерном устройстве. Это не позволяет независимым разработчикам программного обеспечения разрабатывать решения, применяемые повсеместно и позволяющие пользователям осуществлять логический вход посредством более чем одной инфраструктуры аутентификации. В данной области техники большие преимущества предоставило бы решение способа логического входа, позволяющее пользователям осуществлять логический вход посредством различных, совместно существующих инфраструктур аутентификации, таких как выбираемый сетевой сеанс, где были бы преодолены сформулированные выше проблемы.

Сущность изобретения

В различных вариантах осуществления удостоверения транслируются посредством одного из множества различных и сосуществующих модулей провайдера (поставщика) удостоверений. Каждый модуль преобразует соответствующий отличающийся тип удостоверений в общий протокол удостоверений. Транслированные удостоверения передаются посредством интерфейса прикладного программирования (API) провайдера удостоверений модулю пользовательского интерфейса (UI) логического входа собственной операционной системы (ОС) локальной машины. Для аутентификации пользователя согласно преобразованным удостоверениям по базе данных удостоверений вызывается стандартная процедура логического входа ОС. В случае успешной аутентификации пользователь, идентифицированный посредством преобразованных удостоверений, осуществляет логический вход и получает доступ к локальной машине.

В других вариантах осуществления модулем UI логического входа ОС осуществляется запрос через API менеджера провайдеров предварительного доступа (PLAP). Запрашивается одноуровневый список служб доступа соответствующего множества совместно существующих отличающихся модулей PLAP. Одноуровневый список служб доступа отображается модулем UI логического входа на экране. Принимаются введенное удостоверение и выбор одной из служб доступа, отображенных в одноуровневом списке на экране. При установлении соединения с сетью с использованием выбранной службы доступа удостоверения передаются в базу данных удостоверений службы доступа для первичной аутентификации. В случае успешной первичной аутентификации удостоверения передаются из API PLAP модулю UI логического входа. Модуль UI логического входа осуществляет вызов RPC (вызов удаленной процедуры) для передачи удостоверений модулю логического входа ОС. Далее удостоверения передаются с модуля логического входа ОС посредством пользовательского вызова логического входа LSA на LSA. LSA производит вторичную аутентификацию пользователя по базе данных удостоверений. В случае успешной вторичной аутентификации пользователь, идентифицированный удостоверениями, успешно осуществляет логический вход для использования локальной машины посредством ОС.

Перечень фигур чертежей

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

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

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

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

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

Фиг.5a - экранное окно, где пользователь вводит удостоверения в виде имени пользователя и пароля, по которым провайдер удостоверений произведет идентификацию и аутентификацию.

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

Фиг.5c - экран логического входа, позволяющий пользователю выбрать опцию, которая, будучи выбранной, отобразит на экране выбор типов учетных записей и выбор типов соединений для входа в систему.

Фиг.6a - экран логического входа, позволяющий пользователю выбрать тип учетной записи и тип соединения для входа в систему из списков в соответствующих ниспадающих меню.

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

Фиг.7a - экран логического входа, отображающий две (2) учетные записи, которые на текущий момент осуществили логический вход в локальную машину.

Фиг.7b - экран логического входа, отображающий пользовательскую учетную запись с приглашением ввода Персонального идентификационного номера (PIN) в качестве удостоверения для идентификации и аутентификации с целью осуществления логического входа в локальную машину.

Фиг.8a - экран логического входа, отображающий две (2) учетные записи, которые на текущий момент осуществили логический вход в локальную машину, и третью учетную запись, соответствующую сертификату смарт-карты, считываемому локальной машиной, которая отображает экран логического входа.

Фиг.8b - экран логического входа, отображающий две (2) учетные записи, для первой из которых отображено приглашение на ввод PIN для проверки соответствия как удостоверения сертификату смарт-карты, считываемому локальной машиной, которая отображает экран логического входа.

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

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

Фиг.9c - экран логического входа, отображающий одну (1) учетную запись, для которой соответствующий пользователь прошел процедуру аутентификации с целью получения доступа к локальной машине с использованием удостоверения, включающего в себя отпечатки пальцев пользователя.

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

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

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

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

Фиг.14 - пример вычислительной среды, в которой могут быть полностью или частично реализованы описанные здесь программные приложения, способы и системы.

Для обозначения аналогичных компонентов и элементов в описании и прилагаемых фигурах чертежей используются одинаковые номера. Номера серии 100 относятся к элементам, исходно указанным на Фиг.1, номера серии 200 относятся к элементам, исходно указанным на Фиг.2, номера серии 300 относятся к элементам, исходно указанным на Фиг.3 и т.д.

Детальное описание

Различные варианты осуществления предполагают сосуществующие модули, взаимодействующие с операционной системой вычислительного устройства, причем каждый модуль может осуществлять аутентификацию принципала, объекта или пользователя с помощью набора информации (например, удостоверений), содержащего идентификацию и подтверждение идентификации, используемые для получения доступа к локальным и сетевым ресурсам посредством операционной системы. Более того, в результате установления стабильного интерфейса между модулями и операционной системой изменения, касающиеся только одного из модулей и операционной системы, не влияют на процессы идентификации и аутентификации, производимые другими модулями.

Фиг.2a показывает блок-схему последовательности операций, демонстрирующую иллюстративный процесс 200a идентификации и аутентификации пользователей с целью логического входа и получения доступа к локальным и сетевым ресурсам через операционную систему локальной машины. Множество модулей 202 провайдеров удостоверений предоставлено различными независимыми поставщиками программного обеспечения, любой из которых может быть использован локальной машиной для идентификации и аутентификации пользователей. По существу, модули 202 провайдеров удостоверений представляют собой совместно существующие интерфейсы операционной системы, посредством которых пользователь может осуществить логический вход в локальную машину с помощью ее операционной системы.

Каждый модуль 202 провайдера удостоверений использует отдельный процесс идентификации и аутентификации. Один модуль 202 провайдера удостоверений использует пользовательский интерфейс (UI) 107, принимающий в качестве удостоверений имя пользователя и пароль. Другой модуль 202 провайдера удостоверений использует маркер 208. В качестве примера, маркер 208 может быть физическим устройством. Физическое устройство хранит номер, считываемый устройством чтения при попытке пользователя осуществить логический вход в вычислительное устройство. После каждого логического входа, либо с периодическими интервалами с помощью основывающегося на времени алгоритма, номер, хранимый в маркере 208, меняется. Новый номер может быть сохранен также в вычислительном устройстве для будущих аутентификаций. Пользователь может также получить приглашение на ввод Персонального идентификационного номера (PIN) в дополнение к считыванию маркера 208 устройством чтения. Устройство 103 чтения отпечатков пальцев и/или устройство 105 чтения смарт-карт могут использоваться другими модулями 202 провайдеров удостоверений для, соответственно, считывания в качестве удостоверений отпечатков пальцев пользователя, полученных устройством 103 считывания отпечатков пальцев, или считывания удостоверений со смарт-карты, вставленной в устройство 105 чтения смарт-карт. Конечно же, другие устройства считывания удостоверений могут использоваться для предоставления удостоверений другим модулям 202 провайдеров удостоверений, такие как модуль сканирования сетчатки глаза, модуль камеры распознавания лица, модуль камеры распознавания походки, модуль распознавания почерка, модуль распознавания голоса, модуль распознавания запаха, модуль распознавания генетического кода и другие подобные биометрические модули.

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

Каждый модуль 202 провайдера удостоверений может принимать и преобразовывать удостоверения в общий протокол удостоверений. Протокол удостоверений обеспечивает совместимость преобразованных удостоверений с компонентом аутентификации собственной операционной системы локальной машины. Аутентификация преобразованных удостоверений осуществляется по базе данных удостоверений. В случае успешной аутентификации пользователю, идентифицированному посредством удостоверения, разрешается логический вход в собственную операционную систему для доступа к локальной машине.

Каждый модуль 202 провайдера удостоверений взаимодействует с интерфейсом 204 прикладного программирования (API) провайдера удостоверений для обработки обмена данными с системой аутентификации. API 204 провайдера удостоверений взаимодействует с вызывающей стороной, которой может служить Пользовательский интерфейс 206 (UI) логического входа. UI 206 логического входа может быть менеджером удостоверений, получающим и обслуживающим удостоверения пользователя. UI 206 логического входа использует Процедуру удаленного вызова (RPC) модуля 102 логического входа операционной системы (ОС). Модуль 102 логического входа ОС является интерфейсом к ОС вычислительного устройства. Модуль 102 логического входа ОС осуществляет пользовательский вызов логического входа локальных средств защиты (LSA) в модуль 106 локальных средств защиты (LSA). Как описывалось выше со ссылкой на Фиг.1, модуль 106 LSA осуществляет доступ к локальной базе 108а данных менеджера учетных записей системы безопасности (SAM) для типичной идентификации и аутентификации имени пользователя и пароля. Модуль 106 LSA может также осуществить доступ к локально хранимой базе данных 108b удостоверений для идентификации и аутентификации принципала, элемента или пользователя посредством удостоверений, собранных устройством чтения, аналогичным одному из устройств 103-107 и 208 чтения удостоверений.

Преобразованные удостоверения передаются через API 204 провайдера удостоверений на UI 206 логического входа и далее модулю 102 логического входа ОС для локальной аутентификации посредством модуля 106 LSA с целью осуществления пользователем логического входа в локальную машину. В альтернативном случае модуль 106 LSA может осуществить удаленный доступ за пределы локальной машины посредством соединения, устанавливаемого с доменом. В домене можно получить доступ к хранимым там Активному каталогу (AD) и центру распределения ключей Kerberos (KDC) 110. Посредством такого доступа производятся идентификация и аутентификация пользователя по преобразованным удостоверениям, и определяются привилегии доступа пользователя для логического входа в локальную машину через ОС. Успешная идентификация и аутентификация позволяют пользователю осуществить логический вход. Пользователь, осуществивший логический вход через ОС, может начать использование локальной машины.

Общий иллюстративный процесс 200b логического входа показан на Фиг.2b и будет описан со ссылками на Фиг.2a. Процесс 200b логического входа начинается с этапа 212, где операционная система (ОС) локальной машины загружает Пользовательский интерфейс (UI) 206 логического входа. На этапе 214 UI 206 логического входа загружает и инициализирует всех зарегистрированных провайдеров 202 удостоверений с использованием API 204 провайдеров удостоверений.

На этапе 216 модуль 102 логического входа ОС передает UI 206 логического входа команду отобразить экран приветствия UI, который пользователь может видеть и взаимодействовать. На этапе 218 пользователь вводит последовательность клавиш control-alt-delete (CAD). При вводе пользователем последовательности CAD, либо другой последовательности клавиш, которая также является Последовательностью обращения к системе безопасности (SAS), генерируется аппаратное событие, которое может быть перехвачено только ОС. Это действие пользователя заставляет модуль 102 логического входа ОС уведомить UI 206 логического входа на этапе 220 о готовности к приему удостоверений логического входа. На этапе 222 UI 206 логического входа демонстрирует UI для логического входа, как предписывает модуль 202 провайдера удостоверений, используемый по умолчанию. UI 206 логического входа запрашивает модули 202 провайдеров удостоверений о предоставлении одноуровневого списка всех провайдеров удостоверений для его отображения. На этапе 224 UI 206 логического входа принимает входные данные, сообщающие о выборе пользователем одного из множества отображенных провайдеров удостоверений, каждый из которых соответствует одному из модулей 202 провайдеров удостоверений. Эти входные данные инициируют взаимодействие между пользовательским вводом и одной или более внешними системами через API 204 провайдеров удостоверений. Конкретный модуль 202 провайдера удостоверений может зависеть от типа события, инициируемого пользователем для предоставления ОС удостоверений (например, посредством использования пользователем одного из устройств чтения 103-107 и 208 удостоверений). На этапе 226 UI 206 логического входа возвращает полученные удостоверения модулю 102 логического входа ОС посредством RPC. На этапе 228 модуль 102 логического входа ОС производит пользовательский вызов логического входа LSA в LSA 106 для осуществления логического входа пользователя. На этапе 230 модуль 102 логического входа ОС производит RPC в отношении UI 206 логического входа для сообщения результатов процесса 200b логического входа. На этапе 232 UI 206 логического входа вызывает конкретный модуль провайдера 202 удостоверений через API 204 провайдеров удостоверений для сообщения результатов процесса 200b логического входа. После этого управление возвращается модулю 102 логического входа ОС. На этапе 234 модуль 102 логического входа ОС завершает установление сеанса пользователя, и пользователь осуществляет логический вход в компьютерное устройство.

Процесс 300, показанный на Фиг.3 и отображенный в виде блок-схемы последовательности операций, демонстрирует этапы, посредством которых локальная машина 300a может использовать процесс аутентификации нижнего уровня в домене 300b для аутентификации пользователя по его удостоверениям. Провайдер 302 удостоверений аутентификации нижнего уровня на локальной машине 300a взаимодействует с системой 304 аутентификации нижнего уровня в домене 300b. Домен 300b, в частности, может быть сторонним сервером. Провайдер 302 удостоверений аутентификации нижнего уровня взаимодействует с API 204 провайдеров удостоверений описанным выше способом в соответствии с Фиг.2. По существу, процесс 300 аналогичен процессу 200a в части блоков 206, 102 и 106. В процессе 300 AD/KDC 110 взаимодействуют с LSA 106. Система 304 аутентификации нижнего уровня в домене 300b использует протокол аутентификации нижнего уровня для возвращения удостоверений логического входа провайдеру 302 удостоверений аутентификации нижнего уровня.

Процесс 300 использует процесс предварительной аутентификации, при котором пользовательские удостоверения используются для аутентификации пользователя согласно стороннему способу аутентификации вместо такового на локальной машине. По окончании аутентификации сторонний способ возвращает удостоверения, совместимые с ОС, чтобы обеспечить логический вход пользователя в локальную машину 300a через ее ОС. На практике провайдер 302 удостоверений аутентификации нижнего уровня взаимодействует через API 204 провайдеров удостоверений с UI 206 логического входа, показанный на Фиг.3. Когда пользователь вводит удостоверения, эти удостоверения отправляются с локальной машины 300a на AD/KDC 110 в домене 300b, который может являться для локальной машины 300a сетевым сервером. AD/KDC 110 во взаимодействии с системой 304 аутентификации нижнего уровня в домене 300b производит аутентификацию пользователя по его удостоверениям. Система 304 аутентификации нижнего уровня возвращает удостоверения логического входа провайдеру 302 аутентификации нижнего уровня. Провайдер 302 аутентификации нижнего уровня возвращает удостоверения UI 206 логического входа через API 204 провайдеров удостоверений. После этого UI 206 логического входа может передать удостоверения модулю 102 логического входа ОС посредством RPC. Соответственно, ОС локальной машины 300a изолирована от сторонней системы 304 аутентификации нижнего уровня в домене 300b.

Фиг.4 содержит блок-схему последовательности операций, изображающую иллюстративный процесс 400, посредством которого принципал, элемент или пользователь может быть аутентифицирован по дополнительным удостоверениям для получения доступа к домену, такому как Web-сайт, и в котором принимают участие запросчик удостоверений и аутентификатор 406 (средство аутентификации) Web-сайта. По существу, после того, как принципал, элемент или пользователь осуществил логический вход в локальную машину, принципал, элемент или пользователь проходит процедуру удаленной аутентификации посредством запросчика удостоверений и аутентификатора 406 Web-сайта, обрабатывающих дополнительные удостоверения. Пользовательский интерфейс (UI) 402 удостоверений запрашивает дополнительные удостоверения посредством приложения 404, выполняемого на локальной машине. Локальная машина содержит ОС, в которую пользователь осуществил логический вход как активный. Локальная машина находится на связи с устройством ввода (например, 103, 105, 107 или 208), посредством которого могут быть получены дополнительные удостоверения. Один из множества различных совместно существующих модулей 202 провайдеров удостоверений используется для сбора дополнительных удостоверений пользователя с устройства ввода (например, 103, 105, 107 или 208). Как только дополнительные удостоверения собраны, они передаются приложению 404 для аутентификации. Приложение 404 является локальным приложением, исполняемым на локальной машине, которое может запрашивать и получать дополнительные удостоверения. Каждый из модулей 202 провайдеров удостоверений может собирать различные типы удостоверений, таких как дополнительные удостоверения, с одного из устройств ввода (103, 105, 107, 208), и каждый модуль 202 провайдера удостоверений взаимодействует через API 204 провайдеров удостоверений с ОС локальной машины. API 204 провайдеров удостоверений получает удостоверения, собранные одним из модулей 202 провайдеров удостоверений, причем каждый модуль 202 провайдера удостоверений может предоставлять соответствующий тип собираемых им удостоверений API 204 провайдеров удостоверений для аутентификации принципала, такого как пользователь, с целью осуществления логического входа принципала в ОС для доступа к локальной машине.

Иллюстративные изображения экрана дисплея, демонстрирующие различные варианты осуществления, которые предоставляют различные варианты логического входа, показаны на Фиг.5a-10 и 12. Один вариант осуществления использует имя пользователя и пароль для ввода в модуль провайдера удостоверений, что может быть способом по умолчанию для ввода пользователем удостоверений в экране логического входа. Другой вариант осуществления использует смарт-карту Инфраструктуры открытого ключа (PKI) для ввода удостоверений во взаимодействии с модулем провайдера удостоверений смарт-карт. Еще один вариант осуществления использует модуль провайдера удостоверений с удостоверением в виде отпечатков пальцев, при этом провайдер удостоверений проводит идентификацию и аутентификацию пользователя по его отпечаткам пальцев, полученным путем сканирования.

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