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#CIHCIDHF
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ć <borut.hadzia...@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/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 >>> >>> >> > > > > -- > Why? > Because YES! > -- Why? Because YES! --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
