See my replies inline. > -----Original Message----- > From: Manjula Peiris [mailto:[EMAIL PROTECTED] > Sent: 17 August 2007 05:03 > To: Apache AXIS C Developers List > Subject: RE: [Rampart/C] SAML Support? > > 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.) Okay, I don't think I have enough experience with WS-Policy or Rampart to implement the policy part of this at this stage, so I am just going to concentrate on adding in a SAML token, even if it's just for myself. And then if I have some time in the future go back to this. > 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.
I am using the same svc_client, yes. > 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. > > 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. Okay, I have implemented the basics by adding an extra member to the struct in rampart_context, and I believe I have added the sec_header_builder functions too. I added it to rampart_context as storing the saml-token in the secpolicy struct didn't seem the correct place to do it, since it is not the policy; just what the policy will require. 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? If you could give me some tips as to how to get, modify and set the rampart_context that rampart will use, that would really help. 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] > > > > > --------------------------------------------------------------------- > 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]
