You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2006/11/15 18:59:39 UTC
[jira] Created: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Sandesha contains hard-coded security properties for rampart
------------------------------------------------------------
Key: SANDESHA2-44
URL: http://issues.apache.org/jira/browse/SANDESHA2-44
Project: Apache Sandesha2
Issue Type: Improvement
Reporter: Matt Lovett
Priority: Minor
Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
Thanks
Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=comments#action_12450218 ]
Chamikara Jayalath commented on SANDESHA2-44:
---------------------------------------------
Sure. Will do. Please send the patch.
BTW you can test by running the Scenario_4_1 client in the interop folder.
(run 'maven interop:create' to build the service)
Chamikara
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=comments#action_12450542 ]
Chamikara Jayalath commented on SANDESHA2-44:
---------------------------------------------
Unfortunately it seems like secureConv+RM hs been broken due to some changes in Sandesha2/Rampart. I'll work on fixing that first, hopefully with some help from Ruchith.
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: rampart.patch
>
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=comments#action_12450542 ]
Chamikara Jayalath commented on SANDESHA2-44:
---------------------------------------------
Unfortunately it seems like secureConv+RM hs been broken due to some changes in Sandesha2/Rampart. I'll work on fixing that first, hopefully with some help from Ruchith.
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: rampart.patch
>
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=comments#action_12450218 ]
Chamikara Jayalath commented on SANDESHA2-44:
---------------------------------------------
Sure. Will do. Please send the patch.
BTW you can test by running the Scenario_4_1 client in the interop folder.
(run 'maven interop:create' to build the service)
Chamikara
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Resolved: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Gatford resolved SANDESHA2-44.
-------------------------------------
Resolution: Fixed
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: https://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: rampart.patch
>
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=all ]
Matt Lovett updated SANDESHA2-44:
---------------------------------
Attachment: rampart.patch
Patch as described above
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: rampart.patch
>
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-44) Sandesha contains hard-coded
security properties for rampart
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-44?page=all ]
Matt Lovett updated SANDESHA2-44:
---------------------------------
Attachment: rampart.patch
Patch as described above
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: http://issues.apache.org/jira/browse/SANDESHA2-44
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: rampart.patch
>
>
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that were added to help the RampartBasedSecurityManager. I think that we can probably remove these hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence message into SecurityManager::getSecurityToken(), pass in the application message context instead. This context is much more likely to have the right config associated with it. (This may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken() method.
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test this. If I put the patch up could someone who uses Rampart take a look, and tell me if we need part 2?
> Thanks
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org