Re: [OpenSPCoop-Dev] Re: Modalità d'integrazione dei servizi applicativi

["Domenico Loiacono" <dloiacono@gmail.com>]

> Il problema e' dovuto al fatto che il client sta usando mustUnderstand=1
> e Actor non specificato. Questo puo' andar bene in un'interazione SOAP
> peer to peer, ma non va bene se ci sono dei nodi intermediari che non
> devono interpretare l'header, come avviene in questo caso per le Porte
> di Dominio.
>
> Per risolvere il tuo problema dovrebbe quindi essere sufficente
> introdurre un actor nell'header WSSecurity prodotto dal client, oppure
> specificare il mustUnderstand=0, che rende legale il fatto che la Porta
> di Dominio ignori l'header in questione.

Introdurre un actor sull'header WSSecurity o porre l'attributo mustUnderstand=0, significherebbe però imporre questa regola a tutti i client a livello di specifiche di integrazione, affinchè la implementino, con la conseguenza che in alcuni casi potrebbe risultare molto complesso intervenire nei framework dei servizi applicativi a livello di sicurezza per modificare l'attributo mustUnderstand ( p.es. client applicativi .NET (WCF)).

> In alternativa, se non puoi intervenire sugli applicativi, puoi fare in
> modo che la PdD ignori comunque l'header, aggiungendo un handler che
> marchi l'header WSS come gestito. Se vuoi fare cosi', ti basta agire sul
> file:
>
>  'deploy/pdd/deploy_axis/web_app/WEB-INF/server-config.wsdd'

Questa seconda alternativa, già utilizzata nel post http://www.openspcoop.org/pipermail/sviluppatori/msg00092.html in riferimento alla PA, in effetti è quella che abbiamo utilizzato nei nostri scenari di test per ovviare al problema e ci sembra la strada preferibile per non intervenire sui servizi applicativi ed evitare di aggiungere complessità nell'integrazione dei client.

Nel caso in cui la situazione, actor non specificato e mustUnderstand=1, si verificasse per altri tipi di header, occorrerebbe per quanto detto aggiungere ulteriori "bypass". E' corretto ?

 

 

Domenico

Il 22/03/07, Andrea Poli<apoli@link.it> ha scritto:
> > Domenico Loiacono wrote:
> >
> > ...
> > in contesti applicativi in cui è definita una politica di sicurezza per cui è richiesto lo scambio di token di
> > autenticazione/autorizzazione all'interno di messaggi soap attraverso
> > header WS-Security, i test hanno evidenziato un blocco dei messaggi
> > sulla porta delegata in quanto la stessa ne ha tentato l'interpretazione.
> > .....
> > .....
>
> > In breve, per migliore fruizione, si riporta la sola sezione del log
> > che riporta il trace dell'errore applicativo:
>
> > ........
> > 2007-03-20 09:58:49,343 DEBUG [org.apache.axis.EXCEPTIONS ] AxisFault:
> > AxisFault
> > faultCode: {http://schemas.xmlsoap.org/soap/envelope/}MustUnderstand <http://schemas.xmlsoap.org/soap/envelope/%7DMustUnderstand>
> > faultSubcode:
> > faultString: Did not understand &quot;MustUnderstand&quot;
> > header(s):{ http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security < http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd%7DSecurity>
> > .......
>
>
> Il problema e' dovuto al fatto che il client sta usando mustUnderstand=1
> e Actor non specificato. Questo puo' andar bene in un'interazione SOAP
> peer to peer, ma non va bene se ci sono dei nodi intermediari che non
> devono interpretare l'header, come avviene in questo caso per le Porte
> di Dominio.
>
> Per risolvere il tuo problema dovrebbe quindi essere sufficente
> introdurre un actor nell'header WSSecurity prodotto dal client, oppure
> specificare il mustUnderstand=0, che rende legale il fatto che la Porta
> di Dominio ignori l'header in questione.
>
> In alternativa, se non puoi intervenire sugli applicativi, puoi fare in
> modo che la PdD ignori comunque l'header, aggiungendo un handler che
> marchi l'header WSS come gestito. Se vuoi fare cosi', ti basta agire sul
> file:
>
>  'deploy/pdd/deploy_axis/web_app/WEB-INF/server- config.wsdd'
>
> aggiungendo la riga:
>
> '<handler name="WSBypassMustUnderstand"
> type="java:org.openspcoop.wssecurity.WSBypassMustUnderstandHandler"/>'
> al servizio 'RicezioneContenutiApplicativi'. La definizione del servizio
> diventa quindi:
>
> <!-- Servizio di ricezione Richieste Interne -->
> <service name="PD" provider="java:MSG" style="wrapped" use="literal">
>    <requestFlow>
>       <handler name="WSBypassMustUnderstand"
> type="java:org.openspcoop.wssecurity.WSBypassMustUnderstandHandler"/>
>       <handler type="IdentificazioneParametriPD"/>
>       <handler type="Authentication"/>
>    </requestFlow>
>    <responseFlow>
>       <handler type="EsitoInvocazione"/>
>    </responseFlow>
>    <parameter name="allowedMethods" value="OpenSPCoop_PD"/>
>    <parameter name="FullMessageService" value="true"/>
>    <parameter name="className"
> value="org.openspcoop.pdd.services.RicezioneContenutiApplicativiWS"/>
>  </service>
>  <!-- Servizio di ricezione Richieste Interne -->
>
> Dopo la modifica va ovviamente rifatto il deploy di OpenSPCoop.
>
> Andrea.
> _______________________________________________
> Sviluppatori mailing list
> Sviluppatori@openspcoop.org
> http://www.openspcoop.org/mailman/listinfo/sviluppatori
>


--
Domenico Loiacono