hi, okay Thibault I will add this to list of Issues, its a minor change if you are not aware how to add the config key and param I can do it.
http://code.google.com/p/openmeetings/issues/detail?id=1208 Can you please attached your DIFF with the Patch to it and I will commit it to the SVN. Sebastian 2010/4/15 <t.lem...@gmail.com> > Sebastian Wagner a écrit : > > hi, >> >> >> *I think then that this behaviour should be switchable in config: having a >> parameter that decides weither or not OM falls back to internal DB auth if >> Ldap is offline.* >> >> => adding this param is no problem, you can also make it slightly >> different: >> Still populate the password but if the user has turned off the LDAP >> Feature you set the user to status *disabled*. Disabled users are not able >> to login via the User-Database of OM. >> > > This is possible but not secure. As a security officer I know that password > duplication is a bad thing to do as this can decrease the Information System > overall security level. > > For instance, OM is storing the password in a database: so now it's up to > the DB admin to secure the DB access. > ==> Imagine he just doesn't think it contains confidential information, > this could lead to passwords compromise. > > OM stores passwords as MD5 hashes, so it may seem to be secure anyway... > yes and no... because most of the time passwords are easy to find by small > derivations of a passwords dictionary. > Having an MD5 list of passwords is enough to break a good number of > passwords quickly. A way to increase security would be to use salted MD5 > version of the passwords. > > However there is a better approach to security: instead of trying to secure > the confidential data an application stores, it is better to just store only > required data. And since passwords are not required for Ldap users in OM > (unless the "to be invented" sync-ldap-password-to-om parameter is set), > then it would be better to just not record them. > > Thibault > > > > >> Sebastian >> >> 2010/4/15 <t.lem...@gmail.com <mailto:t.lem...@gmail.com>> >> >> >> smoeker a écrit : >> >> hola, >> >> the original reason for storing the ldap passwd locally (md5 >> encrypted) within OM is to be able to use openMeetings, even >> if ldap >> server is maintained/off/not available... >> >> >> That is why usually an Ldap client implementation shoud propose to >> setup 2 Ldap servers definitions, in order to have one as backup. >> >> >> -> i remember a post, somebody saying its sometimes hard to >> keep syncd >> with the Ldap Directory Admin - i agree with that ;-) >> >> I don't understand. What do you mean by this? Can you give an >> example ? >> >> >> -> this is also the reason for storing the admins password >> locally - >> admin users should always be able to access OM, even if there are >> compilations with the Ldap Directory Server... >> >> Let's narrow down the password duplication to admins only then. >> >> Since its always the Ldappassword that has to be correct (in >> case Ldap >> is configured) >> >> Not for Admins. for admins Ldap authentication is always bypassed. >> --- in MainService --- >> // AdminUser werden auf jeden Fall lokal authentifiziert >> if(user != null && user.getLevel_id() >=3){ >> log.debug("User " + usernameOrEmail + " is admin -> >> local login"); >> withLdap = false; >> } >> --- --- >> >> >> , its not really duplicated, but stored as fallback >> (this is working without stopping OM Server). >> >> Well, yes it is duplicated then ;-) >> This method has another pb. It supposes that all authentication >> systems supported by OM in the future will let OM know the user >> password which is not always the case. >> >> Imagine that someone wants to implement an authentication module >> to support the Central Authentication Service (CAS). This SSO >> system works like this: >> * OM gets a request, and is setup to use CAS, so that it checks if >> a service ticket (either a cookie or GET param) is set >> * OM sees no ticket and redirects the client to the CAS server >> which performs authentication, generate a ticket and redirect the >> client to OM with teh valid ticket set in URL or cookie >> * OM sees the new request with a ticket, it checks the ticket by >> asking the CAS server if it is valid, and then accept the client. >> ==> In this protocol, OM never sees the user password. >> >> It would be a pity to prevent future developpements of any kind of >> authentication systems, just because the first design was >> supposing a valid password is known by OM. >> But this is only my opinion. >> >> >> The userdata should be updated on every successful login , so >> the db >> passwd should also always be in sync with the Ldap server. >> (The only >> scenario it would fail would be, if LDAP password changes and ldap >> server is off/not configured in OM, so the local password wouldn't >> match the current DB password - but coding the fallback for the >> fallback is not my flavour ;-)) >> >> This will occur as soon as a Ldap user having admin privileges >> changes his LDAP password. I'm sure of this. >> >> >> i dont think i understand the random passowrd bypass via >> config -how >> would a OM user authenticate, if Ldap server is off? >> >> Ldap server should never be off. at least a backup should be online. >> Imigine that a user gets banned from an organization, and the Ldap >> admin delete his account on the Ldap server. >> This user would only have to run a DOS attack on the Ldap server >> to keep his access on the OM system! >> >> So my proposal of a random password was to prevent anyone from >> login in with a user imported from Ldap even if the Ldap server is >> offline. >> But I see now that we have 2 differents point of view on the matter. >> >> I think then that this behaviour should be switchable in config: >> having a parameter that decides weither or not OM falls back to >> internal DB auth if Ldap is offline. >> >> >> What do you think ? >> Thibault >> >> >> >> see ya >> >> Smoeker >> >> On 15 Apr., 13:51, t.lem...@gmail.com >> <mailto:t.lem...@gmail.com> wrote: >> >> Hi, >> >> While reviewing the ldap authentication module, I found >> out that once >> authenticated, OM records and updates the user's password >> in its >> internal DB. >> Why is that ? >> >> In LdapLoginManagement.java: in method doLdapLogin >> // Update password (could have changed in LDAP) >> u.setPassword(passwd); >> >> Since all authentications are done on the LDAP server, I >> think it is a >> bad idea to duplicate the password in OM internal DB. >> >> Is there another good reason to do this ? >> >> The only reason I see so far is that in MainService, the >> loginUser >> method fails back to non LDAP authentication if the user >> has admin >> privileges. This also means that even if the user changes >> his password >> in LDAP, his old password recorded to the OM db must be >> used... >> >> I think it would be better: >> * to set a random password value in the OM's Users tables >> for the Ldap users >> * set a new parameter in om_ldap that will list admin >> users for which >> LDAP auth must be bypassed (in order to keep a local admin >> login even if >> LDAP is badly configured or unavailable). >> >> What do you think ? >> >> Thibault >> >> >> >> >> -- You received this message because you are subscribed to the >> Google >> Groups "OpenMeetings User" group. >> To post to this group, send email to >> openmeetings-user@googlegroups.com >> <mailto:openmeetings-user@googlegroups.com>. >> >> To unsubscribe from this group, send email to >> >> openmeetings-user+unsubscr...@googlegroups.com<openmeetings-user%2bunsubscr...@googlegroups.com> >> >> <mailto:openmeetings-user%2bunsubscr...@googlegroups.com<openmeetings-user%252bunsubscr...@googlegroups.com> >> >. >> >> For more options, visit this group at >> http://groups.google.com/group/openmeetings-user?hl=en. >> >> >> >> >> -- >> Sebastian Wagner >> http://www.webbase-design.de >> http://openmeetings.googlecode.com >> http://www.laszlo-forum.de >> seba.wag...@gmail.com <mailto:seba.wag...@gmail.com> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenMeetings User" group. >> To post to this group, send email to openmeetings-u...@googlegroups.com. >> To unsubscribe from this group, send email to >> openmeetings-user+unsubscr...@googlegroups.com<openmeetings-user%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/openmeetings-user?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "OpenMeetings User" group. > To post to this group, send email to openmeetings-u...@googlegroups.com. > To unsubscribe from this group, send email to > openmeetings-user+unsubscr...@googlegroups.com<openmeetings-user%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/openmeetings-user?hl=en. > > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
