What you want to do is feasible, but you must play by the rules, which don't include Java. Here is a little history, why your current attempt does not work, and how you can fix it.
It won't be easy.
A little history
First, there was a fundamental change in the way Windows acquire credentials starting with Windows Vista. That logon.exe utility you mentioned uses the old architecture. Back then, you could do pretty much anything you wanted, as anything fiddling with the logon architecture ran as a DLL in Winlogon's process. You might have already found a few custom GINA, like this one I wrote. They are ignored in recent versions of Windows.
Nowadays, Winlogon asks LogonUI to acquire credentials. LogonUI is a process that will hosts Credential Providers. A credential provider is represented by a "tile" on the logon screen. There is a few COM interfaces to implement so that LogonUI asks you for credentials.
The important things to remember are:
- You must implement a COM interface to interact with the logon process
- You get to decide what UI you present, or no UI at all
Implementing a COM interface pretty much excludes Java.
The problem you are facing right now
Logging a user in means getting a security token for him. But logging a user interactively means that you must tell Winlogon to open the door. The only process Winlogon will listen to for that is LogonUI.
In other words, even if you had code that can create a security token, you won't be able to use it to unlock the desktop.
The Windows API to create a security token is LogonUser, by the way.
How you can fix it
You must write a Credential Provider. I never heard of way to do it in Java, this is too platform specific and non-portable. All of the documentation if for C++, but I heard that it can be done in .Net. A good starting place is the Credential Providers samples in the Platform SDK.
When your Credential Provider initialzes, you will spawn a thread that waits for some event, like a Bluetooth device showing up. Running a service will work, as long as you can communicate back to your CP.
You also need to save a pointer to LogonUI's event mechanism in your implementation of ICredentialProvider::Advise.
When your hardware detection thread detects your bluetooth device, have it call ICredentialProviderEvents::CredentialsChanged. It will tell LogonUI to go through all of the Credential Providers again. When called, you must answer that you are the default auto-logon provider.
Phew! And we have not logged on, yet!
The last step is to retreive the password you save for that user, and send it to LogonUI in when ICredentialProviderCredential::GetSerialization is called.
LogonUI will take it from there. It will instruct Winlogon to call an authentication package for you and log the user in.
This SO answer says the same thing, but it is a little terse. This MSDM article is old be more complete than my answer.
+Encrypting and managing the user's password is left as an exercice ;) but you might want to take a look at the Data Protection API.