[ http://issues.apache.org/jira/browse/AXIS2C-261?page=all ]
Samisa Abeysinghe updated AXIS2C-261:
-------------------------------------
Fix Version/s: 1.0.0
> 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
> Assigned To: Malinda Kaushalye Kapuruge
> Fix For: 1.0.0
>
>
> 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]
