You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Stefano Puri <st...@intecs.it> on 2009/01/13 18:31:21 UTC

Re: Encryption of SAML supporting token

Hi,

I have succeeded in sending an encrypted SAML token with Rampart by 
specifying <sp:EncryptedSupportingTokens>
in the client side WS-Security policy (1.2) configuration file; however 
at server side, in the receiving phase, it seems that no control is 
performed about the encrypted token existence (I hope I am wrong).

For instance, I can use <sp:SupportingTokens> at client side and 
<sp:EncryptedSupportingTokens> at server side and the policy check at 
server side succeeds, while it should throw a fault.

I have tried to investigate the Rampart source code; for instance I have 
seen that the PolicyBasedResultsValidator.validateSupportingTokens() 
method, which if I have understood well is used during the receiving 
phase to validate the tokens accordingly with the policy data, doesn't 
care about EncryptedSupportingTokens: is this right? Is the control 
performed in a different point?

Best regards,

Stefano.

Stefano Puri ha scritto:
> Hi Nandana,
> 
> thank you very much for your reply.
> 
> First of all something regarding my scenario: I have started from the 
> (working) sample05 example coming with Rampart (where a SAML token is 
> used as SupportingToken in a client-server communication) and now I am 
> trying to extend the policies at client and server side...
> 
> At client side I have tried to use sp:EncryptedSupportingTokens in the 
> policy to add an encrypted SAML token to the SOAP request, where 
> sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702", so 
> WS-Security Policy 1.2.
> Unfortunately, when the message is sent to the server, nothing is added 
> in the security header of the request.
> 
> Any further suggestion?
> 
> Thank you in advance.
> 
> Stefano.
> 
> Nandana Mihindukulasooriya ha scritto:
>> Security Policy 1.2 supports encrypted supported tokens. Can you 
>> please try
>> using that ?
>>
>> thanks,
>> nandana
>>
>> On Fri, Nov 21, 2008 at 2:41 PM, Stefano Puri 
>> <st...@intecs.it>wrote:
>>
>>> Hi,
>>>
>>> I have a policy with a SAML defined as supporting token. I would like
>>> to protect this token with encryption:
>>> does anyone know if Rampart supports encryption of SAML supporting 
>>> token?
>>>
>>> For instance at the client side (message outflow) I am trying to use the
>>>
>>> <sp:EncryptedElements>
>>>
>>> element in the policy to refer to the SAML token but it doens't seem to
>>> work.
>>>
>>> Also I am wondering if during the message inflow, Rampart would be
>>> able to verify the <sp:EncryptedElements> policy statement for the
>>> incoming message and then decrypt and check for the SAML supporting
>>> token existence.
>>>
>>> Thank you in advance.
>>> Stefano.
>>>
>>>
>>> LEGAL DISCLAIMER:
>>> The contents of this email and any transmitted files are confidential 
>>> and
>>> intended solely for the use of the individual or entity to whom they are
>>> addressed. We hereby exclude any warranty and any liability as to the
>>> quality or accuracy of the contents of this email and any attached
>>> transmitted files. If you are not the intended recipient, be advised 
>>> that
>>> you have received this email in error and that any use, dissemination,
>>> forwarding, printing or copying of this email is strictly prohibited. 
>>> If you
>>> have received this email in error please contact the sender and 
>>> delete the
>>> material from any computer.
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 
>> 270.9.8/1800 - Release Date: 19/11/2008 18.55
>>
> 
> 
> LEGAL DISCLAIMER:
> The contents of this email and any transmitted files are confidential 
> and intended solely for the use of the individual or entity to whom they 
> are addressed. We hereby exclude any warranty and any liability as to 
> the quality or accuracy of the contents of this email and any attached 
> transmitted files. If you are not the intended recipient, be advised 
> that you have received this email in error and that any use, 
> dissemination, forwarding, printing or copying of this email is strictly 
> prohibited. If you have received this email in error please contact the 
> sender and delete the material from any computer.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.15/1838 - Release Date: 08/12/2008 18.16
> 


LEGAL DISCLAIMER:
The contents of this email and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. We hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender and delete the material from any computer.