Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of borut.hadzialic@gmail.com
 designates 74.125.82.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=FmHo7l8QBpFi1b/h4mFaWjeW5WtA4Icixp74wgrduQVM+FVJ9qaGNJs27z4n4uotat
         Mx+FxJ9ForjnfdcQiVCJbE/Tg/cFEUs2BepftaXI18Ktf9Uxmdp7SAaXfEv3NmMtgX4g
         ceiqj7gCq1N2ql73dbbnd2VGga+dSPEEJnF+s=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=_gE6v7v2crcxtTtNWyh75pF6tm-diKjEhT3+e@mail.gmail.com>
References: <AANLkTimUpOn3JQu5OKMZkQ1gswBmO+HRv3CtpDa_hvVu@mail.gmail.com>
	<4D73925C.8060207@ice-sa.com>
	<AANLkTimCE0acm-NaPr0cxvj2dbapw6u98ogzf3XZGA2E@mail.gmail.com>
	<AANLkTi=_gE6v7v2crcxtTtNWyh75pF6tm-diKjEhT3+e@mail.gmail.com>
Date: Mon, 7 Mar 2011 11:03:25 +0100
Message-ID: <AANLkTimWOnj1NN6E32mouWtNxdYwn9vstFBTad_nhnXc@mail.gmail.com>
Subject: Re: Tomcat NTLM Authentication
From: =?UTF-8?B?Qm9ydXQgSGFkxb5pYWxpxIc=?= <borut.hadzialic@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the links I sent you was broken, the right link is:

Oracle Jdbc connection with kerberos
http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/clntsec.htm#CI=
HCIDHF

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

On Mon, Mar 7, 2011 at 10:55 AM, Borut Had=C5=BEiali=C4=87
<borut.hadzialic@gmail.com> 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:
> http://blog.springsource.com/2009/09/28/spring-security-kerberos/
>
> Some general information about kerberos from msdn:
> http://msdn.microsoft.com/en-us/library/ms995329.aspx
> http://msdn.microsoft.com/en-us/library/ms995330.aspx
>
> Very nice articles about credentials delegation (you need that so your
> app server can impersonate clients when it connects to the database)
> http://s2.diffuse.it/blog/show/6602-SPNEGO_authentication_and_credential_=
delegation_with_Java
> http://spnego.sourceforge.net/credential_delegation.html
>
> 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:
> https://jira.springsource.org/browse/SES-11
>
>
> We use Oracle as the database and some materials that were helpfull were =
these:
> Oracle Jdbc connection with kerberos
> http://download.oracle.com/docs/cd/E11882_01/java.112/e10589/clntsec.htm#=
insertedID7
> http://download.oracle.com/javase/6/docs/api/javax/security/auth/Subject.=
html
>
> Some general info on Oracle Advanced Security
> http://download-west.oracle.com/docs/cd/B14099_19/idmanage.1012/b14085/od=
ip_actdir001.htm#CHDDFFGG
>
> 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 =D7=94=D7=99=D7=9C=D7=94 <hilavalensia@gmail.com>:
>> Hey,
>>
>> The tomcat is running on windows server 2008 R2 STD
>> I don't now if using windows authentication is less secure and affects a=
ll
>> 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 secur=
e 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=C3=A9 Warnier <aw@ice-sa.com>
>>
>>> ???? 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 lett=
ing
>>>> 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 th=
is
>>>> page-
>>>> http://wiki.apache.org/tomcat/FAQ/Windows#Q4
>>>>
>>>> Which suggest these methods:
>>>> -Waffle/JNA
>>>> -Tomcat SPNEGO
>>>> -SPNEGO SF
>>>> -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 wind=
ows
>>>> 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 b=
e
>>>> what
>>>> I aim for, since tomcat users are not interest me, only the tomcat win=
dows
>>>> service and how it connects to the DB
>>>>
>>>> =C2=A0Exactly. Now you have the issue correctly framed.
>>> And you are right above : all these methods indeed identify/authenticat=
e
>>> 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 se=
rver
>>> is running on a Windows machine.
>>> And also that your back-end database system is able itself to perform u=
ser
>>> authentication either in clear-text (user-id + password), or via Window=
s
>>> 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 n=
ot
>>> work with a "server-local" user-id).
>>>
>>>
>>> So now you have to make one additional effort of thinking rationally, a=
nd
>>> answer the following fundamental question : why ?
>>>
>>> I mean, what exactly is the problem with having a user-id and a passwor=
d
>>> for the database, in clear in a Tomcat configuration file ? =C2=A0Are t=
here users
>>> that can connect to the Tomcat server, and read those configuration fil=
es,
>>> 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 whi=
ch
>>> 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 "serve=
r
>>> local" user-id than as a Domain user-id. =C2=A0That is because the loca=
l user-id
>>> only gives access to the local machine, while a domain user-id gives ac=
cess
>>> to the whole domain.
>>> By running Tomcat as a domain user, you decrease the security of the wh=
ole
>>> network.
>>> 3) security is always a matter of multiple layers of defense. =C2=A0In =
this
>>> case, your first line is to prevent unauthorised people to access the T=
omcat
>>> configuration files.
>>> Because if they can do that, then they can break through any other secu=
rity
>>> that you would put in place. =C2=A0Think about it : no matter how, Tomc=
at 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 accept=
s
>>> connections from Tomcat. =C2=A0This 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 no=
t
>>> know what this user-id is. =C2=A0So this application could for example =
dump the
>>> whole database in some network directory of my choice (and then, if I a=
m
>>> really a bad guy, delete the database too).
>>>
>>>
>>> (**) unless you want real security of access to the DB, and have the To=
mcat
>>> application make its own connection to the DB, and authenticate to the =
DB as
>>> the final user of the application.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
>
>
> --
> Why?
> Because YES!
>


--=20
Why?
Because YES!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org