[jira] Created: (AXIS2C-262) mod_axis2 should allow username token passwords to be validated used Apache's authn_providers
mod_axis2 should allow username token passwords to be validated used Apache's authn_providers - Key: AXIS2C-262 URL: http://issues.apache.org/jira/browse/AXIS2C-262 Project: Axis2-C Issue Type: New Feature Components: transport/http Affects Versions: Current (Nightly) Reporter: James Clark Apache 2.2 introduced a nice separation between authentication and authorization providers. Authentication providers have a nice simple interface that basically just allow a password to be checked. It ought to be possible for mod_axis2 to implement Axis2's password checking API on top of Apache 2's authn_provider API. This would allow the passwords of username tokens to be checked using any of the Apache 2 authn providers including file-based providers and LDAP. Axis2's password checking API will need to be fixed first (see issue 261). -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-261) Password callback API needs redoing
Password callback API needs redoing
---
Key: AXIS2C-261
URL: http://issues.apache.org/jira/browse/AXIS2C-261
Project: Axis2-C
Issue Type: Improvement
Components: rampart
Affects Versions: Current (Nightly)
Reporter: James Clark
There are two distinct scenarios where Axis2/C might use the password:
1. There's an incoming message with a username and possibly digested password,
and Axis2/C needs to check whether the password is valid.
2. There's an outgoing message, and Axis2/C needs to know what username and
what password to use.
These are really, quite different situations with different requirements and
it's not a good idea to combine them into a single interface. Let's consider
them in turn.
1. The key point to bear in mind here is that you can't assume that the
password will be directly accessible. For example, the passwords may be stored
in a database that is readable by root but not by the Axis2/C userid; in this
case, password checking would be done by a separate daemon running as root
(like saslauthd) that provides a service over a Unix socket that accepts a
particular username/password pair and says whether or not it is valid. Or you
might be piggybacking on top of the apache2 authn provider interface.
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
} authn_provider;
I would suggest what you need is an OO type rampart_authn_username_t with
methods similar to the following
axis2_status_t rampart_authn_username_check_password(rampart_authn_username_t
*, const axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const
axis2_char_t *password)
axis2_status_t
rampart_authn_username_check_password_digest(rampart_authn_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const char
*nonce, size_t nonce_length, const char *digest)
(nonce is the concatenation of the timestamp and nonce, ready for hashing;
digest is the binary 20-byte binary SHA-1 hash)
The message context is in there, because the realm (password database) to use
may depend on the message. You'll also need this in order to allow mod_axis2
to provide an implementation of this on top of the Apache auth providers (note
this won't work for password digests).
2. For the outgoing case, I would suggest an interface rampart_cred_username_t
like this:
axis2_status_t rampart_cred_username_get(rampart_cred_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const char **username_res, const char
**password_res)
(the returned username/password will be owned by one of the context objects in
the context hierarchy)
This allows for a number of things not possible at the moment:
- different endpoints can have different username/passwords
- the user can be interactively asked for both the username and password; the
UI can provide a single dialog that allows both to entered at the same time
- the object can perform caching of the username/passwords at the appropriate
level of the context hierarchy, according to the particular policy that it
implements; for example, the username can be cached at the configuration level
(as now) and the password cached at the operation level
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-260) When wsamapping paramter is added to an operation, that operation is displayed twice in the deployed services browser
[ http://issues.apache.org/jira/browse/AXIS2C-260?page=all ] Damitha Kumarage resolved AXIS2C-260. - Resolution: Fixed Someone has mistakenly changed op_alction_map to op_alias_map in add_action_mapping function of axis2_svc struct > When wsamapping paramter is added to an operation, that operation is > displayed twice in the deployed services browser > - > > Key: AXIS2C-260 > URL: http://issues.apache.org/jira/browse/AXIS2C-260 > Project: Axis2-C > Issue Type: Bug > Components: core/description >Reporter: Damitha Kumarage > > When wsamapping paramter is added to an operation, that operation is > displayed twice in the deployed services browser. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-260) When wsamapping paramter is added to an operation, that operation is displayed twice in the deployed services browser
When wsamapping paramter is added to an operation, that operation is displayed twice in the deployed services browser - Key: AXIS2C-260 URL: http://issues.apache.org/jira/browse/AXIS2C-260 Project: Axis2-C Issue Type: Bug Components: core/description Reporter: Damitha Kumarage When wsamapping paramter is added to an operation, that operation is displayed twice in the deployed services browser. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-259) Incorrect use of AXIS2_DECLARE_DATA
Incorrect use of AXIS2_DECLARE_DATA
---
Key: AXIS2C-259
URL: http://issues.apache.org/jira/browse/AXIS2C-259
Project: Axis2-C
Issue Type: Bug
Reporter: James Clark
Priority: Minor
AXIS2_DECLARE_DATA is supposed to be used for declared exported data, eg
AXIS2_DECLARE_DATA int foo;
but in fact it's being incorrectly used to declare types, eg
AXIS2_DECLARE_DATA struct foo {
...
};
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][VOTE] Axis2C 0.93 Release Plan
+1 .. great work guys!! Thanks Srinath On 8/29/06, Deepal jayasinghe <[EMAIL PROTECTED]> wrote: Samisa Abeysinghe wrote: > It is time to do the 0.93 release, with the new features and bug fixes. > > I updated the Wiki here: > http://wiki.apache.org/ws/FrontPage/Axis2C/releases/0.93 > > IMHO, we could do the 0.93 release within next week. > I would like to propose that we do the release on 31st of August 2006. > > We have implemented almost all the features we planned for 1.0 release > by now. So 0.93 will be an early preview of 1.0. > We have to fix few more key bugs (related to specific use cases, not > the common/general use cases) and memory leaks before 1.0. Please have > a look at the TODO section of the Wiki for more information. > > Thanks, > Samisa... > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > +1 for the release. Thanks Deepal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Change function prefix of guththila
Hi, I have changed "guththila_xml_pull_parser_" prefix to "guththila_". and "guththila_xml_pull_parser.h" to "guththila.h"If you have any comments we will appreciate it. thanks,DineshOn 8/8/06, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: Dinesh Premalal wrote:>Hi,> I would like to suggest to change guththila function prefix > "guththila_xml_pull_parser_" in to "guththila_". Because it is> unecessary to type xml_pull_parser for every function that user> use.>>+1.Samisa... > Any ideas please ?>>thanks,>Dinesh>>->To unsubscribe, e-mail: [EMAIL PROTECTED]>For additional commands, e-mail: [EMAIL PROTECTED]- To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED] -- W.Dinesh Premalalhttp://xydinesh.blogspot.com/
Re: [Axis2]Renewing Guththila
Hi, Please my comments inlineOn 7/25/06, Dinesh Premalal <[EMAIL PROTECTED]> wrote: Hi devs, Hope to do following modifications to guththila code in order to minimize memory leaks and enhance the performance of guththila xml parser.guththila_reader 1.Replace guththila_environment, guththila_allocator, guththila_error with axis2_environment, axis2_allocator and axis2_error. axis2_xx implementations has less errors , well tested implementations and no point of maintaining same implementations in two places done ! 2. Remove it's local stack implementation and use axis2_utils stack implementation done !, Now guththila has a dependency on axis2_utils library 3. Implement space , comments and pi handling functions.In here I was meaning by "space" is SPACE event in the StaX api. But need to clarify about SPACE event. I saw some other mailing list StaX gurus still arguing about use of SPACE event. I would say let's wait some time , if we have any requirement with SPACE event then we can implement it. comments and pi ignored by the parser 4. Adding guththila_reader_create_for_io (), guththila_reader_create_for_memory () functions. done! guththila_writer--- 1. Integrate with aixs2_utils stack implementation.done !BTW axis2c is working with guththila in my machine. I will appreciate if some one could help me to integrate guththila with axis2c build system. thanks,DineshIf you have any ideas please let us know. thanks,Dinesh-- W.Dinesh Premalalhttp://xydinesh.blogspot.com/ -- W.Dinesh Premalalhttp://xydinesh.blogspot.com/
