Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
 |
Это учебное руководство представляет два примера приложения, демонстрирующие использование GSS-API Java для безопасных обменов сообщениями между связывающимися приложениями, в этом случае клиентским приложением и серверным приложением.
GSS-API Java использует то, что вызывают "механизмом безопасности", чтобы предоставить эти услуги. Реализация GSS-API, доступная с Java 2 Standard Edition платформа, содержит поддержку Kerberos механизм V5 в дополнение к любым другим специфичным для поставщика вариантам. Мы используем Kerberos механизм V5 для этого учебного руководства.
Чтобы выполнить аутентификацию между клиентом и сервером и установить криптографические ключи для безопасной передачи, механизм GSS-API нуждается в доступе к определенным учетным данным для локального объекта на каждой стороне соединения. В нашем случае учетные данные, используемые на стороне клиента, состоят из билета Kerberos, и на стороне сервера, это состоит из длительного срока секретный ключ Kerberos. Билеты Kerberos могут дополнительно включать адрес узла и IPv4, и адреса узла IPv6 оба поддерживаются. GSS-API Java требует, чтобы механизм получил эти учетные данные из Предмета, связанного с контекстом управления доступом потока.
Чтобы заполнить Предмет с такими учетными данными, приложения клиента и сервера обычно будут сначала выполнять аутентификацию JAAS, используя модуль Kerberos. Учебное руководство по Аутентификации JAAS демонстрирует, как сделать это. Учебное руководство по Авторизации JAAS тогда демонстрирует, как связать аутентифицируемый Предмет с контекстом управления доступом потока. Утилита была также записана как удобство автоматически выполнить те операции от Вашего имени. Использование учебного руководства по Утилите Входа в систему JAAS демонстрирует, как использовать утилиту Login.
Для этого учебного руководства у нас не будет клиента и сервера, выполняют аутентификацию JAAS, и при этом мы не сделаем, чтобы они использовали утилиту Login. Вместо этого мы положимся на установку системного свойства javax.security.auth.useSubjectCredsOnly к false, который позволяет нам ослаблять ограничение требования, чтобы механизм GSS получил необходимые учетные данные из существующего Предмета, установленного JAAS. См. useSubjectCredsOnly Системное Свойство.
Отметьте: Это - упрощенное вводное учебное руководство. Например, мы не включаем файлов политики или выполняем пример кода, используя менеджера безопасности. В действительности код, используя GSS-API Java должен быть выполнен с менеджером безопасности, так, чтобы секретные операции безопасности не были бы позволены, если необходимые полномочия явно не предоставили.
Есть другое учебное руководство, Использование Утилиты Входа в систему JAAS и GSS-API Java для Безопасных Обменов сообщениями, который является точно так же как учебное руководство, которое Вы читаете за исключением того, что это использует утилиту Login, файлы политики, и более сложный конфигурационный файл входа в систему (Конфигурационный файл входа в систему, требуемый всякий раз, когда аутентификация JAAS делается, определяет требуемый модуль аутентификации).
Как со всеми учебными руководствами в этом ряду, базовая технология, используемая, чтобы поддерживать аутентификацию и безопасную передачу для приложений в этом учебном руководстве, Kerberos V5. См. Требования Kerberos.
Если Вы хотите сначала видеть учебный код в действии, можно пропустить непосредственно к Выполнению Программ SampleClient и SampleServer и затем вернуться к другим разделам, чтобы учиться больше.
Приложения для этого учебного руководства называют SampleClient и SampleServer.
Вот сводка выполнения приложений SampleClient и SampleServer:
Фактический код и более подробная информация представляются в следующих разделах.
Весь код и для программ SampleClient и для SampleServer находится в их main методы и могут быть разломаны на следующие подразделения:
Отметьте: классы GSS-API Java, используемые этими программами (GSSManager, GSSContext, GSSName, GSSCredential, MessageProp, и Oid), находятся в org.ietf.jgss пакет.
Первая вещь оба наших клиента и сервера main методы делают читается параметры командной строки.
SampleClient ожидает три параметра:
Вот код для того, чтобы считать параметры командной строки:
if (args.length < 3) {
System.out.println("Usage: java <options> Login SampleClient "
+ " <servicePrincipal> <hostName> <port>");
System.exit(-1);
}
String server = args[0];
String hostName = args[1];
int port = Integer.parseInt(args[2]);
SampleServer ожидает только один параметр:
Вот код для того, чтобы считать параметр командной строки:
if (args.length != 1) {
System.out.println(
"Usage: java <options> Login SampleServer <localPort>");
System.exit(-1);
}
int localPort = Integer.parseInt(args[0]);
GSS-API Java обеспечивает методы для создания и интерпретации маркеров (непрозрачные данные байта). Маркеры содержат сообщения, которыми надежно обменяются между двумя коллегами, но метод фактической маркерной передачи до коллег. Для наших приложений SampleClient и SampleServer мы устанавливаем сокетное соединение между клиентом и сервером и обмениваемся данными, используя потоки ввода и вывода сокета.
SampleClient передали как параметры имя хост-машины, на которой SampleServer работает, так же как номер порта, на котором SampleServer будет прислушиваться к соединениям, таким образом, у SampleClient есть все, который это должно установить сокетное соединение с SampleServer. Это использует следующий код, чтобы установить соединение и инициализировать DataInputStream и DataOutputStream для будущих обменов данными:
Socket socket = new Socket(hostName, port);
DataInputStream inStream =
new DataInputStream(socket.getInputStream());
DataOutputStream outStream =
new DataOutputStream(socket.getOutputStream());
System.out.println("Connected to server "
+ socket.getInetAddress());
Приложение SampleServer передали как параметр номер порта, который будет использоваться для того, чтобы прислушаться к соединениям от клиентов. Это создает ServerSocket для того, чтобы слушать на том порту:
ServerSocket ss = new ServerSocket(localPort);
ServerSocket может тогда ожидать и принять соединение от клиента, и затем инициализировать DataInputStream и DataOutputStream для будущих обменов данными с клиентом:
Socket socket = ss.accept();
DataInputStream inStream =
new DataInputStream(socket.getInputStream());
DataOutputStream outStream =
new DataOutputStream(socket.getOutputStream());
System.out.println("Got connection from client "
+ socket.getInetAddress());
accept метод ожидает, пока клиент (в нашем случае, SampleClient) не запрашивает соединение на узле и порту SampleServer, через который делает SampleClient
Socket socket = new Socket(hostName, port);
Когда соединение требуют и устанавливается, accept метод возвращает новый объект Сокета, связанный с новым портом. Сервер может связаться с клиентом по этому новому сокету и продолжать прислушиваться к другим клиентским запросам соединения на ServerSocket, связанном с исходным портом. Таким образом у программы сервера обычно есть цикл, который может обработать многократные запросы соединения.
Структура основного цикла для нашего SampleServer является следующим:
while (true) {
Socket socket = ss.accept();
<Establish input and output streams for the connection>
<Establish a context with the client>
<Exchange messages with the client>;
<Clean up>;
}
Клиентские соединения ставятся в очередь в исходном порту, таким образом, с этой структурой программы, используемой SampleServer, взаимодействие с первым клиентом, делающим соединение, должно завершиться прежде, чем следующее соединение может быть принято. Сервер мог фактически обслужить многократные клиенты одновременно с помощью потоков - один поток на клиентское соединение, как в
while (true) {
<accept a connection>;
<create a thread to handle the client>;
}
Прежде, чем два приложения могут использовать GSS-API Java, чтобы надежно обмениваться сообщениями между ними, они должны установить объединенный контекст защиты, используя их учетные данные. (Отметьте: В случае SampleClient были установлены учетные данные, когда утилита Login, аутентифицируемая пользователь, на имени которого SampleClient был выполнен, и так же для SampleServer.) Контекст защиты инкапсулирует информацию об общем состоянии, которая могла бы включать, например, криптографические ключи. Одно использование таких ключей могло бы быть должно зашифровать сообщения, которыми обменяются, если шифрование требуют.
Как часть установления контекста защиты, инициатор контекста (в нашем случае, SampleClient) аутентифицируется получателю (SampleServer), и может потребовать, чтобы получатель также аутентифицировался назад инициатору, когда мы говорим, что "взаимная аутентификация" имела место.
Оба приложения создают и используют объект GSSContext установить и поддержать общую информацию, которая составляет контекст защиты.
Инстанцирование объекта контекста делается по-другому инициатором контекста и получателем контекста. После того, как инициатор инстанцирует GSSContext, он может хотеть устанавливать различные опции контекста, которые определят характеристики требуемого контекста защиты, например, определяя, должна ли взаимная аутентификация иметь место. После того, как все требуемые характеристики были установлены, инициатор вызывает initSecContext метод, который производит маркер, требуемый получателем acceptSecContext метод.
В то время как методы GSS-API Java существуют для того, чтобы подготовить маркеры, которыми обменяются между приложениями, это - обязанность приложений фактически передать маркеры между ними. Так после того, как инициатор получил маркер от его звонка initSecContext, это отправляет тот маркер получателю. Акцепторные вызовы acceptSecContext, передача этого маркер. acceptSecContext метод может поочередно возвратить маркер. Если это делает, получатель должен отправить тот маркер инициатору, который должен тогда вызвать initSecContext снова и передача это этот маркер. Каждый раз initSecContext или acceptSecContext возвращает маркер, приложение, которое названный методом должно отправить маркер его коллеге, и та коллега должна передать маркер к своему соответствующему методу (acceptSecContext или initSecContext). Это продолжается, пока контекст полностью не устанавливается (который имеет место когда контекст isEstablished возвраты метода true).
Код установления контекста для наших примеров приложения описывается в следующем:
В нашем клиент-серверном сценарии SampleClient является инициатором контекста. Вот основные шаги, которые это делает, чтобы установить контекст защиты. Это
initSecContext, отправка любого возвращенного маркера к SampleServer, и получения маркера (если любой) от SampleServer.GSSContext создается, инстанцируя GSSManager и затем вызывая один из createContext методы. class GSSManager служит фабрикой для других важных классов API GSS. Это может создать экземпляры классов, реализовывая GSSContext, GSSCredential, и интерфейсы GSSName.
SampleClient получает экземпляр значения по умолчанию подкласс GSSManager, вызывая статический метод GSSManager getInstance:
GSSManager manager = GSSManager.getInstance();
Значение по умолчанию подкласс GSSManager является тем чей create* методы (createContext, и т.д.), возвращают классы, реализации которых поддерживают Kerberos как базовую технологию.
У метода фабрики GSSManager для того, чтобы создать контекст на стороне инициатора есть следующая подпись:
GSSContext createContext(GSSName peer, Oid mech,
GSSCredential myCred, int lifetime);
Параметры описываются ниже, сопровождаются полным звонком createContext.
GSSName peer ПараметрКоллега в нашей клиент-серверной парадигме является сервером. Для peer параметр, мы нуждаемся в GSSName для принципала службы представление сервера. (См. Имена Принципала Пользователя и Службы Kerberos.) Строку для имени принципала службы передают как первый параметр SampleClient, который помещает параметр в его локальную названную Строковую переменную server. GSSManager manager используется, чтобы инстанцировать GSSName, вызывая один из createName методы. SampleClient вызывает createName метод со следующей подписью:
GSSName createName(String nameStr, Oid nameType);
SampleClient передает server Строка для nameStr параметр.
Вторым параметром является Oid, Oid представляет Универсальный Объектный Идентификатор. Oids являются иерархически глобально поддающимися толкованию идентификаторами, используемыми в пределах платформы GSS-API, чтобы идентифицировать типы имени и механизмы. Структура и кодирование Oids определяются в ISOIEC-8824 и стандартах ISOIEC-8825. Oid передал к createName методом является определенно Oid типа имени (не Oid механизма).
В GSS-API названия строк часто отображаются от независимого от механизма формата в специфичный для механизма формат. Обычно, Oid определяет, какой формат имени строка находится в том, так, чтобы механизм знал, как сделать это отображение. Передача в a null Oid указывает, что имя уже находится в собственном формате, который использует механизм. Дело обстоит так для server Строка; это находится в соответствующем формате для имени Версии 5 Kerberos. Таким образом SampleClient передает a null для Oid. Вот вызов:
GSSName serverName = manager.createName(server, null);
Oid mech ПараметрВторой параметр GSSManager createContext методом является Oid, представляющий механизм, который будет использоваться для аутентификации между клиентом и сервером во время установления контекста и для последующей безопасной передачи между ними.
Наше учебное руководство будет использовать Kerberos V5 в качестве механизма безопасности. Oid для Kerberos, механизм V5 определяется в как "1.2.840.113554.1.2.2", таким образом, мы создаем такой Oid:
Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
Передачи SampleClient krb5Oid как второй параметр createContext.
GSSCredential myCred ПараметрТретий параметр GSSManager createContext метод является GSSCredential представление учетных данных вызывающей стороны. Если Вы передаете null для этого параметра, как SampleClient делает, используются учетные данные значения по умолчанию.
int lifetime ПараметрЗаключительный параметр GSSManager createContext метод int определение требуемого времени жизни, в секундах, для контекста, который создается. Передачи SampleClient GSSContext.DEFAULT_LIFETIME запрашивать время жизни значения по умолчанию.
Теперь, когда у нас есть все необходимые параметры, вот вызов, который SampleClient выполняет, чтобы создать GSSContext:
GSSContext context =
manager.createContext(serverName,
krb5Oid,
null,
GSSContext.DEFAULT_LIFETIME);
После инстанцирования контекста, и до фактического устанавливания контекста с получателем контекста, инициатор контекста может хотеть устанавливать различные варианты, которые определяют требуемые характеристики контекста защиты. Каждая такая опция устанавливается, вызывая a request метод на инстанцированном контексте. Больше всего request методы берут a boolean параметр за указание, требуют ли функцию. Для запроса не всегда возможно быть удовлетворенным, так, было ли это, может быть определен после установления контекста, вызывая один из get методы.
SampleClient запрашивает следующее:
wrap. Шифрование фактически используется только если объект MessageProp, который передают к wrap метод запрашивает конфиденциальность.wrap и getMIC методы. Когда целостность требуют, криптографический тег, известный, поскольку Код Целостности сообщения (MIC) будет сгенерирован, вызывая те методы. Когда getMIC вызывается, сгенерированный MIC появляется в возвращенном маркере. Когда wrap вызывается, MIC упаковывается вместе с сообщением (исходное сообщение или результат шифрования сообщения, в зависимости от того, была ли конфиденциальность применена), все как часть одного маркера. Можно впоследствии проверить MIC против сообщения, чтобы гарантировать, что сообщение не было изменено в пути.SampleClient кодируют для того, чтобы обратиться с этими просьбами на GSSException context следующее:
context.requestMutualAuth(true); // Mutual authentication context.requestConf(true); // Will use encryption later context.requestInteg(true); // Will use integrity later
Отметьте: При использовании значения по умолчанию реализация GSSManager и механизм Kerberos, будут всегда предоставлять эти запросы.
После того, как SampleClient инстанцировал GSSContext и определил требуемые опции контекста, он может фактически установить контекст защиты с SampleServer. Чтобы сделать так, у SampleClient есть цикл. Каждая итерация цикла
initSecContext метод. Если это - первый вызов, метод передают a null маркер. Иначе, это передают маркер, последний раз отправленный SampleClient SampleServer (маркер, сгенерированный SampleServer, призывают acceptSecContext).initSecContext (если любой) к SampleServer. Первый звонок initSecContext всегда производит маркер. Последняя возможность не могла бы возвратить маркер.Маркеры, возвращенные initSecContext или полученный от SampleServer помещаются в байтовый массив. Маркеры должны быть обработаны SampleClient и SampleServer как непрозрачные данные, которые передадут между ними и интерпретируют методами GSS-API Java.
initSecContext параметрами является байтовый массив, содержащий маркер, начальное смещение в тот массив того, где маркер начинается, и маркерная длина. Для первого вызова SampleClient передает нулевой маркер, так как никакой маркер еще не был получен от SampleServer.
Чтобы обмениваться маркерами с SampleServer, SampleClient использует DataInputStream inStream и DataOutputStream outStream это ранее устанавливало использование потоков ввода и вывода для сокетного соединения, сделанного с SampleServer. Отметьте, что всякий раз, когда маркер пишется, число байтов в маркере пишется сначала, сопровождается маркером непосредственно. Причины обсуждаются во введении в раздел Обменов сообщениями SampleClient и SampleServer.
Вот цикл установления контекста SampleClient, сопровождаемый информацией об отображении кода о том, кто клиент и сервер и имела ли взаимная аутентификация фактически место:
byte[] token = new byte[0];
while (!context.isEstablished()) {
// token is ignored on the first call
token = context.initSecContext(token, 0, token.length);
// Send a token to the server if one was generated by
// initSecContext
if (token != null) {
System.out.println("Will send token of size "
+ token.length + " from initSecContext.");
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
}
// If the client is done with context establishment
// then there will be no more tokens to read in this loop
if (!context.isEstablished()) {
token = new byte[inStream.readInt()];
System.out.println("Will read input token of size "
+ token.length
+ " for processing by initSecContext");
inStream.readFully(token);
}
}
System.out.println("Context Established! ");
System.out.println("Client is " + context.getSrcName());
System.out.println("Server is " + context.getTargName());
if (context.getMutualAuthState())
System.out.println("Mutual authentication took place!");
В нашем клиент-серверном сценарии SampleServer является получателем контекста. Вот основные шаги, которые это делает, чтобы установить контекст защиты. Это
acceptSecContext и передача этого маркер, и отправка любого возвращенного маркера к SampleClient.Как описано в SampleClient Инстанцирование GSSContext, GSSContext создается, инстанцируя GSSManager и затем вызывая один из createContext методы.
Как SampleClient, SampleServer получает экземпляр значения по умолчанию подкласс GSSManager, вызывая статический метод GSSManager getInstance:
GSSManager manager = GSSManager.getInstance();
У метода фабрики GSSManager для того, чтобы создать контекст на стороне получателя есть следующая подпись:
GSSContext createContext(GSSCredential myCred);
Если Вы передаете null для параметра GSSCredential, как SampleServer делает, используются учетные данные значения по умолчанию. Контекст инстанцируют через следующее:
GSSContext context = manager.createContext((GSSCredential)null);
После того, как SampleServer инстанцировал GSSContext, он может установить контекст защиты с SampleClient. Чтобы сделать так, у SampleServer есть цикл, который продолжается, пока контекст не устанавливается. Каждая итерация цикла делает следующее:
initSecContext вызвать.acceptSecContext метод, передавая это маркер только получается.acceptSecContext возвращает маркер, тогда SampleServer отправляет этот маркер SampleClient и затем запускает следующую итерацию цикла, если контекст еще не устанавливается.Маркеры, возвращенные acceptSecContext или полученный от SampleClient помещаются в байтовый массив.
acceptSecContext параметрами является байтовый массив, содержащий маркер, начальное смещение в тот массив того, где маркер начинается, и маркерная длина.
Чтобы обмениваться маркерами с SampleClient, SampleServer использует DataInputStream inStream и DataOutputStream outStream это ранее устанавливало использование потоков ввода и вывода для сокетного соединения, сделанного с SampleClient.
Вот цикл установления контекста SampleServer:
byte[] token = null;
while (!context.isEstablished()) {
token = new byte[inStream.readInt()];
System.out.println("Will read input token of size "
+ token.length
+ " for processing by acceptSecContext");
inStream.readFully(token);
token = context.acceptSecContext(token, 0, token.length);
// Send a token to the peer if one was generated by
// acceptSecContext
if (token != null) {
System.out.println("Will send token of size "
+ token.length
+ " from acceptSecContext.");
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
}
}
System.out.print("Context Established! ");
System.out.println("Client is " + context.getSrcName());
System.out.println("Server is " + context.getTargName());
if (context.getMutualAuthState())
System.out.println("Mutual authentication took place!");
Как только контекст защиты был установлен между SampleClient и SampleServer, они могут использовать контекст, чтобы надежно обмениваться сообщениями.
Два типа методов существуют для того, чтобы подготовить сообщения к безопасному обмену: wrap и getMIC. Есть фактически два wrap методы (и два getMIC методы), где различиями между этими двумя является индикация относительно того, где входной сигнал (байтовый массив или входной поток) и куда вывод должен пойти (в возвращаемое значение байтового массива или в поток вывода).
Эти методы для того, чтобы подготовить сообщения к обмену, и соответствующие методы для интерпретации коллегой получающихся маркеров, описываются ниже.
wrap метод является основным методом для обменов сообщениями.
Подпись для wrap метод, вызванный SampleClient, является следующим:
byte[] wrap (byte[] inBuf, int offset, interface len,
MessageProp msgProp)
Вы передаете wrap сообщение (в inBuf), смещение в inBuf где сообщение начинается (offset), и длина сообщения (len). Вы также передаете MessageProp, который используется, чтобы указать на требуемый QOP (Качество защиты) и определить, требуется ли конфиденциальность (шифрование). Значение QOP выбирает криптографическую целостность и шифрование (если требующийся) алгоритм (ы), который будет использоваться. Алгоритмы, соответствующие различным значениям QOP, определяются провайдером базового механизма. Например, значения для Kerberos V5 определяются в в разделе 4.2. Распространено определить 0 как значение QOP, чтобы запросить значение по умолчанию QOP.
wrap метод возвращает маркер, содержащий сообщение и криптографический Код Целостности сообщения (MIC) по этому. Сообщение, помещенное в маркер, будет зашифровано, если MessageProp укажет, что конфиденциальность требуется. Вы не должны знать формат возвращенного маркера; это должно быть обработано как непрозрачные данные. Вы отправляете возвращенный маркер своему равноправному приложению, которое вызывает unwrap метод, чтобы "развернуть" маркер, чтобы получить исходное сообщение и проверить его целостность.
Если Вы просто хотите получить маркер, содержащий криптографический Код Целостности сообщения (MIC) для предоставленного сообщения, Вы вызываете getMIC. Демонстрационная причина, которую Вы могли бы хотеть сделать, это должно подтвердить с Вашей коллегой, что у Вас обоих есть те же самые данные, только транспортируя MIC для тех данных, не подвергаясь стоимости переноса данных непосредственно друг другу.
Подпись для getMIC метод, вызванный SampleServer, является следующим:
byte[] getMIC (byte[] inMsg, int offset, int len,
MessageProp msgProp)
Вы передаете getMIC сообщение (в inMsg), смещение в inMsg где сообщение начинается (offset), и длина сообщения (len). Вы также передаете MessageProp, который используется, чтобы указать на требуемый QOP (Качество защиты). Распространено определить 0 как значение QOP, чтобы запросить значение по умолчанию QOP.
Если Вам создали маркер getMIC и сообщение, используемое, чтобы вычислить MIC (или сообщение, подразумеваемое, чтобы быть сообщением, на которое был вычислен MIC), можно вызвать verifyMIC метод, чтобы проверить MIC для сообщения. Если проверка успешна (то есть, если GSSException не бросается), оказывается, что сообщение является точно тем же самым, как это было, когда MIC был вычислен. Коллега, получающая сообщение от приложения обычно, ожидает MIC также, так, чтобы они могли проверить MIC и быть уверены, что сообщение не было изменено или повреждено в пути. Отметьте: Если Вы будете знать заранее это, то Вы будете хотеть MIC так же как сообщение тогда, более удобно использовать wrap и unwrap методы. Но могли быть ситуации, где сообщение и MIC получаются отдельно.
Подпись для verifyMIC соответствие getMIC показанный выше
void verifyMIC (byte[] inToken, int tokOffset, int tokLen,
byte[] inMsg, int msgOffset, int msgLen,
MessageProp msgProp);
Это проверяет MIC, содержавшийся в inToken (длины tokLen, запуск при смещении tokOffset) по сообщению, содержавшемуся в inMsg (длины msgLen, запуск при смещении msgOffset). MessageProp используется базовым механизмом, чтобы возвратить информацию вызывающей стороне, такой как QOP указание на силу защиты, которая была применена к сообщению.
Обмены сообщениями между SampleClient и SampleServer получаются в итоге ниже, сопровождаются деталями кодирования.
Эти шаги являются "стандартными" шагами, используемыми для того, чтобы проверить клиент и сервер GSS-API. Группа в MIT записала клиенту GSS-API и серверу GSS-API, которые стали довольно популярными тестовыми программами для того, чтобы проверить функциональную совместимость между различными реализациями библиотеки GSS-API. (Эти примеры приложения GSS-API могут быть загружены как часть распределения Kerberos, доступного от MIT в .) Этот клиент и сервер от MIT следует за протоколом, что, как только контекст устанавливается, клиент отправляет сообщение через, и это ожидает назад MIC на том сообщении. Если Вы реализуете библиотеку GSS-API, это - обычная практика, чтобы протестировать это, выполняя или клиент или сервер, используя Вашу реализацию библиотеки против соответствующего равноправного сервера или клиента, который использует другую реализацию библиотеки GSS-API. Если обе реализации библиотеки будут соответствовать стандартам, то две коллеги будут в состоянии связаться успешно.
Одна импликация тестирования Вашего клиента или сервера против, записанных в C (как MIT), является способом, которым нужно обменяться маркерами. C реализации GSS-API не включают основанные на потоке методы. В отсутствие основанных на потоке методов на Вашей коллеге, когда Вы пишете маркер, следует сначала записать число байтов и затем записать маркер. Точно так же, когда Вы читаете маркер, Вы первое чтение число байтов и затем читаете маркер. Это - то, что делают SampleClient и SampleServer.
Вот сводка обменов сообщениями SampleClient и SampleServer:
wrap зашифровать и вычислить MIC для сообщения.wrap к SampleServer.unwrap получить исходное сообщение и проверить его целостность.getMIC вычислить MIC на дешифрованное сообщение.getMIC (который содержит MIC) к SampleClient.verifyMIC проверять, что MIC, отправленный SampleServer, является допустимым MIC для исходного сообщения.Код SampleClient для того, чтобы зашифровать сообщение, вычисляя MIC для этого, и отправляя результат SampleServer является следующим:
byte[] messageBytes = "Hello There!\0".getBytes();
/*
* The first MessageProp argument is 0 to request
* the default Quality-of-Protection.
* The second argument is true to request
* privacy (encryption of the message).
*/
MessageProp prop = new MessageProp(0, true);
/*
* Encrypt the data and send it across. Integrity protection
* is always applied, irrespective of encryption.
*/
token = context.wrap(messageBytes, 0, messageBytes.length,
prop);
System.out.println("Will send wrap token of size "
+ token.length);
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
Следующий код SampleServer читает обернутый маркер, отправленный SampleClient, и "разворачивает" это, чтобы получить исходное сообщение и проверить его целостность. Разворачивание в этом случае включает дешифрование, так как сообщение было зашифровано.
Отметьте: Здесь проверка целостности, как ожидают, успешно выполнится. Но отметьте, что вообще, если проверка целостности перестала работать, она показывает, что сообщение было изменено в пути. Если unwrap метод встречается с отказом проверки целостности, он бросает GSSException с главным кодом ошибки GSSException. BAD_MIC.
/*
* Create a MessageProp which unwrap will use to return
* information such as the Quality-of-Protection that was
* applied to the wrapped token, whether or not it was
* encrypted, etc. Since the initial MessageProp values
* are ignored, it doesn't matter what they are set to.
*/
MessageProp prop = new MessageProp(0, false);
/*
* Read the token. This uses the same token byte array
* as that used during context establishment.
*/
token = new byte[inStream.readInt()];
System.out.println("Will read token of size "
+ token.length);
inStream.readFully(token);
byte[] bytes = context.unwrap(token, 0, token.length, prop);
String str = new String(bytes);
System.out.println("Received data \""
+ str + "\" of length " + str.length());
System.out.println("Encryption applied: "
+ prop.getPrivacy());
Затем, SampleServer генерирует MIC для дешифрованного сообщения и отправляет его SampleClient. Это не действительно необходимо, но просто иллюстрирует генерирование MIC на дешифрованном сообщении, которое должно быть точно тем же самым как исходным сообщением SampleClient, обернутый и отправленный SampleServer. Когда SampleServer генерирует это и отправляет это SampleClient, и SampleClient проверяет это, это доказывает SampleClient, что дешифрованное сообщение, которое имеет SampleServer, является фактически точно тем же самым как исходным сообщением от SampleClient.
/*
* First reset the QOP of the MessageProp to 0
* to ensure the default Quality-of-Protection
* is applied.
*/
prop.setQOP(0);
token = context.getMIC(bytes, 0, bytes.length, prop);
System.out.println("Will send MIC token of size "
+ token.length);
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
Следующий код SampleClient читает MIC, вычисленный SampleServer на дешифрованное сообщение, и затем проверяет, что MIC является MIC для исходного сообщения, доказывая, что дешифрованное сообщение, которое имеет SampleServer, является тем же самым как исходным сообщением:
token = new byte[inStream.readInt()];
System.out.println("Will read token of size " + token.length);
inStream.readFully(token);
/*
* Recall messageBytes is the byte array containing
* the original message and prop is the MessageProp
* already instantiated by SampleClient.
*/
context.verifyMIC(token, 0, token.length,
messageBytes, 0, messageBytes.length,
prop);
System.out.println("Verified received MIC for message.");
socket.close(); context.dispose();
Начиная с базовой аутентификации и безопасной коммуникационной технологии, используемой этим учебным руководством, Kerberos V5, мы используем имена принципала стиля Kerberos везде, где пользователь или служба вызываются.
Например, когда Вы выполняете SampleClient, Вас просят обеспечить Ваше имя пользователя. Ваше имя пользователя стиля Kerberos является просто именем пользователя, Вы были присвоены для аутентификации Kerberos. Это состоит из основного имени пользователя (как "mjones") сопровождаемый и Ваша область (как "mjones@KRBNT-OPERATIONS.EXAMPLE.COM").
Программа сервера как SampleServer, как обычно полагают, предлагает "услугу" и выполняется от имени определенного "принципала службы." Имя принципала службы для SampleServer необходимо в нескольких местах:
Всюду по этому документу, и в сопроводительном конфигурационном файле входа в систему,
service_principal@your_realmиспользуется в качестве заполнителя, который будет заменен подлинным именем, которое будет использоваться в Вашей среде. Любой принципал Kerberos может фактически использоваться для имени принципала службы. Так в целях испытать это учебное руководство, Вы могли использовать свое имя пользователя и в качестве клиентского имени пользователя и в качестве имени принципала службы.
В продуктивной среде системные администраторы обычно как серверы, которые будут выполнены, поскольку, определенные принципалы только и могут присвоить определенное имя, которое будет использоваться. Часто присвоенное имя принципала службы стиля Kerberos имеет форму
service_name/machine_name@realm;
Например, у службы nfs, на которой работают машина, названная "вороном" в области под названием "KRBNT-OPERATIONS.EXAMPLE.COM", могло быть имя принципала службы
nfs/raven@KRBNT-OPERATIONS.EXAMPLE.COM
Такие многокомпонентные имена не требуются, как бы то ни было. Единственные имена компонентов, точно так же как таковые из пользовательских принципалов, могут использоваться. Например, установка могла бы использовать тот же самый принципал службы протокола передачи файлов ftp@realm для всех серверов протокола передачи файлов в той области, в то время как у другой установки могли бы быть различные принципалы протокола передачи файлов для различных серверов протокола передачи файлов, такой как ftp/host1@realm и ftp/host2@realm на машинах host1 и host2, соответственно.
Если область пользователя или имени принципала службы является областью значения по умолчанию (см. Требования Kerberos), можно бросить область, когда Вы регистрируете в Kerberos (то есть, когда Вы запрашиваетесь Ваше имя пользователя). Таким образом, например, если Ваше имя пользователя "mjones@KRBNT-OPERATIONS.EXAMPLE.COM", и Вы выполняете SampleClient, когда это запрашивает Ваше имя пользователя, Вы могли только определить "mjones", бросая область. Имя интерпретируется в контексте того, чтобы быть именем принципала Kerberos, и область значения по умолчанию добавляется, как необходимый.
Можно также бросить область, если основное имя будет преобразовано в GSSName GSSManager createName метод. Например, когда Вы выполняете SampleClient, одним из параметров является имя принципала серверной службы. Можно определить имя без включения области, потому что SampleClient передает имя к такому createName метод, который добавляет область значения по умолчанию как необходимый.
Рекомендуется, чтобы Вы всегда включали области, когда основные имена используются в конфигурационных файлах входа в систему и файлах политики, потому что поведение синтаксических анализаторов для таких файлов может быть зависящим от реализации; они могут или, возможно, не добавляют область значения по умолчанию прежде, чем такие имена будут использованы, и последующие действия могут перестать работать, если нет никакой области на имя.
Для этого учебного руководства мы позволяем базовому механизму Kerberos получать учетные данные пользовательского выполнения SampleClient и SampleServer, вместо того, чтобы вызывать методы JAAS непосредственно (как в Аутентификации JAAS и учебных руководствах по Авторизации JAAS) или косвенно (например, через утилиту Login, описанную в Использовании учебного руководства по Утилите Входа в систему JAAS и в Использовании Утилиты Входа в систему JAAS и GSS-API Java для Безопасного учебного руководства по Обменам сообщениями).
Значение по умолчанию реализация механизма Kerberos, предоставленная Sun Microsystems фактически, запрашивает имя и пароль Kerberos и аутентифицирует указанного пользователя (или служба) к Kerberos KDC. Механизм полагается на JAAS, чтобы выполнить эту аутентификацию.
JAAS поддерживает сменную платформу аутентификации, означая, что любой тип модуля аутентификации может быть включен в соответствии с вызывающим приложением. Конфигурация входа в систему определяет модуль входа в систему, который будет использоваться для определенного приложения. Реализация JAAS значения по умолчанию от Sun Microsystems требует, чтобы конфигурационная информация входа в систему была определена в файле. (Отметьте: у Некоторых других поставщиков не могло бы быть основанных на файле реализаций.) Видят Конфигурационный файл Входа в систему JAAS для информации относительно того, каков конфигурационный файл входа в систему, что это содержит, и как определить, какой конфигурационный файл входа в систему должен использоваться.
Для этого учебного руководства, модуля входа в систему Kerberos com.sun.security.auth.module.Krb5LoginModule определяется в конфигурационном файле. Этот модуль входа в систему запрашивает имя и пароль Kerberos и попытки аутентифицировать к Kerberos KDC.
И SampleClient и SampleServer могут использовать тот же самый конфигурационный файл входа в систему, если тот файл содержит две записи, одну запись для стороны клиента и один для стороны сервера.
Конфигурационный файл входа в систему bcsLogin.conf, используемый для этого учебного руководства, является следующим:
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required;
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required storeKey=true
};
Записи с этими двумя именами (com.sun.security.jgss.initiate и com.sun.security.jgss.accept) используются реализациями Sun механизмов GSS-API, когда они нуждаются в новых учетных данных. Так как механизмом, используемым в этом учебном руководстве, является Kerberos механизм V5, модуль входа в систему Kerberos должен будет быть вызван, чтобы получить эти учетные данные. Таким образом мы перечисляем Krb5LoginModule как необходимый модуль в этих записях. com.sun.security.jgss.initiate запись определяет конфигурацию для стороны клиента и com.sun.security.jgss.accept запись для стороны сервера.
Krb5LoginModule успешно выполняется, только если попытка войти в систему к Kerberos KDC как указанный объект успешна. Выполняя SampleClient или SampleServer, пользователь будет запрошен имя и пароль.
Запись SampleServer storeKey=true указывает, что секретный ключ должен быть вычислен от пароля, обеспеченного во время входа в систему, и это должно быть сохранено в частных учетных данных Предмета, создаваемого в результате входа в систему. Этот ключ впоследствии используется во время взаимной аутентификации, устанавливая контекст защиты между SampleClient и SampleServer.
Для получения информации обо всех возможных вариантах, которые можно передать к Krb5LoginModule, см. документацию Krb5LoginModule.
Для этого учебного руководства мы устанавливаем системное свойство javax.security.auth.useSubjectCredsOnly к false, который позволяет нам ослаблять обычное ограничение требования, чтобы механизм GSS получил необходимые учетные данные из существующего Предмета, установленного JAAS. Когда это ограничение ослабляется, оно позволяет механизму получать учетные данные из некоторого специфичного для поставщика расположения. Например, некоторые поставщики могли бы хотеть использовать кэш операционной системы, если Вы существуете, в то время как другие могли бы хотеть читать из защищенного файла на диске.
Когда это ограничение ослабляется, Микросистема Sun, механизм Kerberos все еще ищет учетные данные в Предмете, связанном с контекстом управления доступом потока, но если это не находит никого там, это выполняет аутентификацию JAAS, используя модуль Kerberos, чтобы получить новые. Модуль Kerberos запрашивает Вас имя и пароль принципала Kerberos. Отметьте, что реализации механизма Kerberos от других поставщиков могут вести себя по-другому, когда это свойство устанавливается в false. Консультируйтесь с их документацией, чтобы определить поведение их реализации.
Чтобы выполнить программы SampleClient и SampleServer, сделайте следующее:
Чтобы подготовить SampleServer к выполнению, сделайте следующее:
SampleServer.java: javac SampleServer.java
Чтобы подготовить SampleClient к выполнению, сделайте следующее:
SampleClient.java: javac SampleClient.java
Важно выполнить SampleServer перед SampleClient, потому что SampleClient попытается сделать сокетное соединение с SampleServer, и это перестанет работать, если SampleServer еще не выполнит и примет сокетные соединения.
Чтобы выполнить SampleServer, убедиться, что выполнили это на машине, на этом, как ожидают, будут работать. Это машинное имя (имя хоста) определяется как параметр SampleClient. Имя принципала службы появляется в нескольких местах, включая конфигурационный файл входа в систему и файлы политики.
Пойдите в каталог, в котором Вы подготовили SampleServer к выполнению. Выполните SampleServer, определяя
-Djava.security.krb5.realm=<your_realm> то, что Ваша область Kerberos является определенной той. Например, если Ваша область "KRBNT-OPERATIONS.EXAMPLE.COM", Вы поместили -Djava.security.krb5.realm=KRBNT-OPERATIONS.EXAMPLE.COM.-Djava.security.krb5.kdc=<your_kdc> то, что Ваш Kerberos KDC является определенным тем. Например, если Ваш KDC "samplekdc.example.com", Вы поместили -Djava.security.krb5.kdc=samplekdc.example.com.-Djavax.security.auth.useSubjectCredsOnly=false то, что базовый механизм может решить, как получить учетные данные. См. useSubjectCredsOnly Системное Свойство.-Djava.security.auth.login.config=bcsLogin.conf то, что конфигурационный файл входа в систему, который будет использоваться, bcsLogin.conf.Единственным параметром, требуемым SampleServer, является тот, определяющий номер порта, который будет использоваться для того, чтобы прислушаться к клиентским соединениям. Выберите высокий номер порта вряд ли, чтобы использоваться для чего-либо еще. Пример был бы чем-то как 4444.
Ниже полная команда, чтобы использовать и для Microsoft Windows и для систем Unix.
Важный: В этой команде следует заменить <port_number> с соответствующим номером порта, <your_realm> с Вашей областью Kerberos, и <your_kdc> с Вашим Kerberos KDC.
Вот команда:
java -Djava.security.krb5.realm=<your_realm> -Djava.security.krb5.kdc=<your_kdc> -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=bcsLogin.conf SampleServer <port_number>
Полная команда должна появиться на одной строке (или, на системах UNIX, на многократных строках, где каждая строка, но последнее завершается с "\" указание, что есть больше, чтобы прибыть). Многократные строки используются здесь только для четкости. Так как эта команда очень длинна, Вы, возможно, должны поместить ее в.bat файл (для Windows) или.sh файл (для UNIX) и затем петлять, чтобы выполнить команду.
SampleServer код прислушается к сокетным соединениям на указанном порту. Когда запрошено, введите имя и пароль Kerberos для принципала службы. Базовый механизм аутентификации Kerberos, определенный в конфигурационном файле входа в систему, зарегистрирует принципал службы в Kerberos.
Для предложений поиска и устранения неисправностей входа в систему см. Поиск и устранение неисправностей.
Чтобы выполнить SampleClient, сначала пойдите в каталог, в котором Вы подготовили SampleClient к выполнению. Выполните SampleClient, определяя
-Djava.security.krb5.realm=<your_realm> то, что Ваша область Kerberos является определенной той.-Djava.security.krb5.kdc=<your_kdc> то, что Ваш Kerberos KDC является определенным тем.-Djavax.security.auth.useSubjectCredsOnly=false то, что базовый механизм может решить, как получить учетные данные.-Djava.security.auth.login.config=bcsLogin.conf то, что конфигурационный файл входа в систему, который будет использоваться, bcsLogin.conf.Параметры SampleClient (1) имя Kerberos принципала службы, который представляет SampleServer, (2) имя узла (машина), на которой SampleServer работает, и (3) номер порта, на котором SampleServer прислушивается к клиентским соединениям.
Ниже полная команда, чтобы использовать и для Windows и для систем Unix.
Важный: В этой команде следует заменить <service_principal>, <host>, <port_number>, <your_realm>, и <your_kdc> с соответствующими значениями (и примечание, что номер порта должен быть тем же самым как номером порта, который передают как параметр SampleServer). Эти значения не должны быть помещены в кавычки.
Вот команда:
java -Djava.security.krb5.realm=<your_realm> -Djava.security.krb5.kdc=<your_kdc> -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.auth.login.config=bcsLogin.conf SampleClient <service_principal> <host> <port_number>
Введите полную команду на одной строке. Многократные строки используются здесь для четкости. Как с командой для того, чтобы выполнить SampleServer, если команда является слишком длинной, чтобы ввести непосредственно в Ваше окно команд, поместите это в.bat файл (Windows) или.sh файл (UNIX) и затем выполните тот файл.
Когда запрошено, введите свое имя пользователя Kerberos и пароль. Базовый механизм аутентификации Kerberos, определенный в конфигурационном файле входа в систему, зарегистрирует Вас в Kerberos. Код SampleClient запрашивает сокетное соединение с SampleServer. Как только SampleServer принимает соединение, SampleClient и SampleServer устанавливают совместно используемый контекст и затем обмениваются сообщениями как описано в этом учебном руководстве.
Для предложений поиска и устранения неисправностей входа в систему см. Поиск и устранение неисправностей.
|
|
