В данной статье расскажу, как мы перешли с NTLM на Kerberos авторизацию для приложений на Oracle Weblogic Server, тем самым упростив пользователям вход, убрав необходимость вводить пароль. Все пользователи, а также сервер приложения находятся в одном домене, так же ранее была настроена доменная авторизация для приложений Weblogic сервера. Все конфигурации были проверены на WLS 12.1.2.
Для начала немного теории, очень кратко для дальнейшего понимания процесса взаимодействия.
Что такое Single Sign-On?
Единый вход (SSO) — это механизм, посредством которого одно действие аутентификации пользователя, позволяет пользователю получить доступ ко всем компьютерам и системам, где у него есть разрешение на доступ, без необходимости вводить несколько паролей. Ранее введенные учетные данные будут прозрачно повторно использоваться различными компонентами.
Что такое Kerberos?
Kerberos — это протокол сетевой аутентификации, который был впервые разработан Технологическим институтом Массачусетса. Kerberos является безопасным методом аутентификации запроса на услугу в сети и предназначен для обеспечения надежной аутентификации для клиент-серверных приложений с использованием криптографии с секретным ключом.
Что такое SPNEGO?
SPNEGO — это простой и защищенный механизм переговоров GSSAPI. Это стандартизованный интерфейс для аутентификации (например, JNDI для поиска в каталогах), реализация по умолчанию для SPNEGO под Windows — это Kerberos (например, LDAP для JNDI). В терминологии Microsoft в качестве синонима SPNEGO используется «Интегрированная аутентификация Windows». В Windows Integrated Authentication могут быть согласованы протоколы Kerberos или NTLM.
Когда сервер получает запрос от браузера Internet Explorer (IE 6.1 или выше), он может запросить, чтобы браузер использовал протокол SPNEGO для аутентификации. Этот протокол выполняет аутентификацию Kerberos через HTTP и позволяет Internet Explorer передавать делегированные полномочия, чтобы веб-приложение могло выполнять вход в последующие Kerberized службы от имени пользователя.
Когда HTTP-сервер хочет выполнить SPNEGO, он возвращает ответ «401 Unauthorized» на HTTP-запрос с заголовком «WWW-Authorization: Negotiate». Затем Internet Explorer связывается с службой выдачи билетов (TGS) для получения билета. Он выбирает специальное имя участника услуги для запроса билета, например:
HTTP/webserver@<DOMAIN NAME>Возвращенный билет затем завернут в токен SPNEGO, который закодирован и отправляется обратно на сервер с использованием HTTP-запроса. Маркер разворачивается, и билет аутентифицируется.
Преимущества Kerberos
Использование керберос дает возможность администраторам отключить проверку подлинности NTLM, как только все сетевые клиенты смогут аутентифицировать Kerberos. Протокол Kerberos более гибкий и эффективный, чем NTLM, и более безопасный.
Настройка SSO на основе Kerberos в среде сервера приложений Weblogic
Схема взаимодействия:
- Когда зарегистрированный пользователь (РС) запрашивает ресурс из Oracle WebLogic Server (WLS), он отправляет исходный HTTP GET-запрос.
- Сервер Oracle WebLogic Server (WLS), выполняющий код обработчика токенов SPNEGO, требует аутентификации и выдает ответ 401 Access Denied, WWWAuthenticate: Negotiate.
- Клиент (Браузер на PC) запрашивает билет сессии из TGS / KDC (AD).
- TGS / KDC (AD) предоставляет клиенту необходимый билет Kerberos (при условии, что клиент авторизован), завернутый в токен SPNEGO.
- Клиент повторно отправляет запрос HTTP GET + токен Negotiate SPNEGO в заголовке авторизации: Negotiate base64 (token).
- Проверка веб-аутентификации SPNEGO на сервере Weblogic видит заголовок HTTP с токеном SPNEGO. SPNEGO проверяет токен SPNEGO и получает информацию о пользователе.
- После того, как Weblogic получит информацию о пользователе, он проверяет пользователя в Microsoft Active Directory / KDC. Когда процесс идентификации выполняется, Weblogic выполняет соответствующий Java-код (сервлеты, JSP, EJB и т.д.) И проверяет авторизацию.
- Код обработчика Token Handler сервера Oracle WebLogic Server принимает и обрабатывает токен через API GSS, аутентифицирует пользователя и отвечает запрошенным URL-адресом.
Теперь перейдем к практике
1. Выполняем настройки на стороне сервера домен контролера, на котором настроены службы TGS / KDC.
- Создаем пользователя в Active Directory (срок действия пароля должен быть не ограничен)
- Устанавливаем соответствующий SPN для имени сервера WLS
Выполняем проверку, установленного SPN
setspn –l HTTP_weblogic
должно вернуть две записи
Сгенерировать Keytab файл
ktpass -princ HTTP_weblogic@mycompany.com -pass PASSWORD -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:krb5.keytab Скопировать данный файл на сервер WLS
2. Настройка сервера WLS
- Нужно создать файл krb5.ini в папке %windir%: C:Windows. Этот файл содержит параметры конфигурации для клиентов, например, где находится KDC. Файл будет выглядеть так:
[libdefaults]
default_realm = <DOMAIN NAME>
ticket_lifetime = 600
[realms]
<DOMAIN NAME> = {
kdc = <HOSTNAME OF AD/KDC>
admin_server = <HOSTNAME OF AD/KDC>
default_domain = <DOMAIN NAME>
}
[domain_realm]
. <DOMAIN NAME>= <DOMAIN NAME>
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true- Создать конфигурационный файл krb5Login.conf:
com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal="user@MYCOMPANY.COM" useKeyTab=true
keyTab=krb5.keytab storeKey=true debug=true;
};
com.sun.security.jgss.krb5.accept {
com.sun.security.auth.module.Krb5LoginModule required
principal="user@MYCOMPANY.COM" useKeyTab=true
keyTab=krb5.keytab storeKey=true debug=true;
};Обратите внимание, что имя домена должно быть указано в верхнем регистре. Для более ранних версий, используйте com.sun.security.jgss.initiate в предыдущем конфиге вместо com.sun.security.jgss.krb5.initiate.
- Оба файла krb5Login.conf и krb5.keytab должны быть размещены в корне директории домена WLS сервера.
- Редактируем файл setDomainEnv
Находим строку set JAVA_OPTIONS=%JAVA_OPTIONS% и в конце добавляем
-Djava.security.auth.login.config=<путь к файл>krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true
- В данном случае не рассматриваем настройку авторизации WLS в AD считаем, что она работает, если нужно расписать этот пункт пишите в комментариях.
- Настраиваем SPNEGO в WLS
Для этого необходимо перейти в WebLogic Server Administration Console
Переходим в раздел Security Realms >myrealm >Providers и нажимаем кнопку Add
Выбираем тип “WebLogic Negotiate Identity Assertion provider”
Проверяем, что бы было выбрано оба параметра.
Нажимаем кнопку Reorder и управляя стрелками выставляем последовательности типов авторизации. На первом месте должно быть установлено WebLogic Negotiate Identity Assertion provider на втором месте Provider that performs LDAP authentication (доменная авторизация)
- Перезагружаем сервер
- Далее необходимо указать приложению способ авторизации CLIENT-CERT, данные изменения применяются в файле web.xml приложения
<security-constraint>
<display-name>Security Constraint for SSO </display-name>
<web-resource-collection>
<web-resource-name>My webapp</web-resource-name>
<description>Group of Users</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>valid-users</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
<description>Role description</description>
<role-name>valid-users</role-name>
</security-role>Роль должна быть предустановлена в системе. В нашем случае используется встроенная роль для ADF (valid-users), а уже далее на основании доменных групп раздаются полномочия.
- Debug
Для выявления проблем с авторизацией необходимо включить дебаг. Для этого переходим в раздел.
Environment -> Servers выбираем наш сервер -> Debug -> weblogic (развернуть) -> Security -> atn, установить галочки и включить.
Для включения и отключения дебага, перезагрузка не требуется.
- Перезагружаем сервер, для применения изменений в конфигурации.
- Деплоим приложение с измененным способом авторизации (новым web.xml)
- Чтобы отключить данный вид авторизации для административной консоли необходимо внести следующие изменения %Ora_Home%wlserverserverlibconsoleappwebappWEB-INFweb.xml.
Меняем строку
<auth-method>CLIENT-CERT,FORM</auth-method> на <auth-method>FORM</auth-method>
Логинимся на доменную машину, переходим по ссылке приложения и авторизуемся без ввода пароля. Стоит отметить, что кнопка Выход, в приложении работать не будет в данной конфигурации.
Автор: system-admins
