Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации
Предыдущее Учебное руководство Учебное Введение и TOC

Больше Вещей Можно Сделать С GSS-API Java и JAAS



Предыдущее учебное руководство, Использование Утилиты Входа в систему JAAS и GSS-API Java для Безопасных Обменов сообщениями, демонстрируемых, как два приложения, в особенности клиент и сервер, могли использовать GSS-API Java, чтобы установить безопасный контекст между ними и затем надежно обмениваться сообщениями.

Есть дополнительные операции, которые может выполнить получатель контекста (сервер в нашем клиент-серверном примере), как только контекст был установлен с инициатором контекста (клиент). В основном сервер может "исполнить роль" клиента. Уровень олицетворения зависит от того, делегировал ли клиент учетные данные к серверу.


Выполнение Кода от имени Клиентского Пользователя

Один возможный тип заимствования прав клиентом, которое может сделать сервер, заставляет код выполняться от имени того же самого объекта (пользователь), клиентский код выполняется от имени. Обычно, метод, выполняемый потоком, использует настройки управления доступом для того потока непосредственно. Однако, исполняя роль клиента в этом учебном руководстве, сервер использует настройки управления доступом клиента так, чтобы у сервера был доступ к точно тем ресурсам, которые имеет сам клиент, когда это работает.

Одно главное преимущество этого подхода, используемое в этом учебном руководстве, - то, что компонент авторизации JAAS может использоваться для управления доступом. Без компонента авторизации JAAS принципал сервера нуждался бы в доступе к любым ресурсам, к которым получает доступ код, выполняемый от имени клиентского пользователя, и серверный код должен будет включать логику управления доступом, чтобы определить, был ли пользователь разрешен получить доступ к таким ресурсам. Используя авторизацию JAAS, обеспечивая основанное на принципале управление доступом, управление доступом обрабатывается автоматически. Полномочия для секретных операций безопасности в таком коде только нужно предоставить тому пользователю и не также к серверному коду. См. учебное руководство по Авторизации JAAS для получения дополнительной информации об авторизации JAAS.

Основной подход

Как сервер "исполняет роль" клиента, чтобы выполнить код от имени пользователя, выполняющего клиентский код? По существу тот же самый путь клиентский код устанавливается, чтобы быть выполненным от имени того пользователя. Весь серверный код должен знать, основное имя пользователя, которое он может получить из контекста, установленного с клиентом.

Вспомните, что аутентификация JAAS пользователя, выполняющего клиент, кодирует результаты в создании Предмета, содержащего Принципал с пользователем (основное) имя. Предмет впоследствии связывается с новым контекстом управления доступом (через a Subject.doAsPrivileged вызовите от утилиты Login), и клиентский код, как полагают, выполняется от имени пользователя; последующие решения управления доступом основаны на том, предоставляют ли тому определенному пользователю, выполняя клиентский код, необходимые полномочия.

Серверный код так же обрабатывается, кроме в этом случае Принципала, определенного для аутентификации, обычно "принципал службы", не пользовательский принципал. Снова, Предмет, содержащий Принципал с указанным основным именем, создается, Subject.doAsPrivileged вызывается, и серверный код, как полагают, выполняется от имени указанного принципала; последующие решения управления доступом основаны на том, предоставляют ли тому определенному принципалу, выполняя серверный код, необходимые полномочия.

Однажды клиент и сервер установили взаимный контекст, имя инициатора контекста (основное имя клиента) может быть определено следующим:

GSSName clientGSSName = context.getSrcName();

Получатель контекста (сервер) может использовать это имя, чтобы создать Предмет, содержащий Принципал, который представляет тот же самый объект. Например, если Вы используете JRE от Sun Microsystems, можно создать такой Предмет через следующее:

Subject client = 
  com.sun.security.jgss.GSSUtil.createSubject(clientGSSName, null);

createSubject метод создает новый Предмет из GSSName и GSSCredential, определенного как параметры. Если серверный код только собирается выполнить код от имени пользователя в локальной JVM, учетные данные пользователя не требуются - и фактически не могут даже быть получены, если клиент не делегировал учетные данные к серверу, как обсуждено в Использовании Учетных данных, Делегированных От Клиента. Так как учетные данные не необходимы здесь, мы передаем a null для параметра GSSCredential.

Отметьте: Если Вы не используете JRE от Sun Microsystems, альтернативный способ сделать, это должно создать экземпляр KerberosPrincipal следующим образом: 
KerberosPrincipal principal = 
  new KerberosPrincipal(clientGSSName.toString());

Затем используйте этот принципал, чтобы создать новый Предмет или заполнить этот принципал в основном наборе существующего Предмета.

Код, который сервер хотел бы выполнить от имени пользователя, должен инициироваться от run метод class, который реализует java.security.PrivilegedAction (или java.security.PrivilegedExceptionAction). Таким образом, код может или быть в таком run метод или вызванный от такого run метод.

Серверный код может передать Предмет, наряду с экземпляром PrivilegedAction (или PrivilegedExceptionAction), к Subject.doAsPrivileged выполнить последующий код, запускающийся с run метод в PrivilegedAction, от имени принципала (пользователь) в указанном Предмете.

Например, предположите PrivilegedAction, class вызывают ReadFileAction, и это берет в качестве параметра Строка с основным именем. Можно создать экземпляр этого class

String clientName = clientGSSName.toString();
PrivilegedAction readFile = 
    new ReadFileAction(clientName);

Звонок doAsPrivileged тогда

Subject.doAsPrivileged(client, readFile, null);

Пример кода и Файл Политики

Следующий пример кода и файл политики иллюстрируют сервер, исполняющий роль клиента, чтобы выполнить код, секретным операциям безопасности которого только разрешают быть сделанными определенным пользователем, выполняющим клиент.

SampleServerImp.java

Файл SampleServerImp.java является точно тем же самым как файлом SampleServer.java от предыдущего (Использование Утилиты Входа в систему JAAS и GSS-API Java для Безопасных Обменов сообщениями) учебное руководство, за исключением того, что после обмена сообщениями с клиентом, у этого есть следующий код, чтобы выполнить a ReadFileAction как клиентский пользователь:

System.out.println("Impersonating client.");

/*
 * Extract the KerberosPrincipal from the client GSSName and 
 * populate it in the principal set of a new Subject. Pass in a 
 * null for credentials since credentials will not be needed.
 */
GSSName clientGSSName = context.getSrcName();
System.out.println("clientGSSName: " + clientGSSName);
Subject client =
   com.sun.security.jgss.GSSUtil.createSubject(clientGSSName,
        null);

/*
* Construct an action that will read a file meant only for the
* client
*/
String clientName = clientGSSName.toString();
PrivilegedAction readFile = 
   new ReadFileAction(clientName);

/*
* Invoke the action via a doAsPrivileged. This allows the
* action to be executed as the client subject, and it also 
* runs that code as privileged. This means that any permission 
* checking that happens beyond this point applies only to 
* the code being run as the client.
*/
Subject.doAsPrivileged(client, readFile, null);

ReadFileAction.java

Файл ReadFileAction.java содержит ReadFileAction class. Его конструктор берет в качестве параметра Строка для имени клиентского пользователя. Клиентское имя пользователя используется, чтобы создать имя файла для файла, из которого ReadFileAction попытается читать. Имя файла будет:

./data/<name>_info.txt
где <имя> является клиентским именем пользователя без своей соответствующей области. Например, если полное имя пользователя mjones@KRBNT-OPERATIONS.EXAMPLE.COM, тогда имя файла 
./data/mjones_info.txt
Отметьте: На системах Microsoft Windows наклонные черты вправо будут наклонными чертами влево.

ReadFileAction run метод читает указанный файл и печатает его содержание.

serverimp.policy

ReadFileAction пытается считать файл, который является проверенной в безопасности работой. Так как ReadFileAction, как полагают, выполняется как клиентский пользователь (Принципал), соответствующее разрешение нужно предоставить не только коду ReadFileAction непосредственно, но и клиентскому Принципалу также.

Принятие ReadFileAction class помещается в названный файл JAR ReadFileAction.jar, и пользовательское имя принципала mjones@KRBNT-OPERATIONS.EXAMPLE.COM, это разрешение можно предоставить через следующее в файле политики:

grant CodeBase "file:./ReadFileAction.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "mjones@KRBNT-OPERATIONS.EXAMPLE.COM" {

    permission java.io.FilePermission "data/mjones_info.txt", 
        "read";
};
serverimp.policy файл является точно тем же самым как server.policy файл от предыдущего (Использование Утилиты Входа в систему JAAS и GSS-API Java для Безопасных Обменов сообщениями) учебное руководство, за исключением того, что это предоставляет SampleServer, кодирует javax.security.auth.AuthPermission "doAsPrivileged" разрешение, в котором это нуждается, чтобы вызвать doAsPrivileged метод, и у этого есть следующий заполнитель для того, чтобы предоставить FilePermission, показанный выше: 
grant CodeBase "file:./ReadFileAction.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "your_user_name@your_realm" {

    permission java.io.FilePermission "data/your_user_name_info.txt", 
        "read";
};

Следует заменить своей областью Kerberos your_realm, и Ваше имя пользователя для your_user_name в обоих your_user_name@your_realm и data/your_user_name_info.txt. Если Вы работаете над Microsoft Windows sytem, Вы также заменяете "/" в data/your_user_name_info.txt с "\".

Выполнение Примера кода

Чтобы выполнить пример кода, иллюстрирующий сервер, исполняющий роль клиента, сделайте все перечисленное в Выполнении Программ SampleClient и SampleServer в предыдущем учебном руководстве, за исключением следующего:

Используя Учетные данные, Делегированные От Клиента

Самый полный тип заимствования прав клиентом возможен, если клиент делегирует его учетные данные к серверу.

Вспомните, что до установления контекста с получателем контекста (сервер в нашем предыдущем учебном руководстве), инициатор контекста (клиент) устанавливает различные опции контекста. Если инициатор вызывает requestCredDeleg метод на context объект с a true параметр, как в

context.requestCredDeleg(true);
тогда это запрашивает, чтобы учетные данные инициатора были делегированы получателю во время установления контекста.

Делегация учетных данных от инициатора получателю позволяет получателю аутентифицировать себя как агент или делегат инициатора.

Во-первых, после установления контекста, получатель должен определить, имела ли учетная делегация фактически место. Это делает так, вызывая getCredDelegState метод:

boolean delegated = context.getCredDelegState();

Если учетные данные были делегированы, получатель может получить те учетные данные, вызывая getDelegCr метод:

GSSCredential clientCr = context.getDelegCr();

Получающийся объект GSSCredential может тогда использоваться, чтобы инициировать последующие контексты GSS-API как "делегата" инициатора. Например, сервер мог аутентифицировать как клиент к серверу бэкэнда, который заботится больше о том, кем исходный клиент был чем, кто промежуточный сервер.

Действуя как клиент, сервер может установить соединение с сервером бэкэнда, установить объединенный контекст защиты, и обмениваться сообщениями в основном тем же самым способом, что клиент и сервер сделал.

Одним путем это могло быть сделано, это, когда сервер вызывает createContext метод GSSManager, это могло передать createContext делегированные учетные данные вместо того, чтобы передать a null.

Альтернативно, серверный код мог сначала вызвать com.sun.security.jgss.GSSUtil createSubject метод и передача это делегированные учетные данные. Тот метод возвращает Предмет, содержащий те учетные данные как учетные данные значения по умолчанию. Сервер мог тогда связать этот Предмет с текущим AccessControlContext, как описано в том, Как Вы Связываете Предмет с Контекстом Управления доступом? в учебном руководстве по Авторизации JAAS. Затем, когда серверный код вызывает GSSManager createContext метод, это может передать нуль (указание, что учетные данные для "текущего" Предмета должны использоваться). Другими словами сервер эффективно стал бы клиентом. Последующие соединения с серверами бэкэнда, используя GSS могли быть сделаны точно как описано в предыдущих учебных руководствах. Этот подход полезен, если Вы хотите код, который будет использовать делегированные учетные данные, чтобы быть идентичным коду, который использует значение по умолчанию локальные учетные данные.

Разрешение, Необходимое, Чтобы Делегировать Учетные данные

Чтобы делегировать учетные данные, у инициатора контекста (SampleClient в нашем предыдущем учебном руководстве) должен быть a javax.security.auth.kerberos.DelegationPermission. Примером, используя заполнителей курсивом для фактических значений является следующее:

permission javax.security.auth.kerberos.DelegationPermission
  "\"service_principal@your_realm\"  
     \"krbtgt/your_realm@your_realm\"";

Отметьте, что у DelegationPermission есть единственная цель в кавычках, которая содержит два элемента, оба из которых заключаются в кавычки. Каждой внутренней кавычки оставляют "\". Таким образом первый элемент

"service_principal@your_realm"
и второе 
"krbtgt/your_realm@your_realm"

Это в основном дает код, выполняющийся от имени клиента разрешение, чтобы передать билет Kerberos указанной коллеге (service_principal), где билет Kerberos предназначается, чтобы помочь службе от krbtgt/your_realm@your_realm.

Замените своей областью все места your_realm появляется. Также замените именем принципала службы принципал службы представление сервера для service_principal@your_realm. (См. Имена Принципала Пользователя и Службы Kerberos в предыдущем учебном руководстве.) Предполагают, что Ваша область KRBNT-OPERATIONS.EXAMPLE.COM, и принципал службы "sample/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM". Затем разрешение могло появиться в файле политики как

permission javax.security.auth.kerberos.DelegationPermission
  "\"sample/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM\"  
     \"krbtgt/KRBNT-OPERATIONS.EXAMPLE.COM@KRBNT-OPERATIONS.EXAMPLE.COM\"";

Предыдущее Учебное руководство Учебное Введение и TOC
Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами