How do you store Kerberos service keys in a Java program.
I have created a client and serverside program, where the serverside sites on my server and client is used on my computer, i can get to the serivce and use it - i then close it.
I want to reach the service again without having to log back into Kerberos, how could i do this?
Cheers
As a client? If you, oyu need a credential cache. This is done by logging in into the OS and have the cache maintained by your OS. Java accesses this cache.
Related
In our project we are using weblogic server.
If I try to login into our application i.e on machine A, a JsessionId is generated after I logged in.
Now, if I use this same JsessionId on another machine i.e machine B the application will prompt me to home page instead of login page.
Please provide a solution for my problem.
Unless otherwise configured, most servers will destroy any JSessionID it does not recognize and issue a new one. This is to prevent Session Fixation attacks. Java Servlet Engines like Tomcat and Jetty do so as will various j2EE Application Servers such as WildFly(UnderTow) and WebLogic.
If you want to have a session migration between servers nodes you will need to configure your server to do so. Servlet Engines and Application Servers will not do so automatically. You will need to look at your Weblogic docs for your version of your Application Server to determine how to do it.
I will tell you that Wildfly and Tomcat definitely require multicast-ip to make this work. Depending upon your environment it is possible that multicast-ip is blocked by firewalls. Additionally I know, as of this writing, that docker containers do not support multicast-ip out of the box so you will need some sort of work-around if you are using docker containers.
The important thing is that you understand why the session is not automatically migrated and that you need to configure your server to do so. If Weblogic uses multicast-ip that might be another hurdle to overcome.
I hope this helps. This is as specific as I can be as I am not a Weblogic developer.
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Prevent session from being replicated when JSESSIONID cookie copied
What is the best way to prevent session hijacking?
HTTP being an stateless protocol uses a session identifier (mostly a cookie) which is sent with every request which to identify the client. The most common way is to use HTTPS to encrypt your request and prevent anyone in the middle from seeing that session identifier.
One important point to consider is that if the attacker has physical access to your machine, then he/she can easily see your session identifier and there is nothing you can do about it. That's the reason why websites like facebook warn you when you open the browser console and run some scripts.
My web application is currently configured to connect to LDAP for user validation without relying on application server settings. In other words, my applications utilizes naming params to connect to LDAP hence its agnostic to application server ie. JBoss or Websphere.
Naming params used are as follows:
ldapURL
ldapPrincipal (bind user)
ldapCredentials (bind user's password)
ldapAuthentication
ldapSearchBase
The requirement now is to allow encrypted password in the ldapCredentials naming param. I have a way out of this situation is using custom SecurityLoginModule to encrypt password and supply it to application using naming param. My application would then decrypt it and then proceed with LDAP user validation. However, this results into additional application installation step.
So I was wondering if there is a way to use application server security domain (or some other way) to store the user credentials in secured fashion on application server and later application would pick it up at the time of user validation with LDAP without writing server specific code in my application. I know that we can use security domain to perform data source connection without writing server specific code. But if I do this for LDAP then I make server talk to LDAP which is not what am looking. Basically may still continue to use Federated users instead of LDAP.
Any decent application server (including JBoss and WebSphere) have server provided LDAP registry, which you can configure and use without any application specific code, and I'd strongly suggest to utilize that instead of writing your own ldap connection code.
Regarding encryption:
for WebSphere traditional, you can plug in your own class into server infrastructure to encrypt passwords see - Plug point for custom password encryption
for WebSphere Liberty - you have out of the box support for aes and hash.
for JBoss first link in Google showed me this How do I encrypt the bindCredential password in Wildfly, but maybe JBoss experts will guide you to something different.
I am trying to setup an enterprise level Spring Config Server which will be used by multiple config client applications across the company. As the encrypt.key should be common across multiple clients, is it possible to protect sensitive information of a client application from other client applications. Am I missing something? Please help me.
That is one way to set things up. You can also let the config server handle decryption so the clients only get decrypted values and secure the connection from client to server using spring security.
single sign-on (SSO) for web applications (used through a browser) is well-documented and established. Establishing SSO for Rich Clients is harder, and is usually suggested on the basis of Kerberos tickets, in particular using a Windows login towards an ActiveDirectory in a domain.
However, I'm looking for a more generic solution for the following: I need to establish "real" SSO (one identity for all applications, i.e. not just a password synchronization across applications), where on client's side (unmanaged computers, incl. non-Windows), the "end clients" are a Java application and a GTK+ application. Both communicate with their server counterparts using a HTTP-based protocol (say, WebServices over HTTPS). The clients and the server do not necessarily sit in the same LAN/Intranet, but the client can access the servers from the extranet. The server-side of all the applications sit in the same network area, and the SSO component can access the identity provider via LDAP.
My question is basically "how can I do that"? More specifically,
a) is there an agreed-upon mechanism for secure, protected client-side "sso session storage", as it is the case with SSO cookies for browser-accessed applications? Possibly something like emulating Kerberos (TGT?) or even directly re-using it even where no ActiveDirectory authentication has been performed on the client side?
b) are there any protocols/APIs/frameworks for the communication between rich clients and the other participants of SSO (as it is the case for cookies)?
c) are there any APIs/frameworks for pushing kerberos-like TGTs and session tickets over the network?
d) are there any example implementations / tutorials available which demonstrate how to perform rich-client SSO?
I understand that there are "fill-out" agents which learn to enter the credentials into the application dialogues on the client side. I'd rather not use such a "helper" if possible.
Also, if possible, I would like to use CAS, Shibboleth and other open-source components where possible.
Thanks for comments, suggestions and answers!
MiKu
Going with AD account IS the generic solution. Kerberos is ubiquitous. This is the only mechanism which will ask you for your credentials once and just once at logon time.
This is all feasable, you need:
A KDC
Correct DNS entries
KDC accounts
Correct SPN entries
Client computers configured to talk to the KDC
Java app using JAAS with JGSS to obtain service tickets
GSS-API with your GTK+ app to obtain service tickets
What did you figure out yourself yet?
Agreed with Michael that GSSAPI/Kerberos is what you want to use. I'll add that there’s a snag with Java, however: by default, JGSS uses its own GSSAPI and Kerberos implementations, written in Java in the JDK, and not the platform’s libraries. Thus, it doesn’t obey your existing configuration and doesn’t work like anything else (e.g. on Unix it doesn’t respect KRB5CCNAME or other environment variables you’re used to, can’t use the DNS to locate KDCs, has a different set of supported ciphers, etc.). It is also buggy and limited; it can’t follow referrals, for example.
On Unix platforms, you can tell JGSS to bypass the JDK code and use an external GSSAPI library by starting the JVM with:
-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so
There is no analogous option on Windows to use SSPI, however. This looks promising:
http://dblock.github.com/waffle/
... but I haven’t gotten to addressing this issue yet.
I use Java Web Start. The file is on http server, that needs name and password (it's windows server). What the Java Web start does is this (with user and IP redacted):
The same on MS Windows client. There is this "Save this password in your password list" option, that does nothing at all (on both Mac OS and Windows), when running this java web start app again, it wants the password again.
Is it a bug in JWS? Or what is going on exactly?
I just had the same problem.
turns out you need to restart your web browser to have the java remember your password.
I also allowed that java cache, but i dont think that was the solution.
I've implemented a workaround for this problem. You can use some kind of cookie based authentication for supporting password authentication.
In my case when a successfull login happens using the HTTP basic authentication i send a cookie in my servlet which holds the username and password the same way the HTTP header contains it when Basic method is used (BASE64 encoded). Web Start stores this cookie in Internet Explorer's cookie store on Windows (on other systems Web Start has it's own cookie store). Web Start then sends this cookie everytime a resource is being accessed from my domain. You can specify a very long lifetime for the cookie (like 10 years) which will probably outlasts the current OS installation anyway.
On subsequent requests i check for the present of the cookie and try to validate the user according to that. If the Cookie auth is invalid and no HTTP Authorization header received (or that's invalid also) i'm sending the HTTP 401 Unauthorized status.
The disadvantage is that username and password is being stored as a cookie on the computer. The password is being sent through the network the same way as with HTTP Basic authentication just in a different header so you can protect it with HTTPS.
This also solves the lack of password remembering option on Linux Web Start.
I implemented the cookie idea, the trouble is now, how do you clear the cookie, if you want to? I mean, nice that the cookie is persistent, but what if the user wants to clear the cookie? As far as I see, the Java console has no option to do it. Clearing the web start cache doesn't seem to do it. On Windows, supposedly IE stores it, so IE gives an interface (haven't tested it myself). But on Mac and presumably Linux, I just can't find out where they are stored. Tried looking in preferences files, and tried blowing away the whole Java cache folder, but they are still stored somewhere. Anyone have an idea?