Hi, See my comments inline (and apologies for the rather large e-mail!) > Hi, > I don't think obtaining a pointer of rampart_context would be useful here. > Let me show you a way to do this. For that you may follow these steps. > 1. Define policy assertions in your client's policy file. You may see > the section 6.3.8 of WS-SecurityPolicy specification[1]. > 2. You need to implement new functions in rampart context to interpret > policy assertions (defined in step1).
Okay, I can do this part, however after reading the ws-securitypolicy specification it seems that this particular assertion in the policy only specifies that a SAML token should exist, not how it's obtained, or attached. I presume this would just be used to check that the SAML token obtained via other means is present and valid? > 3. Write a SAML assertion building module(e.g. in rampart_saml.c Just > like in rampart_username_token.c) > 4. Extend the rampart_shb_build_message() function to support inclusion > of SAML tokens using the SAML assertion building module. This part I'm sure should be okay too. > If I understand your requirement correctly, you can get it done using > attaching a new policy object(with different SAML related policies) for > each and every call. > See the function axis2_svc_client_set_policy() in the echo sample. That > way you can change the SAML token after every message. > Further, if there are configurations, which cannot be supported only > with assertions defined in the specification, you may define 'em under > <rampc:RampartConfig> in the client's policy. Now, this part I have a query about -- you seem to be implying that configuration of the SAML token should be done via the policy.xml file. This likely isn't much use, since I'm not sure about other systems but the one I am interfacing with sends a SAML token after you request one via other means; so hard-coding it in the policy.xml file is not an option. If it's okay with you, let me run through a few quick assumptions about the way the current code works from what I have learned from running through the code. Just to make sure I have the correct idea. The policy is stored within msg_ctx, then within rampart_engine_build_configuration it is converted into a neethi_policy by build_policy then into a rp_secpolicy by rp_secpolicy_builder_build. It's then converted into a rampart_context and returned. Now the problem here is the rampart configuration in the policy itself seems to be a set of assertions, it does not seem as though I can easily attach extra information to it without some form of dirty hack (which certainly wouldn't be acceptable to include in the trunk). It looks as though the custom rampart configuration is parsed in rp_rampart_config_builder_populate, and is stored as an assertion within neethi_policy, but what would be the proper way to add new things in code? Should I just create a new neethi_assertion with an assertion type of ASSERTION_TYPE_RAMPART_CONFIG and then use that? If so would it then be correct to set the SAML as a neethi_assertion_set_element? And how then do you attach it to the policy -- using neethi_policy_add_policy_components? If so, that's all fine, but then how do you remove/change it? There doesn't appear to be any way to remove part of a neethi_policy. And finally (apologies for the long e-mail, but if I'm going to do this, I may as well do it properly), just having the user alter the neethi_policy manually seems rather dirty. Would helper functions to do it for them be an idea, or have I got the whole methodology here incorrect? Thanks, Jamie > HTH... :) > Cheers, > Kaushalye > > [1] http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws- > securitypolicy.pdf > > Jamie Lyon wrote: > > Thanks for the quick reply. > > > > Looking at the build_message function, I see no reason why I shouldn't > > be able to do it. However since you mention asking questions... I have a > > quick one for you. > > > > The username token is set in the rampart_context, which when using > > neethi_policy appears to be set when calling > > axis2_svc_client_set_policy? > > > > However, since I may potentially want to change the SAML token after > > every message, is it possible to somehow obtain a pointer to the > > rampart_context, so that things within it may be changed? > > > > How is this done with the username? Or is it not possible, and the > > username can only be set within a policy? > > > > Thanks, > > Jamie > > > > > > > >> -----Original Message----- > >> From: Kaushalye Kapuruge [mailto:[EMAIL PROTECTED] > >> Sent: 16 August 2007 11:47 > >> To: Apache AXIS C Developers List > >> Subject: Re: [Rampart/C] SAML Support? > >> > >> Hi Jamie, > >> Rampart/C still doesn't have the SAML support. But it's definitely > >> something we have planned to do(Problem is when:) ). > >> If you like to have it implemented by yourself, only for the client > >> side, it's not that difficult. Please have a look at the function > >> rampart_shb_build_message() in src/util/rampart_sec_header_builder.c. > >> Also you may have to include few additional Rampart/C policy > >> > > assertions. > > > >> As a guide, you may see how a Timestamp or a Username token is added > >> > > to > > > >> the header. Feel free to drop questions here in the list, should you > >> need any assistance. Also we appreciate if you can share your > >> implementation with us. > >> Cheers, > >> Kaushalye > >> > >> > >> > >> Jamie Lyon wrote: > >> > >>> Hi, > >>> > >>> Does rampart/c support SAML yet? I have looked on the net and only > >>> found references to SAML support being implemented by July '07. > >>> > >>> I do not require any support for SAML server-side, just simply > >>> attaching a saml assertion (currently stored as an axiom_node_t*) > >>> > > into > > > >>> the security header. > >>> > >>> Is this currently possible? > >>> > >>> If not, how easy would it be to add support? I'm not quite sure how > >>> > > I > > > >>> would pass data to rampart so that a different SAML token could be > >>> attached to each message? Rampart seems fairly stand-alone. > >>> > >>> Any suggestions are welcome. > >>> > >>> Cheers, > >>> > >>> Jamie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
