Устройство обработки информации и способ управления устройством обработки информации - RU2607279C2
Код документа: RU2607279C2
Чертежи
Описание
УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
[0001] Настоящее изобретение относится к устройству обработки информации и способу управления устройством обработки информации.
ОПИСАНИЕ УРОВНЯ ТЕХНИКИ
[0002] Известны многофункциональные периферийные устройства (MFP: многофункциональное периферийное устройство), имеющие функции, такие как функции для сканирования, печати и связи. MFP снабжено панелью управления на основном корпусе, и пользователь может использовать функцию копирования, функцию сканирования или подобные, из MFP посредством эксплуатации панели управления. Также, в последние годы, MFP снабжаются функциями, такими как функции для сервера совместного использования файлов, веб-сервера или подобными, и терминал в сети имеет возможность осуществления доступа к функциям сервера MFP с использованием протокола связи, такого как SMB (блок сообщений сервера), HTTP или подобного. Также MFP снабжаются MIB (базой информации управления), и терминал в сети имеет возможность осуществления доступа к MIB для MFP и использованием SNMP v3 (RFC3414 (модель обеспечения защиты на уровне пользователей (USM)) для версии 3 простого протокола управления сетью (SNMP v3)), который известен как протокол управления сетевым устройством.
[0003] К тому же, в последние годы, MFP снабжаются механизмом аутентификации пользователей для идентификации пользователя, который использует MFP. В общем, в случаях, когда единое MFP обеспечивается множеством функций, протоколами связи или подобным, MFP обеспечивается множеством механизмов аутентификации пользователей, соответствующих каждой из функций, протоколов связи или подобного. Например, существуют случаи, в которых каждый из механизмов аутентификации пользователей является разным для панели управления, для веб-сервера, для сервера совместного использования файлов и для SNMP v3.
[0004] В случаях, когда единое MFP снабжается множеством механизмов аутентификации пользователей таким образом, есть нижеследующие способы координирования механизмов аутентификации. Подход для ассоциации и синхронизации пользовательской информации, используемой в основном для аутентификации для панели управления, и пользовательской информации, управляемой посредством USM (модель обеспечения защиты на уровне пользователей) из SNMP v3, известен (например, выложенная заявка на патент Японии № 2006-195755).
[0005] Также, в последние годы, считается, что для MFP необходима защита, аналогичная защите сетевого терминала, такого как персональный компьютер. По этой причине появились MFP, снабженные механизмом аутентификации пользователей, соответствующим политике паролей (период действия пароля, сложность пароля, настройки/управление блокировкой), журналом аутентификации (записям журналов успеха/сбоя аутентификации), или подобным.
[0006] В случае, когда множество механизмов аутентификации пользователей существуют в едином устройстве, существуют нижеследующие проблемы.
- Есть случаи, в которых для каждого механизма аутентификации пользователей регистрируется учетная запись для одного и того же пользователя, и управление пользовательской информацией является затруднительным. Координация между механизмами для выполнения аутентификации пользователей становится необходимой, как в изобретении, изложенном в выложенной заявке на патент Японии №2006-195755, для того, чтобы сделать одну и ту же учетную запись пригодной для использования множеством механизмов аутентификации пользователей и не обременять пользователя.
- С точки зрения защиты, предпочтительно, чтобы механизм аутентификации пользователей, поддерживающий политику паролей, ведение журнала аутентификации или подобного, и механизм аутентификации пользователей, который не поддерживает политику паролей, ведение журнала аутентификации или подобного, не смешивались на едином устройстве. По этой причине существует проблема, что для поставщиков, которые изготовляют устройства, необходимо нести издержки на разработку для того, чтобы предоставить эквивалентную функцию обеспечения защиты для множества механизмов аутентификации пользователей.
[0007] В случае, когда множество механизмов аутентификации пользователей существуют в едином устройстве, из-за вышеописанных проблем, целесообразной является конфигурация, в которой главным образом используется единый механизм аутентификации пользователей, в случае, когда протоколы связи, функции или подобные являются разными. Однако в каждом способе аутентификации пользователей каждого вида протокола связи есть различия в спецификациях, и поддержка обработки, относящейся к аутентификации пользователей для всех протоколов связи в едином механизме аутентификации пользователей, является трудной. Например, так как схема, заданная USM из SNMP v3, выполняет не только аутентификацию пользователей с использованием пароля пользователя, но также выполняет криптографическую обработку, обработку обнаружения сигнатуры/фальсификации или подобное, с помощью ключа, сгенерированного на основе пароля, такая обработка является сложной.
[0008] Также, для протоколов, которые заданы посредством RFC и в основном хорошо известны, в основном публикуются программные модули или исходный код, которые реализуют протокол. По этой причине поставщики, реализующие сервер, имеют возможность использования существующих программных модулей, исходного кода или подобного. Однако это потребует очень большого объема работ и много человеко-часов для того, чтобы поставщики, которые изготовляют устройства, заменили существующие программные модули и исходный код, который различается для каждого протокола, механизмом аутентификации пользователей, общим для всех частей устройства с учетом аутентификации пользователей. Также, в случаях, когда спецификации, касающиеся проверки политики паролей, изменения паролей и записи в журнал аутентификации, не заданы в протоколе, существующие опубликованные программные модули и исходный код не имеют таких функций. Соответственно, поставщик, который изготавливает устройство, должен добавить/реализовать функции, такие как проверка политики паролей, изменение паролей и осуществление записи в журнал аутентификации, в существующих программных модулях и исходном коде, и проблема состоит в том, что это требует очень большого объема работ и много человеко-часов.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0009] Аспектом настоящего изобретения является устранение вышеупомянутых проблем с традиционной технологией.
[0010] Признаком настоящего изобретения является предоставление способа, в котором возможно интегрировать администрирование, относящееся к аутентификации пользователя.
[0011] Настоящее изобретение в своем первом аспекте предоставляет устройство обработки информации, способное принимать запрос аутентификации в соответствии с протоколом из множества протоколов, причем устройство содержит: запоминающий блок, сконфигурированный с возможностью хранения идентификатора пользователя и пароля для каждого пользователя и способа вычисления для каждого протокола; блок получения, сконфигурированный с возможностью приема запроса аутентификации из удаленного компьютера в соответствии с протоколом из множества протоколов, причем запрос аутентификации включает в себя данные аутентификации; блок управления, сконфигурированный с возможностью:
(i) получения, из запоминающего блока, пароля, соответствующего данным аутентификации, которые включены в запрос аутентификации;
(ii) получения, из запоминающего блока, способа вычисления, соответствующего протоколу;
(iii) преобразования полученного пароля в хэш в соответствии с полученным способом вычисления; и
(iv) верификации подлинности данных аутентификации с помощью хэша.
[0012] Настоящее изобретение в своем втором аспекте предоставляет способ управления устройством обработки информации, способным принимать запрос аутентификации в соответствии с протоколом из множества протоколов, причем способ содержит: этап сохранения для сохранения в память идентификатора пользователя и пароля для каждого пользователя и способа вычисления для каждого протокола; этап приема для приема запроса аутентификации от удаленного компьютера в соответствии с протоколом из множества протоколов, причем запрос аутентификации включает в себя данные аутентификации; этап управления для:
(i) получения, из памяти, пароля, соответствующего данным аутентификации, которые включены в запрос аутентификации;
(ii) получения, из памяти, способа вычисления, соответствующего протоколу;
(iii) преобразования полученного пароля в хэш в соответствии с полученным способом вычисления; и
(iv) верификации подлинности данных аутентификации с помощью хэша.
[0013] Дополнительные признаки настоящего изобретения станут понятны из нижеследующего описания примерных вариантов осуществления со ссылкой на приложенные чертежи.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0014] Прилагаемые чертежи, которые включены в состав и образуют часть данного описания, иллюстрируют варианты осуществления данного изобретения и, вместе с данным описанием, служат для разъяснения принципов данного изобретения.
[0015] Фиг. 1 изображает упрощенный вид, показывающий конфигурацию сети согласно первому варианту осуществления настоящего изобретения.
[0016] Фиг. 2 является блок-схемой, показывающей конфигурацию аппаратных средств MFP согласно первому варианту осуществления.
[0017] Фиг. 3 является блок-схемой для разъяснения конфигурации программного обеспечения MFP и PC и конфигурации данных, которыми программное обеспечение управляет согласно первому варианту осуществления.
[0018] Фиг. 4A-4D изображают виды, показывающие пользовательские интерфейсы, на которых локальные UI отображаются на пульте управления согласно первому варианту осуществления.
[0019] Фиг. 5A-5F изображают виды для разъяснения пользовательских интерфейсов настроек.
[0020] Фиг. 6 изображает вид, показывающий пример конфигурации данных из базы данных пользователей согласно первому варианту осуществления.
[0021] Фиг. 7A-7С изображают виды, показывающие примеры API, которые имеет система аутентификации пользователей согласно первому варианту осуществления.
[0022] Фиг. 8 изображает вид, показывающий пример содержимого таблицы обработки аутентификации согласно первому варианту осуществления.
[0023] Фиг. 9 является схемой последовательности операций для описания функционирования системы аутентификации пользователей, когда API по Фиг. 7A вызывается в MFP согласно первому варианту осуществления.
[0024] Фиг. 10A-10D изображают виды, показывающие взаимосвязи программных модулей, когда MFP выполняет аутентификацию пользователей, вместе с потоком данных согласно первому варианту осуществления.
[0025] Фиг. 11 изображает вид, показывающий пример конфигурации системы, при которой система аутентификации пользователей сконструирована как сервер аутентификации согласно второму варианту осуществления настоящего изобретения.
[0026] Фиг. 12 является блок-схемой, показывающей конфигурацию программного обеспечения MFP и сервера аутентификации согласно второму варианту осуществления.
ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
[0027] Теперь, в дальнейшем в этом документе варианты осуществления настоящего изобретения будут описаны подробно, со ссылкой на прилагаемые чертежи. Следует понимать, что нижеследующие варианты осуществления не предназначены для ограничения пунктов формулы изобретения настоящего изобретения и не все комбинации аспектов, которые описаны согласно нижеследующим вариантам осуществления, обязательно требуются по отношению к средствам для решения проблем согласно настоящему изобретению.
[0028] Фиг. 1 изображает упрощенный вид, показывающий конфигурацию сети согласно первому варианту осуществления настоящего изобретения.
[0029] С сетью (LAN) 100 соединены MFP 101, который является примером устройства обработки информации согласно настоящему изобретению, и персональный компьютер (PC) 102. MFP 101 и PC 102 способны осуществлять связь друг с другом через LAN 100. Здесь, MFP 101 является многофункциональным периферийным устройством, снабженным множеством функций, таких как функции для сканирования, печати и осуществления связи.
[0030] Фиг. 2 является блок-схемой, показывающей конфигурацию аппаратных средств MFP 101 согласно первому варианту осуществления.
[0031] Блок 200 управления, включающий в себя CPU 201, управляет всеми операциями MFP 101. CPU 201 развертывает ОС (операционную систему), программы управления или подобные, которые установлены на HDD 204, в RAM 203 в соответствии с программой загрузки, хранящейся в ROM 202, и MFP 101 функционирует под управлением CPU 201, который исполняет программы. RAM 203 используется в качестве области временного хранения, такой как основная память, рабочая область или подобное, в CPU 201. HDD 204 хранит данные изображения, различные программы или подобное. Интерфейс 205 пульта управления соединяет пульт 209 управления и блок 200 управления. Пульт 209 управления снабжается блоком отображения, который функционирует как воспринимающая касания панель. Интерфейс 206 принтера соединяет блок 210 принтера и блок 200 управления. Данные изображения, которые должны быть напечатаны блоком 210 принтера, пересылаются из блока 200 управления на блок 210 принтера через интерфейс 206 принтера, и печатаются блоком 210 принтера на носителе записи, таком как лист. Интерфейс 207 сканера соединяет блок 211 сканера и блок 200 управления. Блок 211 сканера генерирует данные изображения посредством сканирования изображения на оригинале и подает данные изображения на блок 200 управления через интерфейс 207 сканера. Сетевой интерфейс 208 соединяет блок 200 управления (MFP 101) с LAN 100. Сетевой интерфейс 208 передает данные изображений, информацию или подобное, на внешнее устройство (например, веб-сервер, или подобное), соединенное с LAN 100, и принимает различную информацию от внешнего устройства в LAN 100.
[0032] Следует отметить, что так как PC 102 образован посредством конфигурации аппаратных средств универсального компьютера, которая в общем известна, объяснение конфигурации PC 102 опущено.
[0033] Фиг. 3 является блок-схемой для разъяснения конфигурации программного обеспечения MFP 101 и PC 102 и конфигурации данных, которыми программное обеспечение управляет согласно первому варианту осуществления. Следует отметить, что символы стрелок по Фиг. 3 представляют вызывающий модуль и цель вызова для функций в основных случаях использования. Ниже дано объяснение для функций программного обеспечения и данных, которыми управляет программное обеспечение.
[0034] Программное обеспечение MFP 101 хранится как программа на HDD 204 MFP 101, и функции, разъясненные ниже, реализуются этой программой, развернутой в RAM 203, и посредством CPU 201, исполняющим программу.
[0035] Локальный UI (пользовательский интерфейс) 301 отображает пользовательские интерфейсы, которыми оперирует пользователь, на пульте 209 управления и обеспечивает пользователя функциями, которые имеет MFP 101.
[0036] Фиг. 4A-4D изображают виды, показывающие примеры пользовательских интерфейсов, которые локальный UI 301 отображает на пульте 209 управления, согласно первому варианту осуществления.
[0037] Например, Фиг. 4A изображает вид, иллюстрирующий пример экрана аутентификации пользователей для аутентификации пользователя, который использует пульт 209 управления. Фиг. 4B представляет собой пример экрана изменения пароля для запроса, чтобы пользователь, который осуществил аутентификацию на экране аутентификации пользователей по Фиг. 4A, изменил пароль. Фиг. 4C представляет собой пример экрана меню, показывающего список функций, предоставляемый пользователю, который использует пульт 209 управления. Фиг. 4D представляет собой пример экрана пользовательского интерфейса для использования функции "окна" MFP 101. Например, пользователь имеет возможность сохранения данных изображения, полученных из блока 211 сканера, на HDD 204 как электронного документа посредством использования экрана пользовательского интерфейса по Фиг. 4D. Или пользователь имеет возможность печати электронного документа, полученного из HDD 204, с использованием блока 210 принтера.
[0038] PC 102 снабжается программным обеспечением, таким как веб-браузер 317, инструмент 319 управления файлами, инструмент 321 управления MFP или подобными.
[0039] Веб-браузер 317 снабжается функцией, в которой веб-браузер 317 осуществляет связь с HTTP-сервером 302 MFP 101 в качестве HTTP-клиента 318. HTTP-сервер 302 вызывает удаленный UI 303 после приема запроса от веб-браузера 317. Удаленный UI 303 предоставляет пользователю, эксплуатирующему веб-браузер 317, пользовательский интерфейс, заданный в HTML. HTTP-сервер 302 возвращает HTML-данные, полученные от удаленного UI 303, веб-браузеру 317 в качестве ответа на запрос от веб-браузера 317.
[0040] Инструмент 319 управления файлами снабжается функцией, в которой инструмент 319 управления файлами осуществляет связь с SMB/CIFS-сервером 304 MFP 101 в качестве SMB/CIFS-клиента 320. SMB/CIFS-сервер 304 снабжается процессором 305 NTLM-аутентификации для обработки протокола NTLM- (NT LAN Manager) аутентификации. SMB/CIFS-сервер 304 вызывает службу 306 управления документами, когда SMB/CIFS-сервер 304 принимает запрос, такой как запрос просмотра файла, сохранения файла или подобного, от инструмента 319 управления файлами. Служба 306 управления документами снабжается функциями для предоставления просмотра или обновления электронных документов (файлов, имеющих расширение файла, такое как PDF, JPEG, PNG, DOC или подобное), сохраненных на HDD 204, и выполнения сохранения новых файлов, или подобного.
[0041] Инструмент 321 управления MFP снабжается функцией для осуществления доступа к MIB 309, которой MFP 101 обеспечивается посредством осуществления доступа к SNMP-серверу 307 MFP 101 в качестве SNMP-клиента 322. SNMP-сервер 307 обеспечивается блоком 308 обработки USM-аутентификации для обработки протокола аутентификации пользователей, заданного посредством USM из SNMP версии 3. SNMP-сервер 307 обращается к данным, сохраненным в MIB 309, и выполняет настройки, когда SNMP-сервер 307 принимает запрос осуществления доступа от инструмента 321 управления MFP PC 102.
[0042] Система 310 аутентификации пользователей снабжается механизмом для аутентификации пользователя, который использует MFP 101. Ниже дано разъяснение деталей функций, которые имеет система 310 аутентификации пользователей.
[0043] Системе 310 аутентификации пользователей предоставляется UI 311 настроек для пользователя, который управляет MFP 101, для выполнения настройки, относящейся к аутентификации пользователей MFP 101. UI 311 настроек может быть сконфигурирован как пользовательский интерфейс, описанный в HTML, который пригоден для использования из веб-браузера 317 PC 102 аналогично удаленному UI 303.
[0044] Фиг. 5A-5F изображают виды для разъяснения пользовательских интерфейсов из UI 311 настроек.
[0045] Фиг. 5A представляет собой пример экрана меню. Когда любой из элементов, обозначенных номерами 502-505, указан на экране по Фиг. 5A, обработка переходит на экран для указанной функции. Настройка 502 аутентификации пользователей является пользовательским интерфейсом для задания функции аутентификации пользователей MFP 101 в состояние ВКЛ или ВЫКЛ. Когда настройка 502 аутентификации пользователей указана на экране по Фиг. 5A, обработка переходит на экран по Фиг. 5B. На экране по Фиг. 5B пользователь имеет возможность задания аутентификации пользователей в состояние ВКЛ или ВЫКЛ, и система 310 аутентификации пользователей сохраняет содержимое, которое задано здесь, как настройку 312 аутентификации на HDD 204. Каждый программный модуль имеет возможность обращения к настройке ВКЛ/ВЫКЛ аутентификации пользователей посредством осуществления доступа к настройке 312 аутентификации. В примере по Фиг. 5B, аутентификация пользователей задана в состояние ВКЛ (аутентификация пользователей включена).
[0046] Экран по Фиг. 5C отображается посредством управления 503 учетными записями пользователей, указываемого на экране по Фиг. 5A. На экране по Фиг. 5C пользователь имеет возможность регистрации и редактирования имени пользователя и полномочий пользователя. Экран по Фиг. 5D представляет собой пример экрана, который отображается, когда на экране по Фиг. 5C указывается "зарегистрироваться" или "редактировать". Пользователь имеет возможность выполнения регистрации, редактирования или подобного, учетной записи пользователя посредством экранов пользовательского интерфейса, показанных на Фиг. 5C и Фиг. 5D. Система 310 аутентификации пользователей управляет информацией, относящейся к учетной записи пользователя, зарегистрированного с использованием экрана по Фиг. 5D, посредством хранения информации в базе данных 313 пользователей на HDD 204. Имя пользователя "Alice" зарегистрировано как администратор на экране по Фиг. 5D, и также зарегистрирован пароль, соответствующий имени пользователя.
[0047] Фиг. 6 изображает вид, показывающий пример конфигурации данных базы данных 313 пользователей согласно первому варианту осуществления.
[0048] Здесь имя пользователя 601, пароль 602 и полномочия 603 зарегистрированы посредством экранов пользовательского интерфейса, показанных на Фиг. 5C и Фиг. 5D. Дата/время 604 последнего обновления пароля представляет собой данные и время, в которые пароль зарегистрирован или обновлен посредством экрана по Фиг. 5D.
[0049] Экран по Фиг. 5E отображается посредством настройки 504 политики паролей, указываемой на экране по Фиг. 5A. Фиг. 5E представляет собой пример экрана пользовательского интерфейса для задания политики, относящейся к паролям. Например, "нет периода действия", "30 дней" и "90 дней" могут быть выбраны в качестве периодов действия паролей. Также может быть выбрано, является ли допустимым/недопустимым "три буквы или более" (настройка, чтобы пароль принудительно составлял три буквы или более), "включая символ" (настройка для принудительного включения символа в пароль), или подобное, в качестве настроек для сложности пароля. Система 310 аутентификации пользователей сохраняет набор элементов посредством экрана по Фиг. 5E в качестве настроек 314 политики паролей на HDD 204.
[0050] Экран по Фиг. 5F отображен посредством управления 505 журналом аутентификации, указываемым на экране по Фиг. 5A. Фиг. 5F представляет собой экран пользовательского интерфейса для управления записями журнала результатов аутентификации. На Фиг. 5F возможно просматривать журналы 316 аутентификации, которые система 310 аутентификации пользователей записывает на HDD 204. На этом экране отображаются имя пользователя, режим аутентификации, дата и время, в которые выполнена аутентификация, и результат аутентификации (OK или NG (не удачно)), которые зарегистрированы в журналах 316 аутентификации.
[0051] Фиг. 7A-7C изображают виды, показывающие пользовательские интерфейсы API (интерфейсы программирования приложений), которыми система 310 аутентификации пользователей обеспечивается согласно первому варианту осуществления.
[0052] Посредством других программных модулей, вызывающих API 701 по Фиг. 7A, системе 310 аутентификации пользователей может быть выдан запрос аутентификации, запрашивающий аутентификацию пользователей. Система 310 аутентификации пользователей определяет функционирование API 701 посредством обращения к таблице 315 обработки аутентификации на основе информации от вызывающего модуля 702.
[0053] Фиг. 8 изображает вид, показывающий пример содержимого таблицы 315 обработки аутентификации согласно первому варианту осуществления.
[0054] Таблица 315 обработки аутентификации хранит комбинацию из информации 801 вызывающего модуля, присутствия или отсутствия функции 802 изменения пароля вызывающего модуля, режима 803 вычисления, типа 804 обработки аутентификации или подобного. В информации 801 вызывающего модуля регистрируется протокол связи вызывающего модуля, который изначально выдает запрос аутентификации. Присутствие или отсутствие функции 802 изменения пароля вызывающего модуля представляет, содержит ли программный модуль вызывающего модуля функцию изменения пароля. Например, так как для локального UI 301, который управляет интерфейсом с помощью пользователя, присутствие или отсутствие функции 802 изменения пароля вызывающего модуля имеет значение "существует", и существует функция для отображения экрана изменения пароля по Фиг. 4B на экране управления.
[0055] Между тем, для протокола связи, такого как HTTP, SMB/CIFS и SNMP v3, не задан протокол для изменения пароля. По этой причине HTTP-сервер 302, SMB/CIFS-сервер 304 и SNMP v3 сервер 307 не имеют функции для запроса изменения пароля. Режим 803 вычисления представляет собой алгоритмы вычисления, которые API 701 использует для преобразования из пароля в другое значение. "БЕЗ ОБРАБОТКИ" представляет собой использование пароля как есть, без обработки пароля. "MD4" представляет собой вычисление MD4- (алгоритм классификации сообщений 4) классификатора (хэш-значения) из пароля. "MD5" представляет собой вычисление MD5 (алгоритм классификации сообщений 5) классификатора (хэш-значения) из пароля. Режим 803 вычисления не ограничен алгоритмами "MD4", "MD5" или подобными и может быть любым видом режима вычисления, пока режим 803 вычисления является известным режимом вычисления, который реализует система 310 аутентификации пользователей. Например, в общем известны алгоритмы вычисления, такие как HMAC (хэширование с помощью ключей для кода аутентификации сообщений) (RFC 2104), SHA (алгоритм безопасного хэширования) или подобные. Может быть взята такая конфигурация, в которой система 310 аутентификации пользователей обеспечивается алгоритмом вычисления NTLM или USM из SNMP версии 3 в качестве режима вычисления. Тип 804 обработки аутентификации категоризирует функционирование API 701 либо на "осуществить верификацию", либо на "возврат значения вычисления". "Осуществить верификацию" представляет собой API 701, выполняющий операцию верификации значения, вычисленного из пароля, относительно данных 704 аутентификации, принятых от вызывающего модуля, и возвращения результата верификации. "Возврат значения вычисления" представляет собой API 701, выполняющий операцию вычисления из пароля другого значения для пароля с помощью алгоритма, указанного "режимом 803 вычисления", и возвращения вычисленного значения (выходных данных, показанных номером 705 по Фиг. 7A).
[0056] Далее ниже дано разъяснение смысла возвращаемых значений 706 на Фиг. 7A, которые возвращает API 701.
[0057] - SUCCESS
SUCCESS представляет, что обработка API 701 выполнена успешно. В случае, в котором типом 804 обработки аутентификации является "осуществить верификацию", SUCCESS представляет, что обработка аутентификации пользователей выполнена успешно. В случае, в котором типом 804 обработки аутентификации является "возврат значения вычисления", значение, вычисленное из пароля, сохраняется в выходных данных 705 на Фиг. 7A и возвращается.
[0058] - SUCCESS_NEED_PWD_CHANGE
SUCCESS_NEED_PWD_CHANGE представляет, что пользователю необходимо изменить пароль, так как, хотя обработка API 701 выполнена успешно, пароль не удовлетворяет политике паролей. В случае, когда есть функции изменения пароля вызывающего модуля, возвращается это значение.
[0059] - ERROR
ERROR представляет, что обработка API 701 приостановлена. В случае, в котором типом 804 обработки аутентификации является "осуществить верификацию", ERROR представляет, что обработка аутентификации пользователей дает сбой. В случае, когда типом 804 обработки аутентификации является "возврат значения вычисления", значение, вычисленное из пароля, не возвращается.
[0060] - ERROR_NEED_PWD_CHANGE
ERROR_NEED_PWD_CHANGE представляет, что так как пароль не удовлетворяет политике паролей, обработка API 701 приостановлена. В случае, когда нет функции изменения пароля вызывающего модуля, возвращается это значение.
[0061] Описание разъясненного выше API 701 является только одним примером, и настоящее изобретение не ограничено этим примером. Например, может быть взята конфигурация, чтобы получить от вызывающего API модуля порцию или всю информацию таблицы 315 обработки аутентификации, показанной на Фиг. 8. В случае, когда от вызывающего модуля получена только порция информации, берется конфигурация, чтобы из таблицы 315 обработки аутентификации получить только информацию, требуемую для определения функционирования API. Посредством конфигурирования так, что таблица 315 обработки аутентификации имеет возможность редактирования извне, становится возможным поддерживать гибкую модификацию или добавление программных модулей, которые использует API.
[0062] Другой пример API показан на Фиг. 7B. API по Фиг. 7B использует параметры 708 и делает возможным получение от вызывающего модуля всей информации таблицы 315 обработки аутентификации, которая показана на Фиг. 8. Таким образом, в случае, когда берется конфигурация, чтобы получить от вызывающего модуля всю информацию, системе 310 аутентификации пользователей необязательно обращаться к таблице 315 обработки аутентификации. Также необязательно ограничивать API обработки аутентификации до одного API, и для каждой комбинации обработки, предусмотренной заранее, может быть подготовлено множество API. В разъяснении ниже, разъяснение дано с помощью API 701, показанного на Фиг. 7A, используемого в качестве API для обработки аутентификации.
[0063] API по Фиг. 7C получает результат аутентификации пользователей, которую исполняет программный модуль, и осуществляет запись в журнал в журналах 316 аутентификации.
[0064] Фиг. 9 является схемой последовательности операций для описания функционирования системы 310 аутентификации пользователей, когда, в MFP 101, программный модуль вызывает API 701 по Фиг. 7A согласно первому варианту осуществления. Следует отметить, что программа, которая исполняет эту обработку, развертывается в RAM 203 при исполнении и исполняется под управлением CPU 201.
[0065] Эта обработка инициируется посредством вызываемого API 701 по Фиг. 7A, и система 310 аутентификации пользователей принимает запрос на обработку, относящуюся к аутентификации пользователей. Сперва, на этапе S901, система 310 аутентификации пользователей получает информацию вызывающего модуля 702 и имя пользователя 703 (идентификатор пользователя) из параметров API 701. Далее обработка переходит на этап S902, и система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации на основе информации вызывающего модуля 702, получает режим аутентификации (присутствие или отсутствие функции изменения пароля, режим вычисления, тип обработки аутентификации). Далее обработка переходит на этап S903, и система 310 аутентификации пользователей определяет, зарегистрировано ли имя пользователя, полученное на этапе S901, в базе данных 313 пользователей (Фиг. 6) или нет. В случае, когда имя пользователя зарегистрировано, получают пароль 602 и дату/время 604 последнего обновления пароля, зарегистрированные в связи с именем пользователя. Между тем, в случае, когда имя пользователя не зарегистрировано в базе данных 313 пользователей, и пароль не мог быть получен на этапе S903, система 310 аутентификации пользователей определяет сбой аутентификации на этапе S904, так как система 310 аутентификации пользователей не может получить пароль, и обработка переходит на этап S914. На этапе S914 система 310 аутентификации пользователей осуществляет запись в журнал сбоя аутентификации. Затем обработка переходит на этап S915, система 310 аутентификации пользователей возвращает ошибку (ERROR) вызывающему API 701 модулю, и обработка завершается.
[0066] Между тем, в случае, когда получение пароля выполнено успешно на этапе S904, обработка переходит на этап S905, и система 310 аутентификации пользователей, обращаясь к настройке 314 политики паролей, определяет, удовлетворяет ли полученный пароль периоду действия, настройке сложности или подобному, или нет. Здесь, в случае, когда период действия пароля истек, или сложность неудовлетворительна, обработка переходит на этап S906, и система 310 аутентификации пользователей также определяет присутствие или отсутствие функции изменения пароля вызывающего модуля. Здесь в случае, когда функция изменения пароля существует, обработка переходит на этап S907, и обработка продолжается. Однако в случае, когда определено, что функция изменения пароля не существует на этапе S906, обработка переходит на этап S914, и осуществляется запись в журнал сбоя аутентификации, и затем на этапе S915 ошибка (ERROR_NEED_PWD_CHANGE) возвращается вызывающему API 701 модулю, и обработка завершается.
[0067] В случае, когда, на этапе S905, система 310 аутентификации пользователей определяет, что полученный пароль удовлетворяет периоду действия и настройке сложности, или в случае, когда, на этапе S906, определено, что функция изменения пароля вызывающего модуля существует, обработка переходит на этап S907. На этапе S907 система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, подтверждает режим 803 вычисления, заданный для вызывающего модуля. В случае, когда здесь режим вычисления не является режимом "БЕЗ ОБРАБОТКИ" (например, в случае "MD4" или "MD5"), обработка переходит на этап S908, и выполняется обработка вычисления, на основе полученного пароля, в соответствии с режимом вычисления. Например, MD4-классификация или MD5-классификация вычисляется здесь в соответствии с алгоритмом MD4 или MD5. Здесь, обработка переходит на этап S909, и система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, подтверждает тип 804 обработки аутентификации, заданный для вызывающего модуля. Здесь, в случае, когда типом 804 обработки аутентификации является "возврат значения вычисления", обработка переходит на этап S910, система 310 аутентификации пользователей сохраняет вычисленное значение в выходных данных 705 и возвращает успешное выполнение обработки (SUCCESS), и обработка завершается. Также, в случае, когда проверка политики паролей на этапе S905 дает здесь сбой, что-нибудь возвращается на это событие (SUCCESS_NEED_PWD_CHANGE).
[0068] Между тем, в случае, когда система 310 аутентификации пользователей, на этапе S909, определяет, что типом 804 обработки аутентификации является "осуществить верификацию", обработка переходит на этап S911, и система 310 аутентификации пользователей осуществляет верификацию подлинности данных аутентификации 704 (Фиг. 7A) относительно значения, вычисленного на этапе S908. В случае, когда результатом верификации является то, что данные аутентификации 704 и вычисленное значение совпадают, обработка переходит на этап S912, система 310 аутентификации пользователей осуществляет запись в журнал успеха аутентификации, обработка переходит на этап S913, успешное выполнение обработки (SUCCESS) возвращается вызывающему API модулю, и обработка завершается. В этом случае, в случае, когда проверка политики паролей на этапе S905 имеет значение NG, что-нибудь возвращается на это событие (SUCCESS_NEED_PWD_CHANGE).
[0069] Между тем, в случае, когда определено, что результатом верификации на этапе S911 является то, что данные аутентификации 704 и вычисленное значение не совпадают, то определяется сбой аутентификации, обработка переходит на этап S914, и система 310 аутентификации пользователей осуществляет запись в журнал сбоя аутентификации. Затем, на этапе S915, вызывающему API модулю возвращается ошибка (ERROR), и обработка завершается.
[0070] Далее будет дано разъяснение для примера функционирования, когда аутентификация пользователей на MFP 101 задана в состояние ВКЛ, и различные программные модули исполняют аутентификацию пользователей с использованием системы 310 аутентификации пользователей. Здесь будет дано разъяснение для случая, в котором программными модулями являются локальный UI 301, HTTP-сервер 302, SMB/CIFS-сервер 304 и SNMP-сервер 307.
[0071] Фиг. 10A-10D изображают виды, показывающие взаимосвязи программных модулей, когда MFP 101 выполняет аутентификацию пользователей, вместе с потоком данных согласно первому варианту осуществления.
[0072] Фиг. 10A изображает вид для разъяснения случая, когда локальный UI 301 выполняет аутентификацию пользователей с использованием системы 310 аутентификации пользователей. На Фиг. 10A экран аутентификации пользователей отображается на экране управления, и аутентификация пользователей запрашивается для пользователя, использующего MFP 101. Локальный UI 301, на этапе S1001, получает имя пользователя и пароль, которые пользователь вводит на экране аутентификации пользователей по Фиг. 4A. Также, на этапе S1002, локальный UI 301 делает запрос на обработку аутентификации посредством прохождения имени пользователя и пароля в систему 310 аутентификации пользователей посредством API 701 по Фиг. 7A. При этом система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, выполняет проверку политики паролей, верификацию подлинности пароля и запись в журнал аутентификации, и на этапе S1003 отвечает локальному UI 301 результатом обработки.
[0073] Здесь локальный UI 301 отображает экран меню по Фиг. 4C, например, и разрешает пользователю использование функции MFP 101 в случае, когда результат является успешным (SUCCESS). С другой стороны, в случае, когда результатом аутентификации является NG (SUCCESS_NEED_PWD_CHANGE), экран изменения пароля по Фиг. 4B отображается на экране управления, так как проверка политики паролей имеет значение NG, и от пользователя запрашивается изменение пароля. Также, в случае, когда результатом аутентификации является ошибка (ERROR), отображается экран аутентификации пользователей по Фиг. 4A, и от пользователя запрашивают повторно ввести информацию аутентификации.
[0074] Далее будет дано разъяснение функционирования HTTP-сервера 302 MFP 101 со ссылкой на Фиг. 10B. Фиг. 10B изображает вид для разъяснения случая, когда HTTP-сервер 302 выполняет аутентификацию пользователей с использованием системы 310 аутентификации пользователей.
[0075] HTTP-сервер 302, на этапе S1004, принимает запрос получения HTML, включающий в себя аутентификацию HTTP-классификатора (RFC 2617), от веб-браузера 317. При этом HTTP-сервер 302 получает имя пользователя и MD5-классфикатор из пакета, и, на этапе S1005, делает запрос на обработку аутентификации к системе 310 аутентификации пользователей посредством API 701. При этом система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, выполняет проверку политики паролей и обработку верификации, осуществляющую верификацию относительно вычисления MD5-классификатора, выполняет запись в журнал аутентификации, и на этапе S1006 отвечает результатом аутентификации. HTTP-сервер 302, в случае, когда результат аутентификации является успешным (SUCCESS), передает запрос получения HTML удаленному UI 303 на этапе S1007. При этом удаленный UI 303 получает от HTTP-сервера 302 информацию о пользователе, который аутентифицирован, и выполняет предоставление HTML и управление доступом в соответствии с пользователем. Между тем, в случае, когда результатом является сбой (ERROR/ERROR_NEED_PWD_CHANGE), HTTP-сервер 302 осуществляет уведомление веб-браузера 317 об ошибке.
[0076] Далее будет дано разъяснение функционирования SMB/CIFS-сервера 304 MFP 101 со ссылкой на Фиг. 10C. Фиг. 10C изображает вид для разъяснения случая, когда SMB/CIFS-сервер 304 выполняет аутентификацию пользователей с использованием системы 310 аутентификации пользователей.
[0077] SMB/CIFS-сервер 304 принимает пакет, включающий в себя данные аутентификации в формате NTLM-данных от инструмента 319 управления файлами PC 102 на этапе S1008. При этом SMB/CIFS-сервер 304 получает имя пользователя из пакета и на этапе S1009 делает запрос на обработку аутентификации к системе 310 аутентификации пользователей посредством API 701. При этом система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, выполняет проверку политики паролей, и вычисление MD4-классификатора, и на этапе S1010 возвращает результат обработки вместе с MD4-классификатором. При этом, в SMB/CIFS-сервере 304, процессор 305 NTLM-аутентификации выполняет обработку NTLM-аутентификации с использованием MD4-классификатора, полученного от системы 310 аутентификации пользователей, и данные NTLM-аутентификации, полученные из пакета. Затем SMB/CIFS-сервер 304 получает результат аутентификации, произведенный процессором 305 NTLM-аутентификации, и на этапе S1011 имя пользователя и результат аутентификации сообщаются системе 310 аутентификации пользователей посредством API по Фиг. 1С.
[0078] В случае, когда аутентификация пользователя здесь выполнена успешно, после этого SMB/CIFS-сервер 304 разрешает доступ к службе 306 управления документами из инструмента 319 управления файлами из PC 102. Служба 306 управления документами получает пользовательскую информацию от SMB/CIFS-сервера 304 на этапе S1012 и выполняет предоставление услуг, управление доступом или подобное, в соответствии с пользователем. Между тем, в случае, когда аутентификация пользователя дает сбой, SMB/CIFS-сервер 304 сообщает ошибку инструменту 319 управления файлами из PC 102.
[0079] Далее будет дано разъяснение функционирования SNMP-сервера 307 MFP 101 со ссылкой на Фиг. 10D. Фиг. 10D изображает вид для разъяснения случая, когда SNMP-сервер 307 выполняет аутентификацию пользователей с использованием системы 310 аутентификации пользователей.
[0080] SNMP-сервер 307, на этапе S1013, принимает пакет, включающий в себя данные аутентификации в соответствии с USM (RFC3414) SNMP v3, от инструмента 321 управления MFP из PC 102. Затем SNMP-сервер 307 получает имя пользователя из этого пакета и делает запрос на обработку аутентификации к системе 310 аутентификации пользователей посредством API 701 на этапе S1014. При этом система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, выполняет проверку политики паролей и вычисление MD5-классификатора, и на этапе S1015 возвращает результат обработки вместе с MD5-классификатором. При этом, SNMP-сервер 307, блок 308 обработки USM-аутентификации выполняет обработку NTLM-аутентификации с использованием MD4-классификатора, полученного от системы 310 аутентификации пользователей, и данные NTLM-аутентификации, полученные из пакета. Затем SNMP-сервер 307 получает результат аутентификации блока 308 обработки USM-аутентификации, и на этапе S1016, осуществляет уведомление системы 310 аутентификации пользователей об имени пользователя и результате аутентификации посредством API по Фиг. 1С. В случае, когда аутентификация пользователей выполнена успешно, SNMP-сервер 307, на этапе S1017, выполняет доступ к MIB 309, которую запрашивает инструмент 321 управления MFP. SNMP-сервер 307 выполняет управление доступом для осуществления доступа к MIB 309 в соответствии с пользователем. Между тем, в случае, когда аутентификация пользователей дает сбой, SNMP-сервер 307 уведомляет инструмент 321 управления MFP из PC 102 об ошибке.
[0081] Посредством первого варианта осуществления, который разъяснен выше, так как механизм аутентификации пользователей MFP 101 реализован посредством единой системы 310 аутентификации пользователей, нагрузка управления настройками, относящимися к аутентификации пользователей, и нагрузка управления учетными записями пользователей могут быть уменьшены.
[0082] Также посредством первого варианта осуществления, так как политика обеспечения защиты паролей и функция печати журнала аутентификации предоставляются для всех путей доступа, возможно адаптировать эквивалентные функции обеспечения защиты ко всем путям доступа.
[0083] Также, программным модулям, которые используют систему 310 аутентификации пользователей MFP 101, не всегда обязательно поддерживать политику обеспечения защиты паролей, запись в журнал аутентификации или подобное, и таким образом есть преимущество, что не возникнут издержки реконструкции существующего программного модуля или исходного кода.
[0084] Кроме того, посредством первого варианта осуществления, для системы 310 аутентификации пользователей и программных модулей, которые используют систему 310 аутентификации пользователей, возможно выполнять распределенную обработку, относящуюся к аутентификации пользователей. По этой причине есть эффект, что возможно сконфигурировать устройство, в котором элементы управления, относящиеся к аутентификации пользователей, являются интегрированными, в то же время максимально используя существующие программные модули и исходный код.
[0085] [ВТОРОЙ ВАРИАНТ ОСУЩЕСТВЛЕНИЯ]
Описанная ранее система 310 аутентификации пользователей не всегда должна быть внутри MFP 101, и может быть взята конфигурация, такая, чтобы система 310 аутентификации пользователей являлась отдельным узлом в сети.
[0086] Фиг. 11 изображает вид, показывающий пример конфигурации системы, при которой система аутентификации пользователей сконструирована как сервер аутентификации согласно второму варианту осуществления настоящего изобретения.
[0087] Здесь, MFP 1101, PC 1102 и сервер 1103 аутентификации соединены посредством LAN 1100. Следует отметить, что, так как конфигурации аппаратных средств MFP 1101 и PC 1102 являются такими же, как и конфигурации аппаратных средств MFP 101 и PC 102 согласно описанному ранее первому варианту осуществления, их разъяснение будет опущено.
[0088] Фиг. 12 является блок-схемой, показывающей конфигурацию программного обеспечения MFP 1101 и сервера 1103 аутентификации согласно второму варианту осуществления. Так как конфигурация PC 1102 является такой же, как и конфигурация PC 102 описанного ранее первого варианта осуществления, разъяснение опущено. Следует отметить, что участки, общие для описанной ранее Фиг. 3, обозначены одинаковыми ссылочными номерами, и их разъяснение опущено. Также, так как средства, указанные ссылочными номерами 1211-1216 сервера 1103 аутентификации пользователей имеют те же функции, как и средства, обозначенные ссылочными номерами 311-316 по описанной ранее Фиг. 3, их разъяснение опущено.
[0089] MFP 1101 снабжается агентом 1201 для осуществления связи с сервером 1103 аутентификации. Сервер 1103 аутентификации снабжается системой аутентификации пользователей 1202. MFP 1101 и сервер 1103 аутентификации имеют возможность установки доверительного отношения посредством предварительного обмена секретными ключами шифрования, которые должны быть использованы для связи. Может осуществляться обмен сертификатами, которые выдала третья сторона, такими как сертификат клиента, сертификат сервера или подобными, использующими способ PKI.
[0090] Агент 1201 обеспечивается API (номер 701 на Фиг. 7A или Фиг. 7С или подобные), эквивалентным API, который имеет система 1202 аутентификации пользователей. Агент 1201 получает результат обработки посредством вызова API системы 1202 аутентификации пользователей посредством связи по сети, когда API вызывается из другого программного модуля. Так как здесь необходимо, чтобы информация, которая идет по сети, удерживалась в секрете, шифрование выполняется с использованием ключей, которыми обменялись заранее. Таким образом, посредством конфигурирования системы 1202 аутентификации пользователей так, чтобы была независимым узлом (сервером аутентификации) в сети, может быть предоставлена система 1202 аутентификации пользователей, пригодная для использования из множества MFP.
[0091] Как разъяснено выше, в соответствии с этим вариантом осуществления, могут быть получены нижеследующие эффекты.
[0092] - За счет того, что реализуемый механизм аутентификации пользователей делается в виде единой системы аутентификации пользователей, нагрузки управления настройками, относящимися к аутентификации пользователей, и управления учетными записями пользователей могут быть уменьшены.
[0093] - Возможно применять один и тот же механизм аутентификации пользователей ко всем путям доступа для устройства, использующего систему аутентификации пользователей.
[0094] - Возможно снова использовать существующие программные модули и исходный код, и может быть сконфигурировано устройство, которое может выполнить аутентификацию пользователей при сравнительно меньшем объеме работ и человеко-часов.
[0095] ДРУГИЕ ВАРИАНТЫ ОСУЩЕСТВЛЕНИЯ
Варианты осуществления настоящего изобретения могут быть также реализованы компьютером системы или устройства, который считывает и исполняет исполняемые компьютером инструкции, записанные на носителе информации (например, постоянном компьютерно-читаемом носителе информации) для выполнения функций одного или более из вышеописанных вариантов осуществления настоящего изобретения, и посредством способа, выполняемого компьютером системы или устройства посредством, например, считывания и исполнения исполняемых компьютером инструкций из носителя информации для выполнения одного или более из вышеописанных вариантов осуществления. Компьютер может содержать одно или более из центрального процессорного блока (CPU), микропроцессорного блока (MPU) или других интегральных схем и может включать в себя сеть из отдельных компьютеров или отдельные компьютерные процессоры. Исполняемые компьютером инструкции могут быть предоставлены компьютеру, например, из сети или носителя информации. Носитель информации может включать в себя, например, одно или более из жесткого диска, оперативной памяти (RAM), постоянной памяти (ROM), хранилища распределенных вычислительных систем, оптического диска (такого как компакт-диск (CD), универсальный цифровой диск (DVD) или диск Blu-ray (BD)TM), устройства флэш-памяти, карты памяти и подобного.
[0096] Хотя настоящее изобретение было описано со ссылкой на варианты осуществления, следует понимать, что данное изобретение не ограничено раскрытыми примерными вариантами осуществления. Объем следующей формулы изобретения должен соответствовать наиболее широкой интерпретации с тем, чтобы охватывать все такие модификации и эквивалентные структуры и функции.
Реферат
Изобретение относится к обработке информации. Технический результат - упрощение управления множеством пользовательских учетных записей для пользователя. Устройство обработки информации, содержащее: блок хранения пользовательской информации, сконфигурированный с возможностью хранения пароля, связанного с идентификатором пользователя; множество серверов, каждый из которых осуществляет связь с клиентами, используя отличные друг от друга протоколы связи; блок хранения информации аутентификации, выполненный с возможностью хранения типа обработки аутентификации для по меньшей мере одного из множества серверов; блок приема, сконфигурированный с возможностью приема запроса процесса аутентификации пользователя от одного из множества серверов как вызывающего модуля; первый блок получения, выполненный с возможностью получения типа обработки аутентификации для сервера как вызывающего модуля, хранимого в блоке хранения информации аутентификации; второй блок получения, выполненный с возможностью получения пароля, хранимого в блоке хранения пользовательской информации и связанного с идентификатором пользователя, полученным из запроса; блок аутентификации, выполненный с возможностью осуществления процесса аутентификации, используя пароль, полученный вторым блоком получения, в соответствии с типом обработки аутентификации сервера как вызывающего модуля, полученным первым блоком получения. 3 н. и 11 з.п. ф-лы, 12 ил.
