You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-c-dev@ws.apache.org by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org> on 2008/01/18 08:26:34 UTC
[jira] Created: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Avoid deploying password callback modules in the client code
------------------------------------------------------------
Key: RAMPARTC-56
URL: https://issues.apache.org/jira/browse/RAMPARTC-56
Project: Rampart/C
Issue Type: Improvement
Components: Rampart-core
Affects Versions: 1.2.0
Environment: N/A
Reporter: Malinda Kaushalye Kapuruge
Assignee: Glen Daniels
Fix For: 1.2.0
Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Malinda Kaushalye Kapuruge closed RAMPARTC-56.
----------------------------------------------
Fixed. Closing
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Supun Kamburugamuva (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561951#action_12561951 ]
Supun Kamburugamuva commented on RAMPARTC-56:
---------------------------------------------
This is a good way to solve the problem allowing future expansions as well. How are we going to set this structure to the svc client? One option is introducing a new option to the svc client. But as Rampart is becoming a very important part in axis2/c we should have a separate method in svc client to set this structure. I think we should discuss this on axis2-c dev as well.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560270#action_12560270 ]
Malinda Kaushalye Kapuruge commented on RAMPARTC-56:
----------------------------------------------------
Right now the order of execution is as follows.
1. Check rampart context for a direct password
2. If not Check rampart context for a password callback function
3. If not Check rampart context for a password callback module
So there is no code change needed in the core functionalities. All we have to provide is either the password directly to the message context or a callback function to retrieve the password.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: Glen Daniels
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562356#action_12562356 ]
Malinda Kaushalye Kapuruge commented on RAMPARTC-56:
----------------------------------------------------
I've added a new struct to keep these configurations in the client side. Right now it supports only UN/PW, PW type and TTL. May be later we can add properties to hold certificates and other configurations too.
Yes I agree with Manjula that we keep svc client alone. If can use axis2 options that would be enough.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "S.Uthaiyashankar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
S.Uthaiyashankar reassigned RAMPARTC-56:
----------------------------------------
Assignee: S.Uthaiyashankar (was: Glen Daniels)
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "S.Uthaiyashankar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
S.Uthaiyashankar resolved RAMPARTC-56.
--------------------------------------
Resolution: Fixed
support for username, password, password type and time to live are implemented. Other features can be added when necessary
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Malinda Kaushalye Kapuruge (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561936#action_12561936 ]
Malinda Kaushalye Kapuruge commented on RAMPARTC-56:
----------------------------------------------------
Here is my suggestion...
We may use a new structure called rampart_config_t and set it to the axis2_svc_client_t
Inside the rampart_config_t we can have following members.
1. username
2. password
Later we can evolve this new struct to hold certificates. password callback functions, TTL values and all the other configurations. In this way we do not need to change the axis2_svc_client_t for each and every new security requirements.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "S.Uthaiyashankar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562482#action_12562482 ]
S.Uthaiyashankar commented on RAMPARTC-56:
------------------------------------------
rampart_config support is added to rampart. So, client code writers can create a rampart_config object and set username, pasword, etc. and then attach it to svc client's option. Following code snippet shows how to do it.
rampart_config_t* client_config = NULL;
axutil_property_t *property = NULL;
client_config = rampart_config_create(env);
if(!client_config)
{
printf("Cannot create rampart config\n");
return 0;
}
rampart_config_set_username(client_config, env, "Raigama");
rampart_config_set_password(client_config, env, "RaigamaPW");
rampart_config_set_password_type(client_config, env, RAMPART_PASSWORD_DIGEST);
rampart_config_set_ttl(client_config, env, 10);
property = axutil_property_create_with_args(env, AXIS2_SCOPE_REQUEST ,
AXIS2_TRUE, (void *)rampart_config_free, client_config);
axis2_options_set_property(options, env, RAMPART_CLIENT_CONFIGURATION, property);
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Manjula Peiris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562339#action_12562339 ]
Manjula Peiris commented on RAMPARTC-56:
----------------------------------------
I think if we add a separate method to set the struct compiling Axis2/C will depend on Rampart/C, because the new struct is defined in rampart. I think it is better to add it as an option so only the client will need rampart to compile.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RAMPARTC-56) Avoid deploying password callback
modules in the client code
Posted by "Supun Kamburugamuva (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561779#action_12561779 ]
Supun Kamburugamuva commented on RAMPARTC-56:
---------------------------------------------
If a single client is used by many users setting only the password won't help. At the moment rampart assumes that a single client has a single user and the user name is set in the client policy file. But unfortunately this is not the case always.
In the case of multiple users, Rampart should support single client with different user names and passwords.
AFAK there are two ways that we can solve this.
1. Providing functionality in the axis2 client code to include username and password. This can be done using a callback function as Uthaiyashankar as suggested.
2. Providing access to the rampart context in the client code. This will enable the user to set the username and password as she wishes.
My personal preference is second option. By providing a call back function what we ultimately do is populating the rampart context. So why we do it in a vey complex and hard to understand way to the user while we can simply allow the user to set the username and password in the rampart context.
I know, providing access to the rampart context in the client code is not that easy and we need to change or add functionality to the svc client code. But as the Rampart evolves we may need to allow the user to set values to the rampart context more often. Best example is the SAML tokens. Another situation that comes to my mind is using different certificates to sign the messages sent by the same client(if multiple users are using the same client). Definitely we cannot do something like above using configuration files. It is hard to implement and use callback functions every time we need to introduce a new feature.
Any comments or suggestions are highly appreciated.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password callback module and deploy it. And then refer the name of the dll via the policy descriptor. This is quite unnecessary, if we can provide a callback function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the message context within the client code. Later when the rampart context is created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.