Программирование >>  Oracle 

1 ... 353 354 355 [ 356 ] 357 358 359 ... 469



Многоуровневая аутентификация

Многоуровневой (n-tier), или промежуточной, аутентификацией называется регистрация программного обеспечения промежуточного уровня от своего имени для выполнения в базе данных каких-либо действий по поручению пользователя. Это позволяет создавать промежуточные приложения, использующие собственную схему аутентификации, например, с помощью сертификатов X509 или другого процесса однократной регистрации и регистрироваться от имени пользователя, не зная его пароля в базе данных. Хотя регистрация выполнена не от имени пользователя, а от имени промежуточного ПО, для базы данных он зарегистрирован.

В этой главе мы рассмотрим многоуровневую аутентификацию и использование этой новой возможности Oracle 8i в приложениях. В частности:

будут представлены возможности и рассмотрено их использование в приложениях;

разработана программа на основе средств библиотеки OCI, которая позволит ис-

пользовать промежуточную аутентификацию для регистрации в базе данных;

описан оператор ALTER USER, позволяющий использовать промежуточную аутентификацию в базе данных;

рассмотрена возможность отслеживания действий, выполняемых от имени про-

межуточной учетной записи.



1490

Глава 22

В версии Oracle 8i многоуровневую аутентификацию можно использовать только в программах на основе библиотеки Oracle Call interface (OCI), написанных на языках С или С + + . В Oracle 9i многоуровневая аутентификация будет поддерживаться также интерфейсом JDBC, что существенно расширит ее возможности.

Когда использовать многоуровневую аутентификацию?

Во времена централизованных и клиент-серверных систем аутентификация была простой. Клиент (приложение) запрашивал у пользователя реквизиты (имя пользователя и пароль) и передавал их серверу базы данных. Сервер проверял эти реквизиты и, если все было правильно, клиент подключался к серверу:


Теперь у нас есть Web и, как следствие, многоуровневая архитектура, когда, например, клиент (браузер) предоставляет свои реквизиты промежуточному серверу приложений, на котором выполняются компоненты JavaServer Page (JSP), обращающиеся к CORBA-объекту, который, в свою очередь, взаимодействует с базой данных. Реквизиты, передаваемые ПО промежуточного уровня, могут совпадать или не совпадать с именем пользователя и паролем, использовавшимся во времена клиент-серверной архитектуры, - это могут быть реквизиты, разрешающие доступ к службе каталогов (directory service), чтобы ПО промежуточного уровня могло выяснить, кто подключается и какими привилегиями доступа. Это могут быть реквизиты в виде сертификата X.509, включающего идентификационную информацию и привилегии. В любом случае ПО промежуточного уровня необязательно использует эти реквизиты для регистрации пользователя в базе данных.

Клиент больше не взаимодействует с базой данных непосредственно; между ними есть один, два или более промежуточных уровней. Можно, правда, заставить пользователя передавать регистрационное имя и пароль компонентам JSP, которые будут передавать их CORBA-объекту, а тот - серверу базы данных, но это не позволит использовать другие технологии и механизмы аутентификации, в особенности механизмы однократной регистрации.

Рассмотрим следующий пример - достаточно типичное современное Web-приложение:



Многоуровневая аутентификация

1491


Клиент представляет собой Web-браузер, отображающий HTML-страницы и обращающийся к Web-серверу/серверу приложений по протоколу HTTP (1). Само приложение находится на Web-сервере/сервере приложений, например, в виде Java-сервлета, модуля сервера Apache и т.д. На представленной выше схеме промежуточный сервер использует службу каталогов (directory service), доступную по протоколу LDAP, которой и передаются предоставленные пользователем реквизиты (2). Служба каталогов используется как средство аутентификации сеанса браузера. Если аутентификация прошла успешно, сервер приложений получает соответствующее уведомление (3) и, наконец, подключается к одной из нескольких баз данных (4) для получения данных и обработки транзакций.

Реквизиты , передаваемые из браузера серверу приложений на шаге (1), могут быть разного вида - имя пользователя/пароль, ключ с сервера однократной регистрации, некий цифровой сертификат - все; что угодно. Имя пользователя базы данных и его пароль, как правило, не передается.

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

база данных ошибок, в которой надо регистрироваться, скажем, как TKYTE;

база данных затрат, в которой надо регистрироваться как TKYTE US;

база данных планировщика, в которой надо регистрироваться как WEBSTKTE;

и так далее...

Подумайте: сколько у вас имен пользователей и паролей в разных базах данных? Я могу вспомнить не меньше 15. Более того, хотя имена пользователей в базах данных я никогда не меняю, пароли изменяются достаточно часто. Правда, хорошо б1ло бы аутен-



1 ... 353 354 355 [ 356 ] 357 358 359 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика