Security (безопасность)
Часть 2 - Механизм идентификации
1. HTTP Basic authentication (Базовая HTTP идентификация)
2. HTTP Digest authentication (Дайджест HTTP идентификация)
3. HTTPS Client authentication (HTTPS идентификация)
4. HTTP FORM-based authentication (HTTP идентификация базирующаяся на формах)
5. Определение механизма идентификации для веб-приложений.
1. HTTP Basic authentication (Базовая HTTP идентификация)
Базовая HTTP идентификация, определённая в HTTP 1.1, является простейшим типом идентификации.
Последовательность событий выглядит так:
1) Браузер делает HTTP запрос:
GET /servlet/SalesServlet HTTP/1.1
2) Сервер возвращает HTTP ответ с кодом 401 Unauthorized и HTTP заголовком который говорит, что используется базовая идентификация. Так же указывается контекст именуемый realm.
HTTP/1.1 401 Unauthorized
Server: Tomcat/5.0.25
WWW-Authenticate: Basic realm="sales"
Content-Length=500
Content-Type=text/html
<html>
…detailed message
</html>
3) После получения такого ответа браузер открывает диалоговое окно и предлагает ввести логин\пароль.
4) После ввода и нажатия кнопки "OK" браузер делает HTTP запрос вида:
GET /servlet/SalesServlet HTTP/1.1
Authorization: Basic am9objpqamo=
Где am9objpqamo= это логин\пароль закодированный в Base64 кодировке. В данном случае здесь записано john:jjj. (Не стоит путать понятия закодированные и зашифрованные данные. Запись "am9objpqamo=" можно легко декодировать при помощи классов sun.misc.Base64Encoder и sun.misc.Base64Decoder).
ПЛЮСЫ:
- Прост в использовании
- Кросбраузеность
МИНУСЫ
- Небезопасный, так как не используется шифрование
- Вид диалогового окна зависит от браузера и не кастамизируется
2. HTTP Digest authentication (Дайджест HTTP идентификация)
Очень похож на базовую HTTP идентификацию, за исключением того, что пароль зашифрован.
ПЛЮСЫ:
- Безопаснее базовой HTTP идентификации
МИНУСЫ:
- НЕ поддерживается большинством браузеров (вообще говоря только некоторые версии IE поддерживают этот вид идентификации)
- НЕ поддерживается многими видами контейнеров, так как спецификация не поддерживает его.
3. HTTPS Client authentication (HTTPS идентификация)
HTTPS - HTTP через SSL(Secure Socket Layer).SSL протокол был разработан Netscape чтоб обеспечить безопасность работы в Internet. Обобщенно это выглядит следующим образом: прежде чем передать какую-либо информацию устанавливается SSL соединение между сервером и браузером и вся последующая информация передаётся в зашифрованном виде. Используется шифрование с публичными ключами.
ПЛЮСЫ:
- это самый безопасный метод идентификации из 4-х
- все основные браузеры поддерживают HTTPS
МИНУСЫ:
- для обеспечения SSL канала необходим сертификат, такой как VeriSign
- трудоёмкое в реализации и поддержке
4. HTTP FORM-based authentication (HTTP идентификация базирующаяся на формах)
Этот метод идентификации схож с базовой HTTP идентификацией, за исключением того, то используется HTTP FORM для получения логина и пароля. Реализуется достаточно просто: разработчик должен предоставить HTTP страницу с помещенным на неё FORM элементом. FORM должна иметь action атрибут равным j_security_check, атрибут method равным POST и 2 поля ввода j_username И j_password. Всё остальное кастаимзируется.
Пример:
<html>
<body>
<h4>Please login:</h4>
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" value="OK">
</form>
</body>
</html>
ПЛЮСЫ:
- метод прост в реализации
- все браузеры поддерживают этот метод идентификации
- вид страницы легко кастамизируется
МИНУСЫ:
- этот метод небезопасный, так как логин\пароль не зашифрованы
- используется когда сессия поддерживает куки или HTTPS
5. Определение механизма идентификации для веб-приложений.
Механизмы идентификации определены в дескрипторе поставки web.xml, однако прежде мы должны определить пользователей, пароли и роли пользователей. Реализация этого этапа зависит от контейнера. В Tomcat это сделать просто:
Определение пользователей в Tomcat
Пользователи а томкете хранятся в <tomcat-root>\conf\tomcat-users.xml, который изначально выглядит +\- так:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
</tomcat-users>
после нашего вмешательства файл выглядит следующим образом:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
<user name="petya" password="ppp" roles="employee" />
<user name="vasya" password="vvv" roles="employee" />
<user name="inokentiy sergeevich" password="iii" roles="employee, supervisor" />
</tomcat-users>
Итак, что изменилось. Было добавлено 3 пользователя: petya, vasya и inokentiy sergeevich с паролями соответственно ppp vvv и iii. Помимо пользователей добавлены 2 роли employee И supervisor. Концепция ролей очень важна в реальном мире, так как пользователей у системы может быть масса (от супер-начальников до обычных гостей) а роли позволяют ограничить доступ к той или иной информации. Так-же стоит заметить что любому пользователю можно назначить более одной роли.
Определение метода идентификации
Определение, какой же метод идентификации будет выбран происходит в дескрипторе поставки web.xml с помощью элемента <login-config>, который определяется следующим образом:
<!ELEMENT login-config (auth-method?, realm-name?, form-loginconfig?)>
Рассмотрим подэлементы:
<auth-method> определяет какой метод идентификации будет использован: BASIC, DIGEST, CLIENT-CERT или FORM
<realm-name> определяет realm (realm это контекст идентификации, его значение показывается в диалоговом окне при базовой идентификации и служит для упорядочивания управления доступом к ресурсам и подсказывает пользователю какой логин\пароль следует использовать в данной ситуации).
<form-login-config> определяет URL-ы для страницы идентификации и страницы ошибки. Используется в паре с auth-method равным FORM, в иных случаях просто игнорируется.
ПРИМЕРЫ:
Базовая идентификация:
<web-app>
...
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>sales</realm-name>
</login-config>
...
<web-app>
Идентификация с помощью форм:
<web-app>
...
<login-config>
<auth-method>FORM</auth-method>
<!--realm-name not required for FORM based authentication -->
<form-login-config>
<form-login-page>/formlogin.html</form-login-page>
<form-error-page>/formerror.html</form-error-page>
</form-login-config>
</login-config>
...
<web-app>
где formlogin.html И formerror.html соответственно страница идентификации и страница ошибки идентификации.
formlogin.html была приведена ранее и выглядит следующим образом:
<html>
<body>
<h4>Please login:</h4>
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" value="OK">
</form>
</body>
</html>
а formerror.html может выглядеть:
<html>
<body>
<h4>Sorry, your username and password do not match.</h4>
</body>
</html>
Часть 2 - Механизм идентификации
1. HTTP Basic authentication (Базовая HTTP идентификация)
2. HTTP Digest authentication (Дайджест HTTP идентификация)
3. HTTPS Client authentication (HTTPS идентификация)
4. HTTP FORM-based authentication (HTTP идентификация базирующаяся на формах)
5. Определение механизма идентификации для веб-приложений.
1. HTTP Basic authentication (Базовая HTTP идентификация)
Базовая HTTP идентификация, определённая в HTTP 1.1, является простейшим типом идентификации.
Последовательность событий выглядит так:
1) Браузер делает HTTP запрос:
GET /servlet/SalesServlet HTTP/1.1
2) Сервер возвращает HTTP ответ с кодом 401 Unauthorized и HTTP заголовком который говорит, что используется базовая идентификация. Так же указывается контекст именуемый realm.
HTTP/1.1 401 Unauthorized
Server: Tomcat/5.0.25
WWW-Authenticate: Basic realm="sales"
Content-Length=500
Content-Type=text/html
<html>
…detailed message
</html>
3) После получения такого ответа браузер открывает диалоговое окно и предлагает ввести логин\пароль.
4) После ввода и нажатия кнопки "OK" браузер делает HTTP запрос вида:
GET /servlet/SalesServlet HTTP/1.1
Authorization: Basic am9objpqamo=
Где am9objpqamo= это логин\пароль закодированный в Base64 кодировке. В данном случае здесь записано john:jjj. (Не стоит путать понятия закодированные и зашифрованные данные. Запись "am9objpqamo=" можно легко декодировать при помощи классов sun.misc.Base64Encoder и sun.misc.Base64Decoder).
ПЛЮСЫ:
- Прост в использовании
- Кросбраузеность
МИНУСЫ
- Небезопасный, так как не используется шифрование
- Вид диалогового окна зависит от браузера и не кастамизируется
2. HTTP Digest authentication (Дайджест HTTP идентификация)
Очень похож на базовую HTTP идентификацию, за исключением того, что пароль зашифрован.
ПЛЮСЫ:
- Безопаснее базовой HTTP идентификации
МИНУСЫ:
- НЕ поддерживается большинством браузеров (вообще говоря только некоторые версии IE поддерживают этот вид идентификации)
- НЕ поддерживается многими видами контейнеров, так как спецификация не поддерживает его.
3. HTTPS Client authentication (HTTPS идентификация)
HTTPS - HTTP через SSL(Secure Socket Layer).SSL протокол был разработан Netscape чтоб обеспечить безопасность работы в Internet. Обобщенно это выглядит следующим образом: прежде чем передать какую-либо информацию устанавливается SSL соединение между сервером и браузером и вся последующая информация передаётся в зашифрованном виде. Используется шифрование с публичными ключами.
ПЛЮСЫ:
- это самый безопасный метод идентификации из 4-х
- все основные браузеры поддерживают HTTPS
МИНУСЫ:
- для обеспечения SSL канала необходим сертификат, такой как VeriSign
- трудоёмкое в реализации и поддержке
4. HTTP FORM-based authentication (HTTP идентификация базирующаяся на формах)
Этот метод идентификации схож с базовой HTTP идентификацией, за исключением того, то используется HTTP FORM для получения логина и пароля. Реализуется достаточно просто: разработчик должен предоставить HTTP страницу с помещенным на неё FORM элементом. FORM должна иметь action атрибут равным j_security_check, атрибут method равным POST и 2 поля ввода j_username И j_password. Всё остальное кастаимзируется.
Пример:
<html>
<body>
<h4>Please login:</h4>
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" value="OK">
</form>
</body>
</html>
ПЛЮСЫ:
- метод прост в реализации
- все браузеры поддерживают этот метод идентификации
- вид страницы легко кастамизируется
МИНУСЫ:
- этот метод небезопасный, так как логин\пароль не зашифрованы
- используется когда сессия поддерживает куки или HTTPS
5. Определение механизма идентификации для веб-приложений.
Механизмы идентификации определены в дескрипторе поставки web.xml, однако прежде мы должны определить пользователей, пароли и роли пользователей. Реализация этого этапа зависит от контейнера. В Tomcat это сделать просто:
Определение пользователей в Tomcat
Пользователи а томкете хранятся в <tomcat-root>\conf\tomcat-users.xml, который изначально выглядит +\- так:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
</tomcat-users>
после нашего вмешательства файл выглядит следующим образом:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
<user name="petya" password="ppp" roles="employee" />
<user name="vasya" password="vvv" roles="employee" />
<user name="inokentiy sergeevich" password="iii" roles="employee, supervisor" />
</tomcat-users>
Итак, что изменилось. Было добавлено 3 пользователя: petya, vasya и inokentiy sergeevich с паролями соответственно ppp vvv и iii. Помимо пользователей добавлены 2 роли employee И supervisor. Концепция ролей очень важна в реальном мире, так как пользователей у системы может быть масса (от супер-начальников до обычных гостей) а роли позволяют ограничить доступ к той или иной информации. Так-же стоит заметить что любому пользователю можно назначить более одной роли.
Определение метода идентификации
Определение, какой же метод идентификации будет выбран происходит в дескрипторе поставки web.xml с помощью элемента <login-config>, который определяется следующим образом:
<!ELEMENT login-config (auth-method?, realm-name?, form-loginconfig?)>
Рассмотрим подэлементы:
<auth-method> определяет какой метод идентификации будет использован: BASIC, DIGEST, CLIENT-CERT или FORM
<realm-name> определяет realm (realm это контекст идентификации, его значение показывается в диалоговом окне при базовой идентификации и служит для упорядочивания управления доступом к ресурсам и подсказывает пользователю какой логин\пароль следует использовать в данной ситуации).
<form-login-config> определяет URL-ы для страницы идентификации и страницы ошибки. Используется в паре с auth-method равным FORM, в иных случаях просто игнорируется.
ПРИМЕРЫ:
Базовая идентификация:
<web-app>
...
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>sales</realm-name>
</login-config>
...
<web-app>
Идентификация с помощью форм:
<web-app>
...
<login-config>
<auth-method>FORM</auth-method>
<!--realm-name not required for FORM based authentication -->
<form-login-config>
<form-login-page>/formlogin.html</form-login-page>
<form-error-page>/formerror.html</form-error-page>
</form-login-config>
</login-config>
...
<web-app>
где formlogin.html И formerror.html соответственно страница идентификации и страница ошибки идентификации.
formlogin.html была приведена ранее и выглядит следующим образом:
<html>
<body>
<h4>Please login:</h4>
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">
<input type="submit" value="OK">
</form>
</body>
</html>
а formerror.html может выглядеть:
<html>
<body>
<h4>Sorry, your username and password do not match.</h4>
</body>
</html>
