Authenticate user without Login page
Shishir Mittal
Greenhorn
Posts: 1
posted 5 years ago
Hello
We have a web application in which we need to figure out who is currently logged in based on their Windows and/or Linux user credentials. We've tried using getRemoteUser() function, but this returns NULL. After some research on the internet, we figured that getRemoteUser() will only work if we have enable user authentication in Tomcat. However, this is not desirable.
Since, all users are on secure network within the organization, we were hoping to get Windows and/or Linux user credential from the system and return the same to server and use it to authenticate the user. We want to avoid using Login page to authenticate any user.
Is there a way in JSP (using Stripes framework) based web application running on Tomcat to read user credentials and send it to server?
Any help would be appreciated.
We have a web application in which we need to figure out who is currently logged in based on their Windows and/or Linux user credentials. We've tried using getRemoteUser() function, but this returns NULL. After some research on the internet, we figured that getRemoteUser() will only work if we have enable user authentication in Tomcat. However, this is not desirable.
Since, all users are on secure network within the organization, we were hoping to get Windows and/or Linux user credential from the system and return the same to server and use it to authenticate the user. We want to avoid using Login page to authenticate any user.
Is there a way in JSP (using Stripes framework) based web application running on Tomcat to read user credentials and send it to server?
Any help would be appreciated.
posted 5 years ago
Shishir, welcome to JavaRanch!
You can't (and should not be able to) access information below the layer in which the web browser is running. In particular, getRemoteUser() has nothing to do with the user credentials of the operating system - it simply returns the login of the authentication that the browser might have made. There are some JavaScript, and ActiveX (Windows) workarounds though, but all these workarounds are inherently unstable and not inter-operable.
Moving to the Servlets forum.
You can't (and should not be able to) access information below the layer in which the web browser is running. In particular, getRemoteUser() has nothing to do with the user credentials of the operating system - it simply returns the login of the authentication that the browser might have made. There are some JavaScript, and ActiveX (Windows) workarounds though, but all these workarounds are inherently unstable and not inter-operable.
Moving to the Servlets forum.
Author of ExamLab - a free SCJP / OCPJP exam simulator
What would SCJP exam questions look like? -- OCPJP Online Training -- Home -- Twitter -- How to Ask a Question
posted 5 years ago
You can do all this with authentication, as long as you set it up correctly. You can setup Tomcat to authenticate against an LDAP server. The browser then sends (after some configuration in Firefox) the current user's credentials to Tomcat which then successfully authenticates the user. For a Windows Active Directory system you can use several solutions like JCIFS (outdated but free) or Jespa (non-free). For other LDAP systems you'd need to search around a bit first.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
posted 5 years ago
Welcome to the JavaRanch, Shishir!
Web application user authentication is generally totally unrelated to LAN user authentication. Were it not so, Amazon.com would have had to set up LAN accounts for every customer they'd ever had.
And just because you're authenticated on YOUR LAN doesn't mean that that should automatically give you rights on MY LAN! 
Of course, for webapps that are partially or wholly internal use, having a separate login and user identity for the LAN and the webapps can be a real pain.
Fortunately, there are ways of dealing with that. For webapps that don't get clever and try and invent their own security systems - meaning apps that use the standard J2EE security functions, security is a plug-in feature that wraps around the webapp. That, is, it's container-managed security. Because different shops/apps have different security needs, the actually authentication and authorization functions are handled by what's known as a Realm.. Most webapp servers - Tomcat for example - come with a number of standard Realm modules and often support third-party Realms as well.
LAN authentication is a variant of Single-Signon authentication. Straight SSO only requires the user to login ones to authenticate to all apps in its Realm. LAN authentication takes that one step further, but using the user's LAN login as the basis. Because this form of authentication needs to know information about the LAN client that web browsers aren't normally expected to know, you have to be using a browser that is capable of providing that information. I don't know if it's still true or not, but at one time, IE users also had to have their browser security settings changed, as well - a rare case (at the time) where Microsoft ran secure by default.
A variation of this security architecture is sometimes used. Some shops find it convenient for both internal and external users to be supported, where the internal users use their LAN security rights, but external users have to login using credentials from a non-LAN source such as an LDAP server or database. That is actually only slightly more complicated.
The main things that are required are to install and configure a suitable Ream module and to ensure that any appropriate client settings are in the right configuration. After that it's all automatic.
Web application user authentication is generally totally unrelated to LAN user authentication. Were it not so, Amazon.com would have had to set up LAN accounts for every customer they'd ever had.
And just because you're authenticated on YOUR LAN doesn't mean that that should automatically give you rights on MY LAN!
Of course, for webapps that are partially or wholly internal use, having a separate login and user identity for the LAN and the webapps can be a real pain.
Fortunately, there are ways of dealing with that. For webapps that don't get clever and try and invent their own security systems - meaning apps that use the standard J2EE security functions, security is a plug-in feature that wraps around the webapp. That, is, it's container-managed security. Because different shops/apps have different security needs, the actually authentication and authorization functions are handled by what's known as a Realm.. Most webapp servers - Tomcat for example - come with a number of standard Realm modules and often support third-party Realms as well.
LAN authentication is a variant of Single-Signon authentication. Straight SSO only requires the user to login ones to authenticate to all apps in its Realm. LAN authentication takes that one step further, but using the user's LAN login as the basis. Because this form of authentication needs to know information about the LAN client that web browsers aren't normally expected to know, you have to be using a browser that is capable of providing that information. I don't know if it's still true or not, but at one time, IE users also had to have their browser security settings changed, as well - a rare case (at the time) where Microsoft ran secure by default.
A variation of this security architecture is sometimes used. Some shops find it convenient for both internal and external users to be supported, where the internal users use their LAN security rights, but external users have to login using credentials from a non-LAN source such as an LDAP server or database. That is actually only slightly more complicated.
The main things that are required are to install and configure a suitable Ream module and to ensure that any appropriate client settings are in the right configuration. After that it's all automatic.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
There are two sides to your request: first, the Tomcat server needs some way to authenticate you against the domain; second, you need some way to get your browser to send those credentials.
The first part can be solved using an LDAP Realm. You'll need to play with it, and determine if just anyone in your LDAP system can log in, or if they need to be a member of a particular group to gain access (most likely, they'll need to be a member of a group).
The second part requires configuration on the desktop. By default, your browser doesn't send this kind of information - and that's a good thing! You really don't want your browser to send your authentication credentials to every site you visit, after all.
The first part can be solved using an LDAP Realm. You'll need to play with it, and determine if just anyone in your LDAP system can log in, or if they need to be a member of a particular group to gain access (most likely, they'll need to be a member of a group).
The second part requires configuration on the desktop. By default, your browser doesn't send this kind of information - and that's a good thing! You really don't want your browser to send your authentication credentials to every site you visit, after all.
OCPJP
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower
Scott Paffrath
Greenhorn
Posts: 4
posted 5 years ago
An alternative to setting up a realm is to use the JCIFS filter at http://jcifs.samba.org/
This will use the SPNEGO protocol to get a network token from your browser. The server (i.e. filter) will use a password/id to check the token against a domain controller. Then getRemoteUser() will return the user's network principal. It is less standard and does not provide authorization but if you are just trying to authenticate it may be worth a look.
This will use the SPNEGO protocol to get a network token from your browser. The server (i.e. filter) will use a password/id to check the token against a domain controller. Then getRemoteUser() will return the user's network principal. It is less standard and does not provide authorization but if you are just trying to authenticate it may be worth a look.
