Hi Jamie, See my commnets in line.
On Tue, 2007-08-21 at 11:58 +0100, Jamie Lyon wrote: > Hi, > > See my reply below. > > > -----Original Message----- > > > I now still have the problem of actually setting the SAML token. All > the > > > functions to do so are in rampart_context.c/h, but how to I access > the > > > context to set the token? I can access it by getting it out of the > > > message context, but I'm unsure how to get the message context. I'm > not > > > sure if it's only created when you call, for example, > > > axis2_svc_client_send_receive, or whether you can somehow access it > > > beforehand. > > > > > > In your list of suggestions you mention passing the new > rampart_context > > > as a parameter to rampart through rampart_context? I'm not sure if > this > > > is a typo, as I can't see any function within rampart_context that > > > doesn't require an already existing rampart_context to modify? > > > > Yes this is a typing error. It should be corrected as pass the > > rampart_cotext as a parameter named RAMPART_CONFIGURATION to rampart > > through msg_ctx. Sorry for confusing you on this. > > > > To pass the rampart_context through the msg_ctx you can do the > following. > > > > 1.Get the svc from svc_ctx from svc_client. > > 2.Get the conf_ctx from svc_ctx. > > 3 Get the axis2_conf from conf_ctx. > > 4 Set the parameter in conf using the function. > > axis2_conf_add_param > > I've done this, and have now got the assertions being included in the > message, I have a few queries/problems however. > > I've got the saml token stored as an axiom_node within rampart_context, > and I add it into the sec_node as a child within > rampart_saml_token_build (called by rampart_shb_build_message). > Unfortunately this means that when the sec_node is destroyed at the end > of a message send, the SAML token is destroyed too. So is there a way of > duplicating an axiom_node so that I can add a clone into the sec_node > instead. No there is no such method. But why are you storing the saml token as an axiom_node within the rampart_context? Cant't you keep the information related to saml_token as a basic type or a user defined type. So that inside rampart you can build the saml node using this information in rampart_context. So for the next request you can alter those information as you wish and rampart will build the saml node accoarding to the new information. > > If there's not a way of duplicating them, like there is with attributes > and namespaces, then I'll have to write a clone function myself. If I do > have to do this, are there any pointers you'd like to share? IMHO duplicating a node make no sense. Because a node always attached to a om_tree. We are keeping shallow copies to the nodes in the tree. > Also, when creating the rampart_context, is there a way to tell it to > load default data from the policy.xml file? At present I'm just > hardcoding values for the default timeout, etc.. If you are not using a policy file that means those options are need to be set by the user. This is useful when rampart is used from other extensions like PHP. But for timeout there is a default value. But other information are user specific so you need to set them using the set functions in rampart_context. > Once this is all working, I'll send the diffs, though I doubt the > current implementation is suitable for including into the axis source > tree. Thats ok. Please send the patches. Thanks. -Manjula. > > --------------------------------------------------------------------- > 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]
