axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samisa Abeysinghe (JIRA)" <>
Subject [jira] Assigned: (AXIS2C-261) Password callback API needs redoing
Date Tue, 12 Sep 2006 06:45:24 GMT
     [ ]

Samisa Abeysinghe reassigned AXIS2C-261:

    Assignee: Malinda Kaushalye Kapuruge

> Password callback API needs redoing
> -----------------------------------
>                 Key: AXIS2C-261
>                 URL:
>             Project: Axis2-C
>          Issue Type: Improvement
>          Components: rampart
>    Affects Versions: Current (Nightly)
>            Reporter: James Clark
>         Assigned To: Malinda Kaushalye Kapuruge
> 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
> 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message