Hi Chamikara, Basically, what we are trying to do is this. When the first invocation passes the security handler, the handler checks the user credentials. If the username/password is valid, the userprofile is retrieved from Ldap and stored in a context for future reference.
>From the security handler we cannot store it in the message context. The >callback interface does not give a handle to the message context. This leaves us with the following questions. How can we store the userprofile in the current messagecontext? Also, why does sandesha skip the security phase when resuming a message in the InOrderInvoker? Thanks, Lennard. ----- Original Message ----- From: Chamikara Jayalath <[EMAIL PROTECTED]> Date: Thursday, August 3, 2006 11:31 am Subject: Re: [Axis2] Sandesha2 and Rampart module > Hi Lennard, > > I'm not fully getting it. What do u mean by a Security Context. To my > knwoedge security handler saves all the information to the message > context. > The storage framework should not loose any information when saving and > retrieving information. In the in-memory implementation Message > Context is > simply stored in a HashMap and properties and all other information > shouldbe there when the message is resumed. > > R u saying that some of these properties are lost when the message is > resumed by the Sandesha2 InOrderInvoker ? > > Chamikara > > > On 8/3/06, L YSSELSTEIN <[EMAIL PROTECTED]> wrote: > > > > Hi Chamikara, > > > > Ok, I understand. > > During debugging I can see the first invocation to be passed > through the > > security phase. > > The problem is that during the security phase the security > handler is > > adding user information to a acegi security context. > > This context only exists during each invocation. > > Because during the second invocation this security handler is not > called,> no user information is available. Because of this the soap > call cannot be > > processed correctly. > > Can we add the user information to the storage framework of > sandesha2?> > > Thanks, > > > > Lennard. > > > > ----- Original Message ----- > > From: Chamikara Jayalath <[EMAIL PROTECTED]> > > Date: Thursday, August 3, 2006 5:30 am > > Subject: Re: [Axis2] Sandesha2 and Rampart module > > > > > Hi Lennard, > > > > > > There is no way a message could reach the RM Phase without going > > > trough the > > > global phases (this include Transport, Security, Dispatch phases). > > > If you > > > have enable In-Order invocation in Sandesha2 (which is the > > > default), it has > > > following behaviour. > > > > > > Every incoming application will be paused at the RMPhase. So in > the> > firstinvocation the messages will go through the Global > Phases and the > > > Application Phases upto the RM Phase. Later Sandesha2 will invoke > > > application message in the order of Message Numbers. So if you are > > > monitorning in the second invocation you will only see a set of > > > Applicationlevel Phases. But this message must have gone through > > > the Security Phase in > > > its first invocation. Therefore this does not produce a > security hole. > > > > > > Chamikara > > > > > > > > > > > > On 8/2/06, Lennard IJsselstein <[EMAIL PROTECTED]> > wrote:> > > > > > > Hi Ruchith, > > > > > > > > I also expected the phases you mentioned. But when I check the > > > > executionChain in the messagecontext while debugging I only > see the > > > > phases I mentioned before. For some reason sandesha2 alters the > > > phases> of the messages during invocation. > > > > > > > > Before sandesha2 was added the execution chain was as you > described.> > > > > > > Thanks, > > > > > > > > Lennard. > > > > || > > > > Ruchith Fernando wrote: > > > > > > > > > Hi Lennard, > > > > > > > > > > On 8/2/06, Lennard IJsselstein <[EMAIL PROTECTED]> > > > wrote:> > > > > > >> Hi all, > > > > >> > > > > >> We are currently using both the Sandesha2 and the Rampart > module.> > > >> The problem we are facing now is when we send a > webservice> > call the > > > > >> following happens: > > > > >> - The CreateSequence soapmessage is send to the Axis2 servlet > > > and is > > > > >> correctly processed. > > > > >> As expected the following axis2 phases are hit: > > > > >> Transport, Security, RMPhase OperationInPhase > > > > >> - The soapmessage with the actual webservice call is send to > > > the Axis2 > > > > >> servlet. > > > > >> The following phases are hit: > > > > >> soapmonitorPhase, RMPhase, OperationInPhase. > > > > >> - The TerminateSequence soapmessage is send to the Axis2 > > > servlet and is > > > > >> correctly processed. > > > > >> As expected the following axis2 phases are hit: > > > > >> Transport, Security, RMPhase, OperationInPhase > > > > >> > > > > >> Our question is: > > > > >> Why does the 'normal' soapmessage not run through the > > > Security> >> phase? > > > > > > > > > > > > > > > IMHO the request message should go through the following > phases : > > > > > Transport, Security, PreDispatch, Dispatch, OperationInPhase > > > > > > > > > > Transport and Dispatch phases are used to dispatch and since > > > you have > > > > > not mentioned any of these in the phases that the soap message > > > hit I > > > > > wonder how the request reached the OperationInPhase. > > > > > > > > > > Thanks, > > > > > Ruchith > > > > > > > > > > > > > -------------------------------------------------------------- > ---- > > > --- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > --- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
