OSGi Security Layer

Сегодня поговорим об одном из четырех функциональных слоёв среды выполнения OSGI - защитном слое (об остальных трех - модульном слое, слое управления жизненным циклом и сервисном слое,  постараюсь рассказать в следующем посте).

Защитный слой в OSGI полостью наследует защитный механизм из Java 2 Security Architecture. Насколько вы понимаете, тема достаточно объемная, и тот материал, который я здесь опишу, затронет лишь вершину айсберга защитной системы Java платформы, поэтому мы коснемся лишь тех вопросов которые больше всего касаются OSGi.

Безусловно такая защитная функциональность как верификация байт кода и Java Languаge  очень важны, но поскольку мы не хотим опускаться так глубоко, а лишь немного царапнем поверхность темы, будет лучше если мы поговорим таких темах как Permissions, Authentication и Authorization.

Но сначала несколько слов про историю Java Security. Она берет начало аж с самой первой платформы, но с тех пор достаточно сильно эволюционировала, в силу изменения требований к безопасности приложений и уровням доступа в целом.  Измененная версия защитного слоя появилась в платформе Java 2 и используется до сих пор. Java определяет несколько типов permissons, которые используются для получения доступа к системным ресурсам, с целью получения гарантий на их сохранность. В Java есть абстрактный класс Permission, который имеет несколько наследников. Для примера можно рассмотреть класс FilePermission. Этот класс нужен для того чтоб дать приложению права на определенный тип доступа к ресурсам.

FilePermission file = new FilePermission("myfile.txt" ,"read, write");

Объект file говорит о том что наше приложение может читать строки и добавлять новые строки в файл, который находится там же где и наше приложение. Как не хочется вручную выставлять права доступа к  каждому файлу, к счастью для этого есть возможность использовать ваилд-кард. Например, если мы хотим дать права на чтения не только папке, но и каждому файлу который в ней находится, можно в конце пути поставить символ '*'.

FilePermission file = new FilePermission("/tmp/*" ,"read");

Если хотим поставить права для всех вложенных директорий можно поставить мета символ '-'. 

FilePermission file = new FilePermission("/tmp/-" ,"read");

, при этом платформа обойдет все папки рекурсивно и каждому файлу поставит соответствующие права на чтение.

Следующими важными типами премишинов являются SoketPermission, который контролирует доступ в сеть через сокеты. Классы SecurityPermission и AuthPermision чрезвычайно важны для осуществления авторизации и аутентификации, как и говорят их названия. Аутентификация это процесс распознавания пользователя системой, в то время как авторизация это наделения пользователя определенными правами. Думаю из определения понятно что сначала пользователь должен пройти этап аутентификации, а уж затем авторизоваться. К счастью для этих целей в Java есть специальный пакет, который так и называется Java Authentication and Authorization (JAAS). Рассказывать об этом не очень интересно, гораздо легче почитать документацию. Стоит лишь знать что пакет обеспечивает почти всеми возможными способами и методами для проведения авторизации и аутентификации.

Как уже было сказано OSGI наследуют архитектуру Java 2, однако также вносит в нее дополнительные расширения. Забыл сказать что этот слой является необязательным, так как большинство решений наших задач не требует  защиты или использует более высокоуровневую защиту.

Платформа OSGI может идентифицировать код либо по цифровой подписи, либо по местоположению. На самом высоком уровне определены сервисы, которые управляют пермишинами, которые ассоциируются с аутентицированными кусками кода. Такими сервисами явлюятся: 

- Permission Admin Service

- Condidtional Permission Admin Service.
Самый часто применяемый способ это цифровая подпись jar-файлов. Этот способ применяется для аутентификации подписчика или для гарантии того что содержимое архива не было изменено после последней подписи. Цифровая подпись основана на публичном криптографическом ключе (Public Key Сryptography). PCL использует систему в которой есть два ключа: публичный и приватный. Один применяется для шифрования, второй - для расшифровки. Сообщение зашифрованное приватным ключем может быть проверено только с помощью публичного ключа.  Публичный ключ может быть отправлен в виде документа, который называется Сертификатом доверия, в то время как приватный должен быть в сохранном месте (где нибудь в несгораемом сейфе или под подушкой и бабушки). Jar файл может быть подписан несколькими подписчиками. Каждый из подписчиков должен сохранить в папке META-INF два типа ресурсов. Первый ресурс это своего рода манифест файл, содержащий инструкции, и должен иметь расширение .SF. Второй ресурс это PCKS7, содержащий цифровую подпись подписчика.

Каждая из реализация спецификации OSGI поддерживает MD5 и SHA1 алгоритмы. Бандлы в OSGI всегда являются валидными архивами. Однако есть некоторые ограничения к бандлам, которые не применяются к архивам. Бандлы не поддерживают частично подписанные бандлы. Другими словами манифест файл должен содержать подпись для каждого ресурса в бандле, не включая ресурсы в папке META-INF. Как уже было сказано, сертификаты это основная форма подписи документов, содержащая имя и информацию о публичном ключе. Этот сертификат может иметь несколько форм, но в OSGI принято для подписи использовать сертификаты формата X.509. Этот формат разрабатывался много лет и является частью OSI группы.

Вот в принципе и все. Осталось добавить что для управления сертификатами и цифровыми подписями есть очень удобное API, которое лишает нас чудесной возможности долгой руттиной работы над валидацией ключей и контрольных сум java-архивов и других ресуров.