Our customers connect to our databases exclusively with jdbc thin client calls on the SSL port, authenticating externally with PKI certificates in keystores. I would like to collect some of their client certificate information at logon time, as I would be able to do using OWA_UTIL.GET_CGI_ENV if they were connecting via https.
I've researched this for quite a while now, and I've found something in the SYS_CONTEXT userenv parameters called AUTHENTICATION_DATA that seems promising. However, the documentation states only that for users connecting externally with x503 certificates (do they mean x509v3?), that parameter contains "Data being used to authenticate the login user. For X.503 sessions, returns the context of the certificate in HEX2 format."
That's all Oracle has to say about that. No documentation of "HEX2 format" exists. No explanation anywhere about how to view the authentication data.
Does anyone have any experience using that data or at least reading what it really is?
Related
I am trying to build a client / server servlet application with these general requisites:
both the client and the server are jetty embedded;
the server expose a servlet in order to receive json data via POST;
the connection must be secured via SSL (i.e. the connection will be done via Internet via https);
I want that only my Jetty client be able to send data to my server, all other tentative must be refused by the server;
the server and the client are unattended machines (i.e. not password via command line could be inserted by human);
no password in clear must be stored on the client device. In general I don't want someone could open the remote client device and stole the password and building a fake remote device capable to send data to my server too.
I have build a perfectly working client / server application via HTTP but I am confused about the security.
I have read that there is the possibility to use client / server mutual authentication and seems what I am looking for but I can't get the complete picture.
In this document client-certificate-authentication there is a more or less clear explanation about how to build a shared trusted CA but the password for accessing the TrustStore and the KeyStore are in clear in the code.
I think I am missing a tile in the puzzle.
Could someone point me in the right direction?
Thanks,
S.
I'm going with a simple answer (for now).
If you just want only your clients to talk to the server, then yes, Client SSL/TLS certificates are the way to go.
You'll want the server's SslContextFactory.Server.setNeedClientAuth(true) set to true. That will in turn cause Java's javax.net.ssl.SSLParameters.setNeedClientAuth(true) to be set on incoming connection establishment. If the client fails to provide the client certificate, the connection is closed, and no HTTP request is sent or processed.
As for securing the client certificate, that's up to you, you can do anything you want to do, as long as it results in a valid client SslContextFactory.Client that the Jetty client can access. This includes ...
Using plaintext passwords
Using obfuscated passwords (minimal effort, minimal security)
Encrypted keystore/truststore passwords elsewhere in your client, provided to the SslContextFactory.Client at the last minute. (modest security, wouldn't be that hard to figure out)
Creating the java.security.KeyStore object yourself and handing it to SslContextFactory.Client.setKeyStore(KeyStore) and SslContextFactory.Client.setTrustStore(KeyStore) methods prior to starting the Jetty Client. (a bit better security wise, puts more work on your behalf)
You might want to consider having the client certificates be short-lived (24 hours?) dynamically refreshed from the server, and have the client certificates be revokable (at the server/CA side) if you encounter abuse. (such as the same client certificate from multiple different client IPs)
I'm trying to improve some code that enables logging in to our application using digital certificates, probably certificates stored on PKCS11 tokens.
It's a Java client server application, with the server on JBoss [Wildfly], and a rich Java thick client. We also have a GWT/Javascript based web client, but this doesn't yet support certificate auth.
The current implementation uses 2-way SSL authentication if certificate authentication is configured, i.e. the server will require a client certificate when the connection is opened. This causes some problems, and in trying to find ways to address them I've been searching madly to see if there is a standard, 'Right Way To Do PKI Auth To A JBoss Application'.
However just about everything I have found on the subject seems also to revolve around using two-way SSL, which kind of implies that is the Right Way to Do It.
It seems undesirable to me, in that the network transport is quite a low-level concern, heavily separated from the application logic and stuff like authentication and user management.
In order to prove the client is a valid user of the system (as opposed to merely someone with credentials endorsed by a CA in the server trust store), the server application logic has to rummage around looking to find the certificate that was used on the incoming connection in order to scrape the Common Name off it. I've discovered that javax.servlet.request.X509Certificate is a standard-ish parameter one can query on the servlet, so it ought at least to be possible.
The other architectural problem this causes is that our app requires reauthentication for the lifetime of certain sensitive operations. If one is using the SSL connection to prove the user has the private key, then logically that would require opening a whole separate connection.
Logically, authenticating with a certificate would seem to require
The server generating a nonce
The client encrypting the nonce using the client's private key
The client sending that encrypted value to the server with the accompanying public certificate [or certificate chain].
Now, that is exactly what happens during an SSL handshake, but obviously a whole load of other baggage comes with it that is irrelevant to the application-level concern of authenticating the user.
I thought about implementing the steps directly myself, but this would seem to violate the first rule of crypto (Don't implement your own crypto).
If the server generates random nonces then that introduces a level of chattiness and statefulness to the process, which is doable but a pain when you are striving for a stateless and clusterable server.
Time-based One-Time Password implementations circumvent this, and seem to be a standardized mechanism for 2-factor authentication that is getting support from Google+ and the like.
However I can't find anything in the way of out-of-the-box libraries that will let me build an implementation using certificates directly from an imposed PKI.
Currently I have got a specific problem finding a solution and I am hoping you are able to provide
some light on the matter.
The Structure of the problem:
The task at hand is to gather a client's login credentials (token) and pass this to the servlet. However I cannot seem to find a good resource to do this. I have researched a wide variety of ways. I.e SPNEGO, WAFFLE etc..., However, these seem to require some sort of active directory by my understanding, I am trying to gather the credentials from the users local machine. A clear explanation or guidance to how I can gather the windows credentials to the servlet for my specific request would be appreciated.
Diagrams are always a better way of explaining so I will provide one if you are still confused:
Windows PC (Client) ------------------------> Java Servlet -------------------------------------> IIS Server
(windows authentication) --------------> (Get Credentials) -------------------- (Check Credentials & Authenticate)
(token) (pass credentials)
Thank you in advanced to anyone who replies, I really appreciate it!.
You are wasting your time. If you only take the credentials from the users local machine then you have no way of knowing if those credentials can be trusted. You might as well just give every user administrative access to your web application.
The reason active directory (or something like it) is required is that it is not under the control of the client and is trusted by the server. For example, when using SPNEGO, the client authenticates itself to the windows domain, the client gets a token from the windows domain that it can only get if it is authenticated, the client passes the token to the server, the server can then validate that token with the Windows domain to confirm that the client is indeed who they claim to be. (Not quite that simple but you get the idea.)
There are other ways to do this - e.g. with PKI - but they all have in common a central, trusted authentication system that the server can use to validate credentials provided by the client.
I have a java application that connects to an external sql database using jdbc 4. It uses prepared statements to select data from the database and also to send updates. Can the data that's transferred between the database and my application be classified as encrypted or are there further steps I would need to take in my application for it to be encrypted?
No, PreparedStatement does not equate to encryption. You would need to enable (better yet if you can require it; my familiarity is with postgresql rather than mysql) SSL on the server and set up a certificate and private key. You would then need to instruct your application to use SSL and to accept (only) the certificate belonging to the server.
Note that SSL and encryption in transit, while useful, does not protect the data from an attacker who gains access to the database.
PS. Most likely ServerFault would be the best resource for answers regarding how to configure mysql.
Edit for follow on: According to the documentation the credentials in the initial connection are secured.
How does the SQL Server JDBC Trusted Connection Authentication work? (ie how does the trusted connection authenticate the logged in AD user in such a transparent and elegant fashion and how can I implement a similar authentication solution for my client-server applications in Java without a database connection or any use of the existing SQL Server solution.)
Assumptions
* Working within a Windows 2003 domain
* You have access to the Windows API via JNI/JNA
It depends on the client. For example if you have a Web Browser, it can use the NTLM Authentication to pass the domain authentication of your current client to the server. In this case the browser like IE or FF supports this, and you web server needs the support for NTLM. For example here for Tomcat: http://jcifs.samba.org/src/docs/ntlmhttpauth.html
There is also the SPNEGO protcol in combination with Kerberos, as explained here: http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/lab/index.html
If you have your own client, it depends on the client's framework if it is able to use the local user's security context and is able to pass it on. The page above describes this at least for a kerberos scenario.
Greetings
Bernd
PS: I am not sure if you can pass the authentication context established with the jcifs/ntmlm solution to a backend component like SQL Server. It should work with Kerberos tickets (if configured).
jTDS and Microsoft JDBC Driver both offer native Windows Authentication.
Have you looked at this question? The situation seems to be similar to yours (connecting to a SQL Server database using Windows authentication).