ПО на javascript(HTML) и авторизация на уровне OS

Здравствуйте!
Поставлена задача - "Требуется разработать программное обеспечение на javascript(HTML), которое использует источник данных JSON(или XML) по протоколу HTTP(HTTPS) с сервера СУБД Oracle. При этом требуется обеспечить авторизацию Ораклом пользователя запустившего приложение (JS) на уровне операционной системы(пользователь AD)."

Я администратор бд Оracle, в бд настроена аутентификация на уровне операционной системы. Проинсталлирована только бд (11 версия).
Подскажите, пожалуйста, что необходимо еще проинсталлировать для решения этой задачи.

Спасибо!

Анна96321,

На HTTP сервере и в браузере нужно настроить Kerberos аутентификацию.

JSON, сводится к HTTP запросам. Вот в процессе HTTP запроса HTTP сервер и браузер выполняют аутентификацию пользователя. В частности, если для сайта в браузере разрешена интегрированная аутентификация Windows, браузер по запросу HTTP сервера может взять билет Kerberos из WinLogon и передать его в HTTP сервер.

Perl'ун, спасибо!
Я хотела бы еще задать пару вопросов (сорри, мб наивных).

HTTP сервер - это Oracle HTTP сервер, который необходимо проинсталлировать? или чтото другое?

Анна96321
Perl'ун, спасибо! Я хотела бы еще задать пару вопросов (сорри, мб наивных). HTTP сервер - это Oracle HTTP сервер, который необходимо проинсталлировать? или чтото другое?

Если у вас нет особых требований к HTTP серверу, то "Oracle HTTP сервер" это то что вам нужно. Фактически, это Apache.

У меня Oracle HTTP сервер и приложения на APEX и на PL/SQL процедурах.

В состав Oracle HTTP сервера входит модуль mod_plsql который обеспечивает вызов PL/SQL процедур (как самодельных так и процедур движка APEX) непосредственно из Apache без промежуточных CGI скриптов и т.п..

Однако, есть море возможностей из HTTP сервера выполнять запросы к БД Orcale.

Как определитесь с системным ПО, можно будет говорить о настройках.

В Apache устанавливается модуль mod_auth_kerb.

В файле dads.conf добваляем параметры:

SetHandler pls_handler
PlsqlAuthenticationMode Basic
PlsqlDatabaseUsername <bla-bla-bla>
PlsqlDatabasePassword <bla-bla-bla>

AuthType Kerberos
AuthName "Enter AD Credentials"
KrbMethodNegotiate on
KrbServiceName host/my_server.company.ru@RU.RU
Krb5KeyTab /etc/krb5.keytab
KrbDelegateBasic off
KrbMethodK5Passwd off
KrbAuthRealms RU.RU
Require valid-user

Модуль mod_auth_kerb создает CGI переменную REMOTE_USER в которую заносит имя пользователя AD. PL/SQL процедура проверяет, что пользователь имеет полномочия выполнять запрошенное действие и выполняет его.

Если браузер пользователя не отдает билет Kerberos, HTTP сервер возвращает статус 401. К Oracle запрос не проходит.

Включение сервера в домен и настройка Kerberos это отдельная песня не для форума Oracle. Главное помните, что Kerberos чувствителен к регистру, "Perl@AD" и "PERL@AD" для него разные имена!

Я правильно понимаю, что в результате каждый пользователь подсоединиться к базе данных под своим именем и получит доступ соответственно своим правам в базе данных? или в базе данных все будут работать под одним именем и разделение прав надо делать на уровне приложения? Мне обязательно нужен первый вариант.

Вопрос возник потому как вижу строки

Perl'ун
В Apache устанавливается модуль mod_auth_kerb. В файле dads.conf добваляем параметры: ... PlsqlDatabaseUsername <bla-bla-bla> PlsqlDatabasePassword <bla-bla-bla> ...

Спасибо

Анна96321,

да. если имя и пароль указаны:

PlsqlDatabaseUsername APEX_USER
PlsqlDatabasePassword some_secret_password142

то mod_plsql логинится в БД с этим именем (в данном случае APEX_USER) и с привилегиями и ролями этого APEX_USER. далее приложение проверяет полномочия и предоставляет доступ. У меня полномочия предоставляются в зависимости от принадлежности группам AD.
если вы планируете создавать новое Web приложение БД, то это простой хороший вариант.

==========================

Если требуется создавать сессию в БД от имени пользователя OS. То в общем это тоже возможно.

В базе данных создал пользователя PU с паролем пароль_PU. Схемам предоставлены привилегии выполнять логин через PROXY USER PU.

В Apache создал proxy Location (frontend), закрыл его Kerberos, допилил модуль mod_auth_kerb, чтобы он в HTTP запрос совал стандартный заголовок Basic аутентификации (точнее модуль создает CGI переменную, а директивы Apache суют её значение в заголовок HTTP запроса к backend Location). Заголовок Basic аутентификации содержит <Имя пользователя AD>[PU]:пароль_PU и все это base64 кодируется.
Тут жирная строка читается буквально - PU в квадратных скобках после имени пользователя AD и через двоеточие пароль пользователя PU.

Как это работает.
Запрос frontend Location проверяется Kerberos и транслируется в запрос к backend Location (там нет Kerberos) где живет mod_plsql, но уже с эмуляцией Basic аутентификации в заголовке HTTP запроса (вместо Kerberos).

mod_plsql из заголовка HTTP запроса ловит имя и пароль, логинится в БД с паролем PU но с привилегиями пользователя AD. Функция USER так же возвращает имя пользователя AD.
Таким образом, мы не зная пароля пользователя AD можем подключиться к БД от его имени. Естественно, пароль PU нужно держать в секрете и вообще ограничить возможность логина через proxy пользователя только HTTP сервером.

Еще нужно добавить в backend Location проверку, что запрос пришел не из вне, а с самого Apache. Я это сделал с помощью некоего подобия подписи.

В приложениях следует учитывать наличие proxy. Например, не следует явно использовать номер порта, имя хоста и т.п. поскольку снаружи их не видно.