Manjula Peiris wrote:
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 you are trying to keep the implementation simple, you can
de-serialize the node from string at each and every call using a stax
builder. You may have a look at the function
oxs_axiom_deserialize_node() in omxmlsec/axiom.c
But this is not a very nice design compared to what Manjula has suggested.
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]
--
http://kaushalye.blogspot.com/
http://wso2.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
