Need the ability to allow security elements' Ids to be set from a callback
--------------------------------------------------------------------------
Key: AXIS2-1965
URL: https://issues.apache.org/jira/browse/AXIS2-1965
Project: Apache Axis 2.0 (Axis2)
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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
