Bug #11616
closed
API tokens are not evaluated indepently of LDAP credentials
Description
Hi,
we just had some issue with our backed LDAP servers.
They're timing out on request, which also makes the Rudder UI login hang until finally there is a reply.
So far, so good.
The BAD thing we noticed is that API token based connections are blocked at the same time.
It seems that something in the spring (?) security module blocks for both authentication models if one is unavailiable.
This makes no sense considering the API tokens are not bound to users.
Nor do they even use an external authentication source at all.
Could you please check this and, if at all possible, untangle the two!?
Its one thing if user logon is blocked, but the machine-machine-interface should be available.
I was told (unverified) that it threw a 404 on the API in the end, that should be looked at.
Updated by Florian Heigl over 6 years ago
- User visibility set to Infrequent - complex configurations | third party integrations
- Priority changed from 0 to 65
add visibility
Updated by François ARMAND over 6 years ago
So, this is EXTREMELY bizarre, and there is no reason at all that it should happen (and you are right that it must not happen).
In Rudder, there is two entry-points for url patterns, one for .../secure, one for .../api, and behind each, two completelly unrelated parts of the code is used.
But as what you describe is really strange, I tried to reproduce. With no luck for now.
What I did in Rudder 4.1:
- configure LDAP authentication with that:
rudder.auth.provider=ldap
# this is a different LDAP server than the one used for Rudder database
rudder.auth.ldap.connection.url=ldap://localhost:3389/cn=rudder-configuration
rudder.auth.ldap.connection.bind.dn=cn=manager,cn=rudder-configuration
rudder.auth.ldap.connection.bind.password=blablabla
rudder.auth.ldap.searchbase=ou=Users
rudder.auth.ldap.filter=(&(cn={0})(objectclass=person))
- tested that the authentication works with both an user and a previously created token
- added a DROP rule for my authentication server
% ldapwhoami -vvv -h 127.0.0.1 -p 3389 -D cn=fanf,ou=Users,cn=rudder-configuration -x -w "fanf" ldap_initialize( ldap://127.0.0.1:3389 ) dn:cn=fanf,ou=Users,cn=rudder-configuration Result: Success (0) % sudo iptables -A INPUT -p tcp --dport 3389 -j DROP % ldapwhoami -vvv -h 127.0.0.1 -p 3389 -D cn=fanf,ou=Users,cn=rudder-configuration -x -w "fanf" ldap_initialize( ldap://127.0.0.1:3389 ) ^C
(note to self: it would be smart to make the authentication query timeout at some point...)
And I'm still able to perform API requests (well, and actually get responses) at that point.
Do you see something different between my experiment and your scenario?
Updated by François ARMAND over 6 years ago
It is not clear, but I tried to make REST request also when an authentication request was pending, and it works, to.
Updated by Benoît PECCATTE almost 6 years ago
- Priority changed from 65 to 58
Florian, we cannot reproduce, can you help us determine when this happens ?
Updated by François ARMAND about 5 years ago
- Status changed from New to Rejected
- Priority changed from 58 to 54
We weren't able to reproduce it. I'm going to close the issue, but if anybody experiences it again, or find a way to reproduce it, please re-open it and add information!