LDAP Authenticator: Use current credentials?

Help / Discuss
, ,
#1

Good day,

I am using Tomcat and WAFFLE (https://github.com/Waffle/waffle) to perform SSO and the LDAP Authenticator extension (https://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/) with settings:

xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl
xwiki.authentication.ldap=1

I’ve enabled logging in LDAP, so I know that the LDAP extension sees the remote username in the log:

2018-09-21 08:20:35,713 [https://tomcatserverfqdn/xwiki/bin/view/Main/] DEBUG x.c.l.XWikiLDAPAuthServiceImpl - RemoteUser: domainname\username

My Tomcat server is running as an Active Directory domain user that has permission to query LDAP.

With SSO in this scenario, there is no need for an LDAP bind password, because the user is already logged on (Tomcat server is running as domain user, who is already logged on, or server wouldn’t be running).

The problem: It seems that the LDAP Authenticator extension requires a binding username and password.

I tried setting null binding username and password:

xwiki.authentication.ldap.bind_DN=
xwiki.authentication.ldap.bind_pass=

I also tried omitting the above two settings. Omitting the settings (or specifying null) doesn’t seem to work, because it seems that null binding is not the same as “already authenticated.”

For LDAP Authenticator, is there any way to say: “Connect to LDAP server using current credentials”?

(Why? It is not good practice to hard-code passwords in plain-text in configuration files.)

#2

Disclaimer: I’m an xwiki user myself, no xwiki dev, let alone an architect. So my answer is partly based on interpretations I made. If you need an definitive or authoritative answer you have to wait for one of the architects to answer.

The current implementation of the LDAP Authenticator only support anonymous bind and simple bind (i.e. username/userdn and password), see XWikiLDAPConnection.java.

Active Directory (at least in the default configuration) does not support anonymous bind, so you have to use simple bind.

You can actually use the username and password of the user that is logging in, if xwiki knows them and if you can can construct a valid username that your LDAP directory accepts for bind (AD is quite friendly about accepted usernames). But I guess WAFFLE is standing in your way, because I doubt it will pass the password to the xwiki application.

Just for completeness: If you want to use this type you will have to use this kind of configuration, but you may have to make sure that {0} contains domain\username and it may not work with SSO:

xwiki.authentication.ldap.bind_DN={0}
xwiki.authentication.ldap.bind_pass={1}

So why is xwiki not using the information of the domain joined tomcat user? My guess is that this is because xwiki is an OS agnostic application, that just cares about java and an java application server. In most of the cases it is just not common that the user running the application/application server has implicitly also access to the user directory. For example my tomcat application user is a local Linux user that does not even have a password (literally no password, not an empty password, but none). This is quite a common case in the linux world.

Allow me to be a little provocative: This is a very windows centric point of view or just not true in this generalisation, whatever you prefer.
To put it simple, you just have to keep your passwords out of reach of people that should not know them. If you protect them via filesystem permissions or encryption or magic is just not relevant. As you are using SSO I’m guessing that your are using xwiki in an intranet, that means that everyone that connects to your wiki, and may be able to steal the bind_DN and bind_pass, already has the permission to read the same information on the AD. So the password is just not worth stealing. You just want to make sure to use the information of a user, that has no other grants than to connect to the AD. So your domain admin would be a bad choice :wink:

To sum up: To make your use case work currently you will have to add a very low permission user to the xwiki.cfg.

If you think that it’s worth adding the possibility to authenticate with the user running the application you could create a Jira enhancement.

To make @vmassol happy:

If you’re a developer you could provide a Pull Request.

If you’re not a provider then you need to wait for someone to fix it for you.

The last option is for you to sponsor the fix by contacting one of the companies sponsoring the development of XWiki, see https://www.xwiki.org/xwiki/bin/view/Main/Support#HProfessionalSupport

#3

Allow me to be a little provocative: This is a very windows centric point of view or just not true in this generalisation, whatever you prefer.

We will have to agree to disagree on this detail. A password stored in plain-text is always some level of risk, although I agree that the level of risk depends on what level of privilege it’s associated with.

Aside from that, there is also the administrative overhead/nuisance that when passwords must be changed (this is often an organizational requirement), you have to do it in multiple places. (I would point out that avoiding changing passwords in multiple places is one of the main purposes of having SSO in the first place.)

To sum up: To make your use case work currently you will have to add a very low permission user to the xwiki.cfg.

I figured that this was the case, but I wanted to make sure. Thank you for confirming this.

It seems like this would be a worthwhile enhancement to add to the LDAP Authenticator extension.

#4

If you think that it’s worth adding the possibility to authenticate with the user running the application you could create a Jira enhancement.

Thanks for the pointer; I created an issue: http://jira.xwiki.org/projects/LDAP/issues/LDAP-56

#5

Perfectly fine with this.

Difficult to aggree, because eventually all passwords that are used to authenticate to something have to be available as clear-text in one form or another. Even if you have a hardware security module it has a plain text password. So eventually if you crack the right nut you get to the core. The nuts just differ in the hardness of the shell.
My point of view is that, a plaintext password at least creates awareness. A whatever obscured password (and a lot of the windows features are just that) not. And you may not believe it. I’m a big fan of windows and the possibilities it has, but I don’t agree with everything.

Agreed. But separation of concern mandates for a lot of users. So I’m happy with separating the concerns of querying AD and starting the application. Naturally that means I have to change two passwords.

Disagree again. End users are something completely different. I want my end users to have the right permissions on their account. And to encourage them to have sensible and strong passwords I try to implement LDAP/AD authentication wherever possible, so they don’t have to remember/handle too many passwords. And to ease up their live even more I have SSO where possible.
But service accounts are so completely different. I handle some hundreds of them for just twenty applications I manage, because of separations of concerns.

#6

My point of view is that, a plaintext password at least creates awareness. A whatever obscured password (and a lot of the windows features are just that) not.

My view is that the fewer places one must store a password the better. Best is to have the password stored only in one place. (The service that runs the application is not in the same category, in my opinion, because the operating system does store service passwords securely, and these are easy to change in an automated fashion.)

So I’m happy with separating the concerns of querying AD and starting the application. Naturally that means I have to change two passwords.

I’m glad you’re OK with that. This can become logically difficult as the number of enterprise services offered increases.

But in any case, thank you for your input. (As noted already: We can agree to disagree.)

#7

Maybe you never enjoyed the view of dropping jaws when you extract all the passwords of all services by running the following script on windows.

“But you need to be administrator”, you might say. Yes, but you only had to write home about your coup in the right font to solve this problem.
So securely is just relative. And it’s there in plain text, it just is.
Don’t get me wrong there have been root exploits too, which jeopardize your passwords too. But at least you know, because nobody claims everything is stored securely. (This is one of the parts I dislike about windows).

#8

Of course the service passwords can be extracted using APIs (if they couldn’t, the services couldn’t start). I would say it’s better than clear-text, and due to programmatic access, easier to change in an automated fashion (again, IMO).

Thanks for the discussion!

#9

You are right, it’s the best to agree that we disagree. At least we agree on something :wink:

#10

@bstewart

Hi Bill,

We are interested in using SSO. Did you manage to get waffle to work? If you did could you please share your configuration? Following their documentation didn’t work for me :frowning: https://waffle.github.io/waffle/README.html

#11

Yes, I am using WAFFLE with Xwiki on Windows with Tomcat 9. (I’m also using SSPI with PostgreSQL on Windows. Very nice: No stored passwords except through the OS/domain, with the exception of the LDAP Authenticator app requiring a separate account with a hard-coded password in xwiki.cfg – hence this post.) All works quite nicely.

I will be putting together some generic write-ups on how to integrate WAFFLE with XWiki/Tomcat 9 on Windows. I can post some guidance here.

#12

That would be amazing! I look forward to seeing your write up.

Thanks.

#13

The description is already available here and it looks very good.

1 Like