Вызов веб-сервиса.NET (WSE 2/3, безопасность WS) от Java

Debian - это управляемая systemd операционная система. В контейнере по умолчанию отсутствует демон systemd для PID-1.

Старые init-скрипты «restart» пересылаются в «systemctl restart», и systemctl хочет общаться с демоном systemd. Вот откуда приходит сообщение об ошибке.

Решения будут

  • использовать контейнерную операционную систему, которая не управляется системой
  • , запустить systemd в контейнере или перенаправить запросы на хост systemd
  • [ 113] использовать docker-systemctl-replace для обработки выполнения systemctl без systemd

22
задан Michael Sharek 19 August 2008 в 15:54
поделиться

5 ответов

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

Кажется, что сервисы, созданные в.NET, следуют более старому стандарту ws-обращения (http://schemas.xmlsoap.org/ws/2004/03/addressing/), и axis2 только понимает более новый стандарт (http://schemas.xmlsoap.org/ws/2004/08/addressing/).

Кроме того, policyCache.config обеспеченный файл находится в форме, которую не может понять модуль крепостного вала axis2.

Так шаги мы должны были сделать, вкратце:

  • Считайте policyCache.config и попытайтесь понять это. Затем перепишите его в политику, которую мог понять крепостной вал. (Помогают некоторым обновленным документам.)
  • Настройте крепостной вал с этой политикой.
  • Возьмите ключи, которые были обеспечены в .pfx файле и преобразовывают их в базу ключей Java. Существует утилита, которая идет с Причалом, который может сделать это.
  • Настройте крепостной вал с той базой ключей.
  • Запишите пользовательский axis2 обработчик, который назад - преобразовывает более новый материал ws-обращения, который выходит из axis2 в более старый материал, ожидаемый сервисом.
  • Настройте axis2 для использования обработчика на исходящих сообщениях.

В конце это было много конфигурации и кода для чего-то, что, как предполагается, является открытым стандартом, поддерживаемым поставщиками.

Хотя я не уверен, что альтернатива..., можно ли ожидать поставщиков (или в этом случае, одного поставщика), чтобы удостовериться, что все будет inter-op?

Как постскриптум я добавлю, что не заканчивал тем, что делал работу, это был кто-то еще в моей команде, но я думаю, что получил существенные корректные детали. Другая возможность, которую я рассматривал (прежде чем мой товарищ по команде вступил во владение) состояла в том, чтобы назвать WSS4J API непосредственно для построения конверта SOAP, поскольку сервис.NET ожидал это. Я думаю, что это работало бы также.

10
ответ дан 29 November 2019 в 05:32
поделиться

@Mike

я недавно сделал тест и это - код, который я использовал. Я не использую материал политики, но я использовал безопасность WS с аутентификацией простого текста. CXF имеет действительно хорошую документацию относительно того, как выполнить этот материал.

я использовал wsdl2java и затем добавил этот код для использования веб-сервиса с ws-безопасностью.

я надеюсь, что это выручает Вас.

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;

import org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor;
import org.apache.ws.security.WSConstants;
import org.apache.ws.security.WSPasswordCallback;
import org.apache.ws.security.handler.WSHandlerConstants;

public class ServiceTest implements CallbackHandler
{

     public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {

            WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
            // set the password for our message.
            pc.setPassword("buddah");
        }

    public static void main(String[] args){
        PatientServiceImplService locator = new PatientServiceImplService();
        PatientService service = locator.getPatientServiceImplPort();

        org.apache.cxf.endpoint.Client client = org.apache.cxf.frontend.ClientProxy.getClient(service);
        org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint();

        Map<String, Object> outProps = new HashMap<String, Object>();
        outProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN + " " +  WSHandlerConstants.TIMESTAMP);
        outProps.put(WSHandlerConstants.USER, "joe");
        outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);

        // Callback used to retrieve password for given user.
        outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS, ServiceTest.class.getName());

        WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
        cxfEndpoint.getOutInterceptors().add(wssOut);


        try
        {
            List list = service.getInpatientCensus();
            for(Patient p : list){
                System.out.println(p.getFirstName() + " " + p.getLastName());
            }

        }
        catch (Exception e)
        {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}
3
ответ дан 29 November 2019 в 05:32
поделиться
2
ответ дан 29 November 2019 в 05:32
поделиться

CXF - я изучил бы CXF. Я использовал его для создания веб-сервиса и клиента в Java с помощью ws-secuirty. Я также подключил .net веб-сервис к нему.

у Них есть довольно хорошая документация также. У меня было больше удачи с ним, чем ось.

0
ответ дан 29 November 2019 в 05:32
поделиться

Спецификации безопасности WS обычно не содержатся в WSDL (никогда в WSDL WSE). Таким образом, wsdl2java не знает, что безопасность WS даже требуется для этого сервиса. То, что ограничения безопасности не присутствуют в WSDL WSE, является большим разочарованием мне (WCF будет включать информацию о WS-Trust в WSDL).

На клиентском конце, необходимо будет использовать Крепостной вал для добавления необходимых Заголовков защиты WS к исходящему клиентскому сообщению. Так как WSDL не сообщает, какие Настройки безопасности WS необходимы, Вы лучше всего выключены путем выяснения у поставщика услуг, что требуется. Требования к защите WS могут быть простым незашифрованным паролем, или могли бы быть сертификатами X509 или могли бы быть зашифрованным сообщением..... Крепостной вал должен быть в состоянии обработать большинство этих сценариев.

Крепостной вал Apache "включен" путем привлечения модуля в axis2.xml файле. Необходимо будет загрузить модуль Крепостного вала и положить его на определенное место в axis2 каталоге, затем изменить xml файл. Можно также затронуть Крепостной вал программно (отредактируйте исходный вопрос, если это - требование, и я отредактирую этот ответ).

В зависимости от того, как Вы настраиваете крепостной вал (через другие XML-файлы или программно), он прервет любые исходящие сообщения и добавит необходимую Информацию о безопасности WS к нему. Я лично использовал axis2 с крепостным валом для вызова сервиса WSE3, который защищается с UsernameToken в простом тексте, и это работало отлично. Подобные, но более усовершенствованные сценарии должны также работать. Существует больше деталей о том, как настроить и начать с Крепостным валом на сайте, связанном выше. Если у Вас есть проблемы о специфических особенностях Крепостного вала или как использовать Крепостной вал с Вашей конкретной установкой WSE, то отредактируйте свой вопрос, и я буду стараться изо всех сил отвечать.

10
ответ дан 29 November 2019 в 05:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: