axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <>
Subject [jira] Assigned: (AXIS2-1965) Need the ability to allow security elements' Ids to be set from a callback
Date Wed, 24 Jan 2007 04:56:49 GMT


Deepal Jayasinghe reassigned AXIS2-1965:

    Assignee: Ruchith Udayanga Fernando

> Need the ability to allow security elements' Ids to be set from a callback
> --------------------------------------------------------------------------
>                 Key: AXIS2-1965
>                 URL:
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: New Feature
>            Reporter: George Stanchev
>         Assigned To: Ruchith Udayanga Fernando
> 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
> 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:
For additional commands, e-mail:

View raw message