I need to connect to Unix Server using Java via SSH and SFTP protocol and execute specific commands and do File Transfers also. But there is RSA token authentication is enabled on Unix. So I need to get the current RSA token password at run time also along with User's Password.
So how to get this done
via Java? Is there any Java API for this?
FYI, Unix Login steps using putty :
connect using Server IP.
List item
give User Name.
give Password
give the 6 digit SecurID generated Number.
This sounds like keyboard-interactive authentication. In this authentication mechanism the server asks user a question, to which the user must respond. Any number of questions is possible and their order is defined by the server.
Keyboard-interactive authentication is used by many servers, but it's usually reduced to asking for a password, so most software which claims support for this authentication method will just put a password as the answer and that's all.
I don't know if free Java libraries support keyboard-interactive authentication with multiple questions. Our SecureBlackbox classes have an event which passes questions to the application, and the application can either provide an answer itself or ask the human operator to provide the answer.
Related
I have login and password for RDP. I can connect to remote desktop using standard program in Windows. However, what I need is not to connect and see desktop but check whether the login and password pair is valid or not. And I need to realize it using Java. I have idea to use socket and RDP protocol but it is very low level for me. I need some ready realization over these (library). I hope I explicitly explain my problem.
I need to develop a web application for the Intranet users. I don't want them to enter the login credentials each time they visit the site. It should be automatically loaded from the System Username and Password.
I have successfully implemented functionality which prompt user name and password registered with active directory and validate against LDAP. I need some tips to login directly from intranet website without prompt username & password.
Here is my queries, please let me know your suggestion.
Is it compulsory to set SPN?
Do we need to create separate keytab file for each client? In my organization, there is around 800 people are working so should I need to add all client principal in keytab file & copy to client machine to perform autologin.
I have tried many API's like JESSO, Waffle, Spring Kerberos, SPNGO but failed to implement auto login.
If you want to use Kerberos/SPNEGO (which would be my recommendation) you do have to set up SPN. And you only need one keytab for AD domain. Are you running your Java program on some app server, like Weblogic, or as a standalone program? Servers do have security framework that you could use, while for standalone program you'd have to do a bunch of stuff manually.
I've found that the easiest way to do this is to use Atlassian's Crowd (https://www.atlassian.com/software/crowd/overview) instead of implementing it yourself. It's a commercial product, but last time I checked, it was dirt cheap, and it just works.
I write a web application I have to do signin in that using the windows username..
I tried to get username using system.get property() but its giving the username of server windows name only.but I want to the username of client system..can any one help me?
If I understood you correctly you want to sign in to the web application using the Windows credentials. If so - the problem is that the server machine knows nothing about the client. It can provide you the user info only after successful login (see Get windows username using JAVA or JSP).
You could point your system to some user store (e.g. LDAP) that will be used by both Windows system and your app. In this situation you will be able to sign in to the app using Windows credentials.
The Browser is an application to generate the view based on an HTML code. It wont give access to the client machine.
You can use request.getRemoteUser() to get the user name, that too is possible only if its allowed in the client machine.
If your client is running on a windows machine you can get the user name using this
var wshshell=new ActiveXObject("wscript.shell");
var username=wshshell.ExpandEnvironmentStrings("%username%");
This is a solution for getting the user name, but i will never recommend this, it surely is a bad practice.
Is the entire Java application running on the server? How would your application even know about a specific client machine? And how would it deal with concurrently logged in users? And how would it deal with a primitive client machine which does not have a notion of a user name?
You can instead run a Java applet which is invoked on the client's machine. You could the send this information to the server to process. However, your users would most likely not like that and not grant the required privileges.
Alternatively, you could try to use JavaScript to read the user name, in case that you are communicating via a webpage. I want to stress the word try in this context since there is not universally functional approach and most users will most likely not allow you to read this property either.
In a nutshell: Users do not normally want to share this information with you and therefore you cannot access it. If you could, you would have found a security hole which would most likely get fixed. Rather, ask your application's users to enter a name to use for whatever reason you would require it. Or, if this is an option, organize for example your Windows credentials in a service that can be accessed by a standardized API.
JNDI LDAP auth requires a cleartext password to be passed (Context.SECURITY_CREDENTIALS) to almost all security mechanisms (or at least how I understand it). It looks like to be designed in a way, that the password originates from the current JVM. But what about a password, that has to be sent from another machine? This approach forces it to be sent in a recoverable fashion (the most simple is cleartext) with little security.
To be more specific, let's consider a 3-tier setup: client, java server and an LDAP server. The user enters the username and password in the client which is sent to the java server. Then the java server communicates with an LDAP server in order to authorize these credentials. Is there a way to make the transmission from the client to the java server secure?
I understand, that we can use SSL or another way to secure the channel itself, but it's still no good that we have to send the password in a recoverable fashion through this (even secure) channel.
I tried to search for an answer, but it looks like most of them consider a 2-tier setup. There were also some 3d party java libraries recommendations (instead of JNDI), but it wasn't clear, if that they can handle my task. If they actually do so, could you please give an example utilizing them for my task?
My target platforms are Delphi XE3 Client, Java SE 6 Server and an AD LDAP. But I'm also interested in a more theoretical discussion not restricted to these concrete client and LDAP.
This approach forces it to be sent in a recoverable fashion (the most simple is cleartext) with little security.
The approach requires you to use SSL. It's as simple as that.
We found the answer and actually made it work on a production system.
The correct path is to use the Kerberos protocol http://en.wikipedia.org/wiki/Kerberos_(protocol).
In my setup the following happens:
1) The client obtains a ticket to the server service in the AD and sends it to the server. This is done via classes near TSSPIWinNTCredentials class in Indy, but I think it's quite possible to do so without difficulties using Windows functions directly.
2) The server logins to the AD as a service. This is done via LoginContext class using correct AppConfigurationEntry with keys.
3) The server authenticates the client in the AD using client's ticket, obtaining client's username. This is done via Subject.doAs method and classes near GSSManager class.
4) The server performs additional business level checks and grants the client a business session. This is business-specific of course.
At no point in this scenario any insecure communication is made, including sending passwords in a recoverable fashion, because it is the design goal of the Kerberos protocol itself.
We have a Rest API that requires client certificate authentication. The API is used by this collection of python scripts that a user can run. To make it so that the user doesn't have to enter their password for their client certificate every time they run one of the scripts, we've created this broker process in java that a user can startup and run in the background which holds the user's certificate password in memory (we just have the javax.net.ssl.keyStorePassword property set in the JVM). The scripts communicate with this process and the process just forwards the Rest API calls to the server (adding the certificate credentials).
To do the IPC between the scripts and the broker process we're just using a socket. The problem is that the socket opens up a security risk in that someone could use the Rest API using another person's certificate by communicating through the broker process port on the other person's machine. We've mitigated the risk somewhat by using java security to only allow connections to the port from localhost. I think though someone in theory could still do it by remotely connecting to the machine and then using the port. Is there a way to further limit the use of the port to the current windows user? Or maybe is there another form of IPC I could use that can do authorization using the current windows user?
We're using Java for the broker process just because everyone on our team is much more familiar with Java than python but it could be rewritten in python if that would help.
Edit: Just remembered the other reason for using java for the broker process is that we are stuck with using python v2.6 and at this version https with client certificates doesn't appear to be supported (at least not without using a 3rd party library).
The most simple approach is to use cookie-based access control. Have a file in the user's profile/homedirectory which contains the cookie. Have the Java server generate and save the cookie, and have the Python client scripts send the cookie as the first piece of data on any TCP connection.
This is secure as long as an adversary cannot get the cookie, which then should be protected by file system ACLs.
I think I've come up with a solution inspired by Martin's post above. When the broker process starts up I'll create an mini http server listening on the IPC port. Also during startup I'll write a file containing a randomly generated password (that's different every startup) to the user's home directory so that only the user can read the file (or an administrator but I don't think I need to worry about that). Then I'll lock down the IPC port by requiring all http requests sent there to use the password. It's a bit Rube Goldberg-esque but I think it will work.