[jira] Updated: (RAMPART-15) Need the ability to allow security elements' Ids to be set from a callback

["Samisa Abeysinghe (JIRA)" <ji...@apache.org>]

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

Samisa Abeysinghe updated RAMPART-15:
-------------------------------------

    Assignee:     (was: Ruchith Udayanga Fernando)

> Need the ability to allow security elements' Ids to be set from a callback
> --------------------------------------------------------------------------
>
>                 Key: RAMPART-15
>                 URL: https://issues.apache.org/jira/browse/RAMPART-15
>             Project: Rampart
>          Issue Type: New Feature
>            Reporter: George Stanchev
>
> There are situation in which a message body need to refer to a security elements (for example UsernameToken) by id. The problem is that at the time of call composition/creation, the security headers have not been yet created and therefore the IDs that are to be assigned to security elements are not yet created. A use case for this is the issue of WS-Trust Request Security Token (RST) with an OnBehalfOf element. The specs say that OnBehalfOf can contain security token reference or a security token. Currently, to implement this, a user is stuck of using WSS4J directly to create its security token and then stuffing it in OnBehalfOf element. This is cumbersome and defies the purpose of having rampart. 
> One way of tackling the problem would be to have provide rampart with callback instance to be called for UID generation. Prior to calling the callback, rampart would need to set some context information as to which security element instance it needs ID for. Using the old OutflowConfiguration classes, rampart could've extended the syntax for each security action to allow specifying of user-supplied context. For example 
> <action>UsernameToken#mytoken1 SAMLTokenSigned#mytoken2</action>. The WSS4J handler under rampart, could parse out the action and see if #tokenid context string is added. Then when ID generation is due, would check the OutflowConfiguration class to see if a callback instance is present and if so it will call it to get an UID with the token contextid. This way the callbacks could provide proper UID based on the context id.
> I dont know enough the new neethi based security policy configuration to propose proper solution.
> This is just one way of solving this.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org