I'm using Microsoft SQL Server 2008, latest SP. the use of domain user is used with the jtds package, which allows the tomcat service to authenticate to the DB with the presence of native SSPI DLL called ntlmauth.dll However, it generated a memory leak in the server. So I'm looking for alternatives.
Thanks Hila 2011/3/7 Borut Hadžialić <borut.hadzia...@gmail.com> > Yes Andre you are right, I misunderstood the OP - Hila wants to access > the database as a single domain user. > > How to implement this is probably database specific. For example > Oracle jdbc driver requires you to either: > A) be running the process which makes the database connections as the > domain user which can access the database. > B) somehow get an instance of javax.security.auth.Subject representing > such an user, for example by using a kerberos keytab file. > > There are code examples for A) (connectWithDefaultUser()) and B) > (connectWithSpecificUser()) on the page i linked in the last mail. > > The problem after that is how to get connection pooling (you might > need to implement you own). > > Hila, what database are you using? > > > On Mon, Mar 7, 2011 at 11:59 AM, André Warnier <a...@ice-sa.com> wrote: > > Borut, > > > > thanks. I think that this is very helpful. > > It does not do what the OP wanted to do, but it does what he /should/ be > > doing (in my view). > > > > הילה, > > if the users connect to Tomcat, and the connections to the database are > all > > done under the "Tomcat" user-id, then basically you are putting all the > > users into one big pot, and the database does not know who is really > > connecting to it. > > That means that now any of the users can do in the database anything that > > this "Tomcat" user-id can do, and you can never find out afterwards who > did > > it. > > And because this "Tomcat" user needs to be able to do in the database > > anything that any user could do, it needs to have very broad rights to > the > > database (the sum of all the users rights). > > In the scheme below, that is not true : each user connects to the > database > > under his own user-id, so the database can decide who is allowed to do > what, > > and can also keep track of who did what. > > > > > > 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: > >> 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/odip_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 הילה <hilavalen...@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 > >>> 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 <a...@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 > >>>>> 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- > >>>>> 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 > >>>>> 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: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>>> > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > -- > Why? > Because YES! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
