I have developed a application which authenticates against Domain server using NTLM authentication, Different user of application are using their domain credential to log into application.
I am facing a problem that application is not using every user login credential, rather it uses first user's credential (seems It is caching authentication results), so whenever new user passes the authentication , it simply logs into application because some other user was authenticated earlier.
I'm afraid that there isn't enough there for me to make sense of.
However, if you've coded the authentication process into the application itself, I don't recommend that.
Partly because webapps with user-designed security are virtually all insecure, but in this particular case also because there is a Tomcat Realm plugin that can handle the authentication and authorization processes instead of making the webapp do it.
Customer surveys are for companies who didn't pay proper attention to begin with.
I am writing service components exposed as REST , and my service component are accessing SSRS(SQL Server Reporting Services) via webservice exposed by SSRS,
I need to authenticate myself before accessing SSRS and same authentication user is used to by SSRS to verify various credential, so for each user. If I enable any tomcat based authentication which will definitely authenticate but still , I have to authenticate user while creating connection to SSRS webservices, in other words the tomcat authentication is not fruitful for me, because second authentication is inevitable .
So I am using Java Authentication before creating SoapService object which is working for me, but It is causing issue in subsequent calls. Credential of first authentication are being used every time.
my standalone program works fine, so only difference I see is, JVM terminates in standalone program and in tomcate JVM is alive, which I suspect is caching the authentication result.
Ah yes, REST. No, that's one case where the standard container system doesn't appear to work well. In large part because the container system is intended to authenticate sessions, but the very definition of REST is that it's (allegedly) sessionless.
The javaDocs on Authenticator seem to indicate that it's intended for use on a client, not a server. And definitely not as a multi-user authenticator. For that, I think you'd have to instantiate a new authenticator for each request, not expect the Authenticator class itself to serve as a factory or provider.
Also, Authenticator seems to get involved in security negotiations. In a standard HTTP security authentication session, the server would either respond to the original request with an "authentication required" response (which would cause a browser to pop up the userid/password dialog) or, in cases of J2EE form-based security, return the login form, which is then submitted back to resume the original request which the server had shunted off to a holding area. In other words, I'm not sure that the HTTP protocol sequences are appropriate.
For NTLM requests, there is metadata that's piggybacked onto the initial request. Thus, the server needs to check that metadata before routing the request to the REST response handler. I'm thinking that the best place to do this would be in a Tomcat Valve. You might want to google around and see if there's one pre-written that you can use. If you did code the security check into the webapp itself, you'd have to basically do the same thing that the NTLM Realm module does, except do it manually. And that, incidentally is one reason why I prefer container-based security where possible. Because sooner or later a maintenance programmer will either forget to code the check or botch the job (or add logic that bypasses the check).
The javaDocs on Authenticator seem to indicate that it's intended for use on a client, not a server.
Though I am using it inside tomcat but still my complete application is client of another application , where authentication is being triggered.
And definitely not as a multi-user authenticator. For that, I think you'd have to instantiate a new authenticatorfor each request, not expect the authenticator class itself to serve as a factory or provider.
I did try to use new Instance every time by writing a new class extending the authenticator class, but did't work
Actually once a negotiation happens, it doesn't trigger any negotiation, to my surprise when I removed network cable ad tomcat was on my local machine, authentication was successful
On other environment , when I changed the authentication to kerberos, I am not facing any issue.
However I am trying to know exact cause of issues with NTLM and possible solutions for same