Sebastian
2010/4/15 <t.lem...@gmail.com <mailto: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>
<mailto: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>
<mailto: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>
<mailto:openmeetings-user@googlegroups.com
<mailto:openmeetings-user@googlegroups.com>>.
To unsubscribe from this group, send email to
openmeetings-user+unsubscr...@googlegroups.com
<mailto:openmeetings-user%2bunsubscr...@googlegroups.com>
<mailto:openmeetings-user%2bunsubscr...@googlegroups.com
<mailto: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>
<mailto: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-user@googlegroups.com
<mailto:openmeetings-user@googlegroups.com>.
To unsubscribe from this group, send email to
openmeetings-user+unsubscr...@googlegroups.com
<mailto: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-user@googlegroups.com
<mailto:openmeetings-user@googlegroups.com>.
To unsubscribe from this group, send email to
openmeetings-user+unsubscr...@googlegroups.com
<mailto: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 <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.
For more options, visit this group at
http://groups.google.com/group/openmeetings-user?hl=en.
