Oh, forgot to mention.
Platform is as such:
JVM: J2SE 1.4.0_01
App Server: JBoss 3.0.0 + Tomcat 4.0.3 (integrated bundle)
I *think* the authenticated Subject gets stored in a Jetty/Tomcat cache, & the principal is stored in the user's session. The auth mechanism then uses this principal to check against the cache when it's security check time. It's obviously not so portable to start stuffing your subject into this cache manually.
Luckily, the mechanism doesn't enforce POST only submission to j_security_check - so you can simply store the user/pass in the session & redirect to a protected resource. On your login page, which the interceptor will call, simply check for eg j_autologin_uname/pass and if present, remove them & do a swift redirect to j_security_check passing the values along for the ride.
Use a sessionListener to set up your user after declarative login. eg. listen for org.mortbay.jetty.Auth to change - it's where the principal is stored in jetty. I just configure a context variable in web.xml for this, so it's fairly portable.
CAn you explain this with any examples? I am using Apache/tomcat but I can relate to this is I knew nore of wht you are refering to. If you can give examples of this listener you are talking about andthe process of the redirect you used better.