Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
Есть две основных настройки, в которых используется JNDI: с и без менеджера безопасности устанавливается.
В случае приложений Java, работающих без установленного менеджера безопасности, доверяют коду, и приложение может провайдеры службы доступа от локального пути к классу. Кроме того нет никакого ограничения, если доступ поставщиков услуг локальные файлы, или делают сетевые соединения с именованием или серверами каталогов где-нибудь на сети.
В случае апплета или приложения, работающего с установленным менеджером безопасности, может быть доверяемый код и недоверяемый код в пределах того же самого апплета или приложение. Совместное использование Дескрипторов Контекста и разделов Среды Контекста ниже особенно применимо в таком сценарии. Возможность апплета или приложения, работающего с менеджером безопасности, установленным к провайдерам службы доступа, особенно поставщики услуг, которые требуют использования ограниченных ресурсов (как файловая система или сетевые соединения), может быть строго ограничена.
Классы в пакетах JNDI не содержат собственных методов. Они не требуют никакой специальной установки, чтобы работать в апплете или приложении.
JNDI использует несколько системных свойств (см. Стандартные Свойства JNDI Application/Applet-scope). Это позволяет апплетам и приложениям быть сконфигурированными легко без большого программирования. Однако, у апплета или приложения мог бы быть ограниченный доступ к некоторым или всем системным свойствам в результате менеджера безопасности, установленного на платформе, на которой это работает. Следовательно, JNDI также позволяет этим тем же самым свойствам быть определенными как параметры апплета в файлах ресурсов, или как свойства среды, которые передают к контексту.
В Java 2 Платформы, использование классов JNDI doPrivileged блоки, получая доступ к системным свойствам, перечисленным в Стандартных Свойствах JNDI Application/Applet-scope.
JNDI не определяет модель обеспечения безопасности или интерфейс коллективной безопасности для того, чтобы получить доступ к именованию и серверам каталогов. Со связанными с безопасностью операциями, такими как требуемые для аутентификации или управления доступом к службе каталогов, имеют дело отдельные поставщики услуг. JNDI обеспечивает средства, которыми приложение или апплет могут передать такую связанную с безопасностью информацию к поставщикам услуг, чтобы установить соединение со службой, но самостоятельно не принимает участие в таких связанных с безопасностью действиях.
JNDI также обеспечивает средства, которыми связанные с безопасностью проблемы могут быть обозначены клиенту в форме связанных с безопасностью исключений.
Поставщиками услуг JNDI управляет менеджер безопасности на месте, когда они пытаются получить доступ к защищенным ресурсам, таким как файловая система или сеть. Некоторые поставщики услуг могут управлять доступом каталога, используя Java 2 архитектуры безопасности Платформы (например, предоставляя доступ к специальным портам для связанных с администрированием апплетов).
У именования и службы каталогов обычно есть их собственная система обеспечения безопасности на месте, чтобы защитить информацию, хранившую там. Например, один каталог мог бы потребовать, чтобы его пользователи сначала "вошли в систему" к каталогу прежде, чем считать или обновить информацию в каталоге. Некоторые службы могли бы предоставить анонимный доступ к части его пространства имен/каталога.
Как только пользователь зарегистрировал в службу, обязательно для соображений безопасности не совместно использовать то полномочие с недоверяемым кодом.
В следующем обсуждении мы именуем дескриптор контекста как ссылку на a Context экземпляр. Это походит как ссылка на a Reader / Writer / InputStream / OutputStream экземпляр часто упоминается как дескриптор файла.
Дескриптор контекста должен быть обработан как любой другой защищенный ресурс. Если часть доверяемого кода получает дескриптор контекста (возможно, аутентифицируя его доступ с сервером каталогов), это должно защитить использование того контекста против несанкционированного или недоверяемого кода. Это походит, как приложение и/или код апплета должны защитить дескрипторы файлов. Например, если часть доверяемого кода открывает файл для того, чтобы записать (и этому предоставили такое полномочие из-за его доверяемого характера), это должно быть осторожно относительно передачи того дескриптора файла к любым другим частям кода, которому доверяют или иначе.
Точно так же предоставляющий доступ дескриптора контекста к недоверяемому коду может привести к своему неправильному употреблению в доступе или обновлении информации в каталоге, или доступа к чувствительным к безопасности свойствам среды, связанным с контекстом.
JNDI позволяет приложению/апплету передавать предпочтение и информацию к контексту в форме среды. Приложение/апплет может также получить текущую среду от контекста. См. См. Конфигурацию и Приложение A для получения дополнительной информации о среде контекста.
Природа информации, содержавшейся в среде контекста, могла бы быть чувствительной и нуждаться в защите от недоверительного доступа. Определенно, свойства среды java.naming.security.principal и java.naming.security.credentials содержите информацию, которая не должна быть выделена к недоверяемому коду. Поставщики услуг могли бы взять предосторожность, чтобы защитить от доступа к этим свойствам (см. Обязанности Поставщиков услуг ниже). Клиентские приложения и апплеты должны заботиться, чтобы не передать дескрипторы контекста с такими чувствительными свойствами среды к недоверяемому коду.
JNDI позволяет файлам class быть загруженными динамически.
Когда JNDI выполняется на JDK 1.1.x платформа, это использует RMI загрузчик class. Классы могут только быть загружены, если есть менеджер безопасности, установленный, и если тот менеджер безопасности разрешает class быть загруженным. Когда такие классы загружаются, они работают в контексте защиты, продиктованном менеджером безопасности.
Когда JNDI будет выполнен на Java 2 платформы, это попытается загрузить такие классы из расположений, определенных в кодовой базе, используя java.net.URLClassLoader . Для class, загружающегося, чтобы успешно выполниться, следует удовлетворить ходатайство и JNDI и классы поставщика услуг полномочия, подходящие для URL, названных в кодовой базе. Например, если схема URL является "http" или "протоколом передачи файлов", следует удовлетворить ходатайство соответствующее java.net.SocketPermission ; если схема URL является "файлом", следует удовлетворить ходатайство соответствующее java.io.FilePermission .
Несколько из классов JNDI сериализуемы. Это позволяет объектам быть полученными доступ в форме потока байтов, возможно за пределами среды, в которой они создавались.
Когда дескриптор контекста создается (или получая начальный контекст или ища это или создавая это из каталога), некоторые свойства среды могут быть определены для этого. Иногда связанные с безопасностью свойства требуются для создания дескриптора контекста (такого как информация о пользователе, которая "регистрирует" пользователя в с каталогом). Поставщик услуг должен заботиться, чтобы защитить эту уязвимую информацию безопасности от недоверяемого кода.
Поставщик услуг должен защитить среду контекста от того, чтобы быть вмешивавшимся или иначе измененный недоверяемым кодом. Поставщик услуг должен защитить чувствительные к безопасности свойства среды от того, чтобы быть считанным недоверяемым кодом. Это могло бы сделать это, отвергая любой поток, контекст выполнения которого и/или полагают, что уровень отличается чем это первоначально сохраненное потоком, который создал дескриптор контекста, чтобы использовать дескриптор контекста. Или это могло бы отвергнуть определенные операции (такие как доступ к чувствительным к безопасности свойствам среды). Или это не могло бы просто возвратить чувствительные к безопасности свойства среды, или только возвратить их доверяемому коду.
У недоверяемого кода (такого как найденные в недоверяемых апплетах) есть ограниченный доступ к сети. Недоверяемые апплеты, например, могут только создать сетевое соединение с узлом, с которого они были загружены. С моделями обеспечения безопасности более прекрасной мелкой частицы для поставщика услуг непосредственно будет возможно быть доверяемым кодом, и следовательно быть позволенным соединиться с узлами не учитывало недоверяемые апплеты. В таком сценарии поставщик услуг должен бояться ставить под угрозу безопасность, предназначенную менеджером безопасности. Если поставщик услуг уверен, что доступ недоверяемым апплетом к каталогу не вызовет проблем безопасности, то это может продолжиться, чтобы предложить такую услугу к недоверяемому коду. Например, разрешение недоверяемого кода получить доступ к каталогу "анонимно" не отправило бы проблем безопасности, потому что каталог уже позволяет любому анонимному клиенту (записанный в языке программирования Java или иначе) получать доступ к тем же самым данным.
К большинству именования и служб каталогов получают доступ по сети. Хотя запрошенные данные защищаются механизмами аутентификации сервера и механизмами управления доступом, некоторые протоколы не защищают (шифруют) данные, отправляемые как ответы. Снова, это не проблема, определенная клиенту, использующему JNDI, а проблему для любого клиента, получающего доступ к каталогу. Поставщик услуг должен задокументировать импликации безопасности, связанные с использованием связанного каталога по сети.
Подобный сетевому доступу, у недоверяемого кода есть ограниченный доступ к локальной файловой системе. Если у поставщика услуг есть специальные полномочия для того, чтобы получить доступ к локальным файлам, он должен сделать так с предельной предосторожностью, чтобы не поставить под угрозу политику безопасности, предназначенную временем выполнения/платформой.
Поставщиком услуг, который пишется полностью в языке программирования Java без привилегированных разделов, управляет та же самая политика безопасности предоставленный другой код, записанный в языке программирования Java. Все защищенные ресурсы, к которым это пытается получить доступ, проходят через того же самого менеджера безопасности и контроллер доступа.
Если поставщик услуг содержит привилегированные разделы кода, или если он содержит собственные методы, то он должен особенно делать все возможное сохранить политику безопасности, предназначенную временем выполнения/платформой.
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT
