[jira] Assigned: (RAMPART-200) Provide capability to configure x509 supporting token certificates different from the ones used for the assymetric binding

["Nandana Mihindukulasooriya (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAMPART-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandana Mihindukulasooriya reassigned RAMPART-200:
--------------------------------------------------

    Assignee: Nandana Mihindukulasooriya  (was: Ruchith Udayanga Fernando)

> Provide capability to configure x509 supporting token certificates different from the ones used for the assymetric binding
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: RAMPART-200
>                 URL: https://issues.apache.org/jira/browse/RAMPART-200
>             Project: Rampart
>          Issue Type: Improvement
>          Components: rampart-core
>    Affects Versions: 1.4
>            Reporter: Detelin Yordanov
>            Assignee: Nandana Mihindukulasooriya
>
> In a conversation secured with an assymetric binding, one might also like to encrypt/sign certain elements in the message with an x509 supporting token.
> For example consider this scenario - in an online shopping store the web app receiving the request might like to encrypt the credit card details of the customer with a certifiacate whose private key is in possesion only of the billing sub-system, while the whole message (containing also the order details) is encrypted and signed using an assymetric binding.
> I tried an assymetric binding scenario with an x509 supporting token, but the message produced by the client contained the protection token for the assymetric binding twice - because I guess Rampart used the encryption certificate also as a supporting token certificate.
> I think that in the simple scenario when we have only one x509 supporting token (might be also endorsing etc.), we need an additional aliases for the certificates to use for signature and/or encryption in case such assertions are present.
> In case when no signed/encrypted content assertion is present in the supporting token, we just need one alias identifying the certificate to insert and we could select from either the signature or the encryption aliases configured.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.