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]
