I have implemented a simple java web application with tomcat realm authentication(Custom FORM authentication). Now, I'm trying to add a second authentication page for the user(two-factor authentication, I'm using Google authenticator). As far as I have referred the Tomcat documentation, we can specify only one login-config.
I tried adding a filter and also tried managing whether the user has finished the Two-Factor authentication manually with session and tokens.
Is there a way to add the second authentication in the web.xml or the server.xml. So, tomcat should handle whether the user has finished both the authentication.
Thanks in advance.
Tomcat only starts one login process. That process may decide to ask the user for more than one credential but tomcat is not aware of it.
So, you should create a filter and/or login servlet that handles authentication for the tomcat container. That filter/servlet (combination) must prompt for all desired credentials.
If you do not use a framework for your application that already has an authentication layer, you are essentially writing your own 2FA implementation.
I need to create an application that fetches User from Ldap and then, generates a token for him to access Restful interface.
First, I am using LdapToolsBundle and I could login using Ldap and login form easily.
Then, I am studying FosOauthServerBundle and oauth2-server-bundle and trying to figure out which one is better for my application. I've installed FosOauthServerBundle correctly but didn't find a way to integrate with LdapToolsBundle.
I studied the possibility of using Fr3dLdapBundle and if anyone has the solution using this bundle, I would be open up.
The problem:
I don't need to persist User Entity. But, if it is required, I don't want to persist it's password. I need always the password being checked from Ldap on every token authentication.
Could anyone help me? I would be greatful.
I've trying to find the answer but after reading a bunch of documentation I think it's not possible, but I would be a nice feature. The problem is I want anyone to access the cached repositories but I don't want them to access the web user interface.
The only way I have figured out is tweaking the nginx configuration to allow access only to certain endpoints like raw repository view. Anyway it has some problems which I've not totally resolved.
You could set up a SAML SSO redirect that forces a user to login, and if they fail they are not redirected back to the Artifactory instance. That's the only way I know of that won't let users even look at the front page of Artifactory.
They would get caught on step 3 after an automatic redirect: SAML SSO Login Process
The obvious downside with this is that you need to have a SAML SSO setup in the first place.
I am working on an API in symfony where users authenticate using a json web token. There is a bundle to provide this here: https://github.com/lexik/LexikJWTAuthenticationBundle.
There is documentation on the project page on how to set everything up. This bundle relies on the standard "form_login" configuration that is backed by the class defined in vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Security/Factory/FormLoginFactory.php.
The bundle provides success and failure listeners for authentication that short circuits the request and returns a JsonResponse with the token or an error with the appropriate response code.
Using the sample configuration on the project page, everything is working as described. The problem is that these predefined config factories such as "form_login" set cookies and many other behaviours that is not required in a stateless api.
The security component defines a config option "stateless" that is defined in the symfony book on security.
However the documentation above clearly states "If you use a form login, Symfony2 will create a cookie even if you set stateless to true."
The "form_login" has many options for redirecting or forwarding to the login page if the user is unauthenticated that isn't required for an api.
Also a lot of other functionality you may want to use, such as the SwitchUserListener is very much ingrained in the traditional development model where the server just returns html.
I'm looking to create a lightweight way to plug into symfony security using this bundle and disabling the other unneeded checks.
With JWT, no login is actually required, we need an unauthenticated route that we send a username and password to (over SSL) using the authorization header that returns the token. For the other protected routes we simply provide this token. This part is already provided by the bundle, I just need a stripped down way to get the initial token without invoking unneeded symfony code.
I found this example http://miguel.ibero.me/en/post/2012-04-04/symfony-rest-api.html which implements the code to get a token in a simple controller, bypassing the firewall.
I am looking for a better way to implement this using the firewall. I suspect I will have to create my own security factory such as "form_login".
I could use the http basic auth method to get the token, but I do not want symfony to present the username/password window. I would like the authenticator to check for the authorized header and simply return a message and response code whether it is successful or not.
Any suggestions appreciated.
I created my own bundle to deal with this: https://github.com/gfreeau/GfreeauGetJWTBundle
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx