On 26/05/10 23:32 +0200, Mathias Laurenz Baumann wrote:
Users do not need to be created with sasl_setpass or other SASL utility,
and often are not, such as when using PAM for authentication.
That's also true when storing cmusaslsecretSRP for SRP authentication,
which can be stored using any method supported by the auxprop store, such
as the mysql client when using the SQL auxprop plugin.
Well, I need some way to create the cmusaslsecret{mech}s on the client, so
I can send them to the server which then can add it to the database.
Which the sasl library can do, on the client. ldapdb and sql auxprop
plugins have the added benefit of allowing you to transmit those attributes
securely.
If your client systems don't have the sasl library installed, then you can
accept a plain text password (transmitted over SSL e.g.) and have whichever
auxprop plugin you prefer convert it to mech specific credentials directly
on the server, but the server then has knowledge of the plain text
password.
If you use a network enabled auxprop plugin (SQL or LDAPDB), and you
allow users permissions to change their own security credentials, then
you could assign a temporary password and let them change it
themselves.
I don't use an external server for storing authentication (at least not
primary) but instead want to use server itself to store it (that is, the
client of the libsasl library).
From what I've understood from the documentation I can only do that, by
writing my own auxprop plugin that calls some functions in the host
application. There are several problems with that:
Your application could just call 'saslpasswd2'. That's what we do when
customers change their passwords from a PHP webpage.
I might be misinterpreting your needs. Where do you intend to store your
authentication credentials?
1) I don't want an extra plugin to be installed in the sasl2
plugin-directory just for my server, so I would just ship it as regular
lib and use the sasl_getpath_t function to tell libsasl to load the
(previously set using sasl_getopt_t) auxprop plugin using a specific path
2) Depending on whether the applications symbols are being exported back
to the library or not, I can't just call an function from the host
application but I could load the library before libsasl does and
register some own callback functions.
You could look at the internal 'slapd' auxprop module OpenLDAP uses. It
seems to do something very similar: storing and retrieving credentials via
it's own internal auxprop module without any changes to the sasl library.
To allow a user to register, I would need to do nearly the same in the
client, I would then just do sasl_setpass to make the mech generate the
cmusaslsecret and saving it in my custom auxprop which would then just
tell the host application (which is the client of my server) and send
the cmusaslsecrets to the server which then can add them to its database.
Am I over-complicating things here? Are there better ways to reach what I
try to achieve? I haven't found any other way than the one I just
described.
--
Dan White
