[JDEV] custom registration [was authenticated registration]

Thomas Muldowney temas at box5.net
Sun Mar 11 22:53:29 CST 2001 

That can't work though, because each of the 3 auth models handles the data 
differently.  They all don'te ven query on NS_AUTH_0K.  If it was all the same
we probably would have abstracted it much earlier and more so than it is now.

My other point would be:  doesn't that defeat the point of xdb?  The whole point
of the XDB is to provide that abstraction layer to the user data.  Why go 
around it in the code?

Am I missing something you're trying to say?

--temas

On Sun, Mar 11, 2001 at 01:14:58AM -0800, Robert Temple wrote:
> In each of the 3 auth modules that I know of, there is this one common
> line of code that gets passwords:
> 
> foo = xdb_get(m->si->xc, m->user->id, NS_AUTH_0K);
> 
> If we create custom modules that replace each of the 3 default auth
> modules, then all we need to do is to just swap that line of code out
> for some of our own custom code.  Not too much of a big deal, but in
> the future if you guys need to make changes to one of those modules, 
> then we will need to go back change our code the same way.  Or if you
> come out with a great new super secure authentication module, using
> something like kerberos, then we will have to go through and swap out
> that one line for our replacement lines again.
> 
> Simply from a maintenence standpoint, its going to require a lot of
> extra work and communication trying keep up with changes the jabber
> team makes.
> 
> now if those lines where replaced with something like
> 
> if (use_custom_auth)
>   foo = (*custom_get_password_function_pointer)(m->si->xc, m->user->id);
> else
>   foo = xdb_get(m->si->xc, m->user->id, NS_AUTH_0K);
> 
> It would be a lot easier to supply our own passwords.
> 
> -Robert
> 
> -----Original Message-----
> From: Thomas Muldowney [mailto:temas at box5.net]
> Sent: Tuesday, March 06, 2001 11:55 PM
> To: jdev at jabber.org
> Subject: Re: [JDEV] custom registration [was authenticated registration]
> 
> 
> Well we designed the module system for this reason, to be able to plugin new
> modules for items that are needed.  Need a different auth system, boom hook
> in the module and it should be running.  Want to verify users on
> registration?
> Hook in a new mod_register.  If you are not a coder at this point I would
> suggest adding the ideas to the Asylum (http://www.jabber.org/?oid=425) so
> that
> they can get even more exposure and perhaps hacked together if someone can
> do
> it easily.
> 
> --temas
> 
> On Tue, Mar 06, 2001 at 09:31:27PM -0800, Robert Temple wrote:
> > We are in the same boat as you. We have a large database of 
> > users we would like to get into the Jabber system.  It would 
> > work best for us if all registration messages sent by clients 
> > got rejected. And when the jabber server received an auth 
> > message the it wouldn't look into its own database for a 
> > password, but instead it would  somehow fetch the password 
> > from our system.   And if the password matched but the user 
> > didn't exist in the Jabber system yet, it would create the 
> > new database entry (the users xml file) for that new user.
> > 
> > I'd rather not have users passwords stored in the Jabber 
> > database at all, we already have a database of usernames &
> > passwords. The less password we have, the more secure we are.
> > 
> > Further, it would be really nice if when someone added someone 
> > else to their roster but that person didn't exist, the server 
> > would check our registration system to see if they exist there, 
> > and if they did, send a special message back to the client that 
> > lets them send an email to that new person that would ask if 
> > they want to sign up for Jabber.
> > 
> > Short of rewriting a few server modules, there isn't an easy
> > way to do this.   I'd like to see a standard auth API to do 
> > what we need in the Jabber server or instead of an API, 
> > pehaps a configuration where the server would get auth 
> > auth verification from an external agent over exterx instead.
> > 
> > It seems like custom authentication is needed by a lot of 
> > groups.
> > 
> > -Robert
> > 
> > > -----Original Message-----
> > > From: kadokev at msg.net [mailto:kadokev at msg.net]
> > > Sent: Tuesday, March 06, 2001 9:57 PM
> > > To: jdev at jabber.org
> > > Subject: Re: [JDEV] authenticated registration
> > > 
> > > 
> > > > I would like to stop just anyone from registering with my 
> > > jabber server.
> > > 
> > > I have a similar issue. I need to authenticate new users 
> > > registering with
> > > the jabber server, to ensure that the 'login' being created is their
> > > 'official' username. That is, to ensure that 
> > > 'login at jabber.ourdomain.com'
> > > is the same as their 'login' for the 'ourdomain' NT domain.
> > > 
> > > No matter how big disclaimers I put up as to the 
> > > non-verifiability of user
> > > information, I cannot risk having 'Bob HelpDeskGuy' register 
> > > as 'Jim TheCEO'.
> > > 
> > > It would probably be excessive (yet fun) to try to build 
> > > strong authentication
> > > into the Jabber server, but perhaps the server *could* be 
> > > extended to 'proxy'
> > > user authentication to a web server?
> > > 
> > > 
> > > > I hear you could set the spool directory read only to stop 
> > > people from
> > > > adding themselves. Ideally, jabberd should be able to 
> > > require that a user
> > > > wishing to be added to the server supply the administrator 
> > > account login
> > > > information, or be added to the server by the administrator 
> > > him/herself.
> > > 
> > > Has anybody looked into having the 'spool' directory owned by 
> > > a web server,
> > > and use a CGI script on the HTTPd to create the XML files?  
> > > This would allow
> > > for authentication of initial account creation via any 
> > > mechanism supported
> > > by Apache- RADIUS, LDAP, NIS, mSQL, DCE, NDS, TACACS+, etc.
> > > 
> > > What I'll most likely end up with is a web site that uses an Apache
> > > NT domain authentication module 
> > > (http://www.asaban.com/index_pl.html) to
> > > verify their identity and create the XML file the first time. 
> > > The script
> > > may also go to an LDAP server and extract their full name and 
> > > other detail
> > > at the same time.
> > > 
> > > Kevin
> > > 
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > > 
> > 
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010311/67e7960f/attachment-0002.pgp>

More information about the JDev mailing list