Hi Nandana,
Thanks for your suggestions. I think I understand the phase stuff a
bit better and I do have policy attached at the operation level
(AsymmetricBinding, include timestamp) and at the input message level to
sign the body. Rampart seems to be engaged on both the client and server
sides. Successful reply messages include a signed header with a time
stamp, but fault messages do not have a soap header, just a body with
the soap fault.
I was following another thread of yours about how security faults are
not signed. I see messages with no soap headers where the soapfault
Value is Sender and the subcode value is InvalidSecurity. My client is
happy with that. But when my service code throws a fault, the soapfault
is Receiver, but the message also does not have a soap header. The
client then objects that there is not a soap header element, which seems
like correct behavior on the client's part.
Do you have any suggestions as to what could be wrong that would cause
the outFlow messages have signed headers but the outFaultFlow message
with Receiver faults to not have?
The conf/axis2.xml file in the axis war has
<phaseOrder type="OutFaultFlow">
<!-- user can add his own phases to this area -->
<phase name="soapmonitorPhase"/>
<phase name="OperationOutFaultPhase"/>
<phase name="RMPhase"/>
<phase name="PolicyDetermination"/>
<phase name="MessageOut"/>
<phase name="Security"/>
</phaseOrder>
the module.xml in my rampart mar has
<OutFaultFlow> <handler name="PolicyBasedSecurityOutHandler"
class="org.apache.rampart.handler.RampartSender">
<order phase="Security" phaseLast="true"/>
</handler>
</OutFaultFlow>
Is there something else that needs to be set?
Thanks for any insights
Mary
Nandana Mihindukulasooriya wrote:
Hi Mary,
I think best way to solve this problem is to use message level
policies. You can attach policies at message level, so they will be
effective either on in the in flow or our flow. But still we have the
problem that we can't specify policies for fault flows, For example, if
we specify a policy for in message it will be applicable for both in
message and in fault messages.
In Axis2 , we have two kinds phases global phases and operation
phases. This article [1] by Deepal explains the whole concept. Phases
before dispatch phases are known as global phases and they will be
called for each and every message. Security is a global phase. We need
security as a global phase become dispatching mechanism like body based
dispatching which used to dispatch operations need messages to be
decrypted before they can act on the message. But having the security
phase doesn't have any effect if rampart is not engaged. As it is
described in the article, it is the rampart module that adds handlers to
the phase. Even if the Rampart is engaged, if the effective security
policy of the message is null, then those handlers will not have any effect.
thanks,
nandana
[1] - http://www.packtpub.com/article/handler-and-phase-in-apache-axis
On Sat, Oct 25, 2008 at 4:17 AM, Mary Thompson <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I ran into the same problem when I switched to ws-policy. First I
had to add the security phase to infaultflow and then the unsigned
fault messages were not acceptable. I "fixed" it by moving the
security phase in the infaultflow to the end the phase order after
OperationInFaultPhase effectively causing it to be ignored.
I wonder if the piece of code that insists you add a security phase
when you don't want any security is wrong. Or if there is some way
to indicate a null security phase.
Mary Thompson
RonnieMJ wrote:
Ok I added an axis2.xml file in my repo, however commenting out
any Security
phase causes errors indicating that the Security phase is missing.
I'm wondering if you would ALSO have to remove any phase info
from the
modules.xml file in the rampart mar?
In this case I'm the client, but receiving a response. Wouldn't
I want to
remove the security phase from the InFlow not out?
Chris82KS wrote:
Hello,
inside the axis2.xml you have the different flows (inFlow,
OutFlow,
InFault and OutFault). Just remove the phase "Security" from
the OutFlow
and the OutFaultFlow.
Greetings
Christian
----- original Nachricht --------
Betreff: Rampart one way only
Gesendet: Do, 23. Okt 2008
Von: RonnieMJ<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Is it possible to have rampart NOT be concerned with
security on a return
message in a synchronous transaction?
Example:
I send to server X with security headers. They return
an OK message or a
fault. Neither of which would have security heading
information.
--
View this message in context:
http://www.nabble.com/Rampart-one-way-only-tp20133511p20133511.html
Sent from the Axis - User mailing list archive at
Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--- original Nachricht Ende ----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
