Hi Jamie, Please see my comments inline.
On Thu, 2007-08-16 at 14:57 +0100, Jamie Lyon wrote: > 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? Yes, <sp:SamlToken> Assertion assumes that both parties have obtained SAML tokens, and how it obtained is done through <sp:IssuedToken> assertion. I think <sp:SamlToken> assertion can't exist seperately, it should exists inside a <sp:ProtectionToken> or as a SupportingToken in policy. So if you are going to use SAML as described in the security policy spec you need to first implement <sp:SymmetricBinding> and related stuff.(Currently rampart does not support SymmetricBinding.) > > 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. The policy file contains two types of assertions. Assertions defined in ws-securiyPolicy spec ans assertions which are specific to rampart. For example requirement for a usernameToken is an assertion of type security policy , But the username to use is rampart specific. These type of assertions we include inside <rampc:RampartConfig>. So if you hard coded it inside RampartConfig you need to add some members in the neethi/src/secpolicy/model/rampart_config struct. If you do not like hard coding you can add the it in rp_secpolicy object or directly in rampart_context. If you add it in secpolicy object, then when you change the values of that assertion per request, you need to reset the secpolicy in the rampart_context. I assume you are using the same svc_client. Because Rampart get the security configurations only through rampart_context. > 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. neethi_policy object is stored in the axis2 description hierarchy and we have access to it through msg_ctx. This neethi_policy object may contain any type of policy not only security. Inside rampart we build a secpolicy object from above neethi_policy and set it in rampart context. > > 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? Yes you cannot add or remove assertions from neethi_policy , it can be built through a policy file or through a om_model. > > 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 If you do this you need to add it in the policy file or need to add in the om_tree. I think it is not your requirement. > 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 IMHO, What you need to do is, 1. Add some form of representaion of SAML in secpolicy struct or rampart_context. 2. If you add it in secpolicy then reset the secpolicy member in rampart_context with the changed one. 3. Pass this rampart_context as a parameter named RAMPART_CONFIGURATION to rampart through rampart_context. 4. Implement necessary logic to build message in the sec_header_builder. Thanks -Manjula. > > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
