tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Borut Hadžialić <>
Subject Re: Tomcat NTLM Authentication
Date Mon, 07 Mar 2011 10:03:25 GMT
One of the links I sent you was broken, the right link is:

Oracle Jdbc connection with kerberos

Or just google for 'oracle jdbc kerberos' if they move the content again.

On Mon, Mar 7, 2011 at 10:55 AM, Borut Hadžialić
<> wrote:
> Hi Hila,
> I have a similar requirement in my current project. End users (using
> browsers and java desktop apps) which work on windows workstations
> which are in a domain, must be able to log in the application without
> needing to type in username and password (using their windows
> credentials). Additionaly, the connection to the underlying database
> must also be done using those user credentials.
> My steps while implementing this were:
> 1. Implement authentication (browser->server, desktop app -> server)
> which uses kerberos
> 2. Enable credential delegation so your app server can impersonate
> client when connecting to the database
> 3. Connect to the database as the client from within app server
> code/process (this is database-specific)
> This is how I solved it:
> I use SPNEGO for browser/webapp scenario authentication. These
> materials helped me come up with a working server side SPNEGO
> implementation:
> This is what I ended up using for reading a SPNEGO token:
> Some general information about kerberos from msdn:
> Very nice articles about credentials delegation (you need that so your
> app server can impersonate clients when it connects to the database)
> I also had some java desktop apps which needed to authenticate in a
> similar way, which use Spring HttpInvoker as a remoting protocol, so I
> decided to make HttpInvoker pass some SPNEGO headers as well, and it
> seems to work:
> We use Oracle as the database and some materials that were helpfull were these:
> Oracle Jdbc connection with kerberos
> Some general info on Oracle Advanced Security
> If you also use Oracle I can send you a complete code example for this
> - I have the whole thing working for simple tests..I should have a
> more complete implementation in few weeks.
> Cheers.
> 2011/3/7 הילה <>:
>> Hey,
>> The tomcat is running on windows server 2008 R2 STD
>> I don't now if using windows authentication is less secure and affects all
>> network's security, since this user have permissions only on the DB. you
>> can't even perform login to servers with this user.
>> anyway, I appreciate your comments and discussion of why it's less secure or
>> not, but I need to perform this (task I've been given from guys in high
>> above positions), so please help with what I'm trying to do :]
>> If I can't use spnego and other stuff of the list i've found, what can I do?
>> Thanks
>> Hila
>> 2011/3/6 André Warnier <>
>>> ???? wrote:
>>>> Hey,
>>>> I want to change the way that tomcat authenticates to the DB of our
>>>> application, from SQL authentication to Windows authentication.
>>>> We use Tomcat 6.0.29 , and the user and password to connect to the DB is
>>>> specified in clear text in the xml configuration file under the folder
>>>> conf/catalina/localhost.
>>>> My goal is to remove the user and password from the xml file, and letting
>>>> the tomcat windows service run with a domain user that has permissions to
>>>> the DB.
>>>> when I searched for a solutions for what i'm trying to do, i got to this
>>>> page-
>>>> Which suggest these methods:
>>>> -Waffle/JNA
>>>> -Tomcat SPNEGO
>>>> -Jespa (commercial)
>>>> -Tomcat IIS Connector
>>>> -Samba JCIFs (obsolete, no NTLMv2)
>>>> Are one of these methods suit for what I'm trying to do?
>>>> When reading about Tomcat SPNEGO, it says that users working on a windows
>>>> client OS and IE or Firefox, can be silently authenticated (SSO) to a
>>>> Tomcat
>>>> running on a windows server via NTLM or kerberos. It doesn't seem to be
>>>> what
>>>> I aim for, since tomcat users are not interest me, only the tomcat windows
>>>> service and how it connects to the DB
>>>>  Exactly. Now you have the issue correctly framed.
>>> And you are right above : all these methods indeed identify/authenticate
>>> the client of the Tomcat application to Tomcat, not Tomcat itself to
>>> something else. (**)
>>> The one thing missing in your description above, is that your Tomcat server
>>> is running on a Windows machine.
>>> And also that your back-end database system is able itself to perform user
>>> authentication either in clear-text (user-id + password), or via Windows
>>> NTLM authentication.
>>> (And, if the back-end database server is set to do NTLM authentication,
>>> then it can only do so for Domain user-id's; NTLM authentication will not
>>> work with a "server-local" user-id).
>>> So now you have to make one additional effort of thinking rationally, and
>>> answer the following fundamental question : why ?
>>> I mean, what exactly is the problem with having a user-id and a password
>>> for the database, in clear in a Tomcat configuration file ?  Are there users
>>> that can connect to the Tomcat server, and read those configuration files,
>>> and which should not be able to do so ?
>>> And if that is the case, can you not do something like :
>>> a) either block these users from accessing the Tomcat server (the best
>>> solution)
>>> OR
>>> b)
>>> - start Tomcat under some Windows user-id (with password)
>>> - set the permissions of the Tomcat configuration files, so that *only*
>>> this user-id can read them ?
>>> Various people have previously tried to point out different aspects which
>>> remain true, among which :
>>> 1) encrypting something is often a chicken-and-egg kind of problem : if you
>>> encrypt something, then you need to decrypt it somewhere else; and the key
>>> to decrypt it has to be stored somewhere also. And so on..
>>> 2) in terms of security, it is much better to run Tomcat under a "server
>>> local" user-id than as a Domain user-id.  That is because the local user-id
>>> only gives access to the local machine, while a domain user-id gives access
>>> to the whole domain.
>>> By running Tomcat as a domain user, you decrease the security of the whole
>>> network.
>>> 3) security is always a matter of multiple layers of defense.  In this
>>> case, your first line is to prevent unauthorised people to access the Tomcat
>>> configuration files.
>>> Because if they can do that, then they can break through any other security
>>> that you would put in place.  Think about it : no matter how, Tomcat needs
>>> access to the DB. If Tomcat has access to the the DB, then any user who can
>>> control Tomcat can access the DB. (*)
>>> 4) your second line of defense, would be that the DB server only accepts
>>> connections from Tomcat.  This way, if someone can get hold of the user-id
>>> of Tomcat, at least they cannot use it to access the DB directly.
>>> (*) Suppose Tomcat runs under domain user-id XYZ, with a very secret
>>> password.
>>> If I can get access to the Tomcat configuration files, then I can also
>>> install any Tomcat application somewhere, and make Tomcat run it.
>>> And this application will run under the Tomcat user-id, even if I do not
>>> know what this user-id is.  So this application could for example dump the
>>> whole database in some network directory of my choice (and then, if I am
>>> really a bad guy, delete the database too).
>>> (**) unless you want real security of access to the DB, and have the Tomcat
>>> application make its own connection to the DB, and authenticate to the DB as
>>> the final user of the application.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> --
> Why?
> Because YES!

Because YES!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message