[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rampart-dev
Subject:    [jira] Moved: (RAMPART-15) Need the ability to allow security
From:       "Davanum Srinivas (JIRA)" <jira () apache ! org>
Date:       2007-01-26 19:09:49
Message-ID: 4286582.1169838589713.JavaMail.jira () brutus
[Download RAW message or body]


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

Davanum Srinivas moved AXIS2-1965 to RAMPART-15:
------------------------------------------------

        Key: RAMPART-15  (was: AXIS2-1965)
    Project: Rampart  (was: Axis 2.0 (Axis2))

> 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
> 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 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.


[prev in list] [next in list] [prev in thread] [next in thread]