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?
Related
I'm playing around with Kerberos SSO. As experimented so far,
When I open a web app that is configured with Kerberos, from the browser, it prompts me for the username and credential, once I enter, I'm logged into the web app .
When I do a kinit from the terminal and give my credentials, I'm signed into the KDC for the given user. After kinit, when I open a web app I'm signed into the web app, without any credentials.
One possible explanation is, when I do a kinit, the TGT is stored in the OS which is available for other clients in the host machine so that my browser was able to use that TGT without prompting me for password.
Now my questions are,
Will I be able to cache the TGT without using kinit?
If yes, how can I do it using a Java client?
If the answer for the first question is yes, will I be able to do it from my web app opened in the browser?
Whenever kinit is executed, a TGT is requested and stored in OS ticket cache.
This TGT can be used to get TGS (service ticket) for multiple services.
If you haven't added your app url as a 'trusted intranet site' in browser, then browser will give you pop-up for the first time for every new session.
Browser accepts the credentials, gets the TGT from your KDC, and puts it in cache. Furthermore, using this TGT, it ask the KDC for the TGS to your app url (usually identified as "HTTP(S)/APP_SERVER_HOSTNAME").
You can verify this-
Perform klist purge to clean all the tickets from cache.
Open browser and hit your app url.
Provide credentials in pop-up and submit.
Execute klist- observe there are two tickets in cache.
One of the ticket is TGT, which spn like - krbtgt#XXX.domain.
The other is TGS for your service - usually "HTTP(S)/APP_SERVER_HOSTNAME".
Please note:
TGT is created by default when you login to the OS. So you can see there's a TGT for your user in OS cache.
OS ticket cache behavior can be platform specific (not verified by me).
You can obtain TGT/TGS or even delegate the credentials using (java)code.
Cache mentioned in your KRB conf is not necessarily the OS ticket cache.
For credential delegation, check out this - Java SPNEGO Authentication & Kerberos Constrained Delegation (KCD) to backend service
For the past couple of years we've been developing a client/server application and it's been working well with us hosting the server and applications. I've recently started work on getting our mobile app to connect and have run into a snag.
The mobile app can login and obtain a token but when it presents that token for an API call Owin is failing to create a valid Principal.
The same API call from our desktop app (running on the same physical machine as the server) has an HttpRequestMessage "MS_OwinContext" property with the Authentication.User field populated. The same call from the mobile does not.
Yet both of them seem to be sending the same API request (different bearer token of course). Alternative can anyone tell me where I might at least start looking or how I could get information from OWIN as to what it's doing? It's also worth pointing out that the mobile app (Xamarin) shares most of its code with the desktop application.
Right now I'm staring at a black box and all I know is that 'it doesn't work'.
Okay the problem was that the server was setting Authority in the bearer options to be localhost. Audience is derived from this so when connecting using the host name validation fails.
The answer appears to therefore not use localhost as part of the authority.
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.
We recently changed the IP-address on a server hosting one of our services based on .NET Web API 2.
The service is using OAuth2, providing external logins via Facebook/Google.
We're still using the same server and the same host name for our services, only the IP-address has changed. Now I'm getting back my login URL with "&error=access_denied" whenever I try to login using Facebook/Google.
I have checked every setting in both Facebook's and Google's developer consoles but nothing seems to apply. If I remove the OAuth redirect URI, I get an error that the URL is blocked, so the settings seems to take effect.
What have I missed?
Funny how asking a question makes you think even more outside of the box. The culprit was that wrong DNS-server was set on the web host.
I'll see myself out...
I have a PowerShell script that uploads a batch of files to lingq.com.
I created it the following way: I logged in to the site via browser, and made an upload manually through the web page. I grabbed the request in Fiddler, then duplicated it in PowerShell, including the authentication cookies. I'd just swap out the content of the request and send it. It wasn't pretty, but it worked and saved me an immense amount of time. The only downside was every time I had to log in to the site again, my authentication cookies got invalidated and I had to grab them again. But that I could live with.
They seem to have changed all their communication to https, because now instead of a request to
http://www.lingq.com/learn/ja/import/contents/?add
all I see in Fiddler is
"Tunnel to www.lingq.com/443"
Fiddler also gives me a warning that HTTPS decryption is disabled. When I enable it, and start capturing, Firefox gives me a certificate error when I try to access the site (or any other site that uses certificates, including Google):
www.lingq.com uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
My script is now completely useless, every request I send returns the login page. And because of Fiddler messing up the certificates, I can't further reverse engineer the site to mimic the requests correctly.
How can I make https decryption work in Fiddler? Alternatively, is there a way my script can properly authenticate itself on the site? I have tried the steps described here:
How to make an authenticated web request in Powershell?
It didn't work at all. My guess is some sort of federated authentication is in place, but frankly I'm completely out of my depth here.