Is it possible to use two authentications methods side by side in Tomcat 6.xxx?
Story:Right now my app runs on ports 80 and 443. In 443 connector there is clientAuth="want" parameter.
If client is coming over 80, no cert is required. But when client is coming over 443 and client has smart card in reader, the cert is automatically asked, even if the client don't wan't to log in.
For login with user-cert, i have FormFallBack authenticator, which means that if client doesn't send certificate (he has not smart card in reader) or certification fails in authenticator, authenticator directs to form, where he can login with password and username.
My english isn't very good, so here is better overview of similar system : http://wiki.apache.org/tomcat/SSLWithFORMFallback
But the process of asking user-cert is annoying for user if browser multiple times asks for cert, if user don't want use smart card for login(but he has it in reader), instead he want's to login with username and password.
So is there option for following:
I have login page where are username and password field and login button. If user presses login button, he will be logged in with username and password(directed to form authenicator).
But in the same page there is button "Login with smartcard". If he presses this button, the server asks for user-cert and gives it to authenticator.
Hope you understand the problem.
I believe you will have to write your own Tomcat authenticator that understands these requirements.
It may not actually be possible because AFAICT you are asking to be able to reconfigure the behavior of the SSL connector on a per-user basis, and you can't configure the connector for the user before the SSL negotiation has taken place.
If you keep the authenticated state with the servlet session, you can offer to log on via either a form or client-certificates by providing two distinct buttons (or links) indeed.
I'm assuming here that you can have paths like /login/form for the form and /login/cert for authentication via a client-cert.
You can trigger client-certificate authentication on demand, when visiting /login/cert using SSL/TLS renegotiation. To do this, use clientAuth="false" in the connector configuration, but put a security constraint on that path in the webapp, using <auth-method>CLIENT-CERT</auth-method>: this will trigger renegotiation when required.
For this to work, you'll need a version of the JRE that supports RFC 5746 (Oracle Java 6 r22 or later), and your clients should support it too. Modern versions of browsers/OSes should support this by now.
See the AuthenticRoast project in Google Code. It does exactly this and more.
Related
Web Servers have settings by which you request client certificates - for eg. SSLVerifyClient require in Apache, a different setting in IIS etc. If this is set, then the browser throws up a dialog asking you to chose a certificate.
Is it possible to ask for a certificate dynamically? i.e. I am really not interested in 2 way SSL - however, I want to ask the user to register his certificate with my application which will be used in a different context. So I need to let the user chose one of the certs registered in his browser and access the cert in my application. How do I do this?
Is this possible at all?
I have figured out one way to do this - I have a upload link in my application - this points to a Virtual Directory which has Client Side Authentication required property. So when the user clicks on the link - it triggers a SSL Renegotiation. The browser throws a dialog which lets the user chose from the registered certs. Once he chosen the certificate, SSL renegotiation happens and the I can access the cert in the application. The SSL renegotiation ensures that the user has the private key corresponding to the Cert.
If there any problems with this method or if there is a better way to do this, I am most certainly interested in doing it.
Also, I am currently doing this in IIS - but I think something like this should be possible in most other webservers also.
I'd like the view implementation for my login page to detect if its page has been downloaded via HTTPS. Then it could warn that login won't work unless the whole site is served via HTTPS, due to my checks on the server side and due to it being generally unwise. And it could avoid sending any password via regular HTTP.
Is there any way to do this in GWT client code without writing some Javascript?
Yes. This test should do it:
Window.Location.getProtocol().equals("https")
A probably better alternative would be to write a redirect to https rule (on the server side) as soon as your user hits your login page, this way you force your users to be https from the start of the login process, before you send to your server any username/password, hence they are guaranteed to be encrypted.
I have a simple webpage deployed to tomcat which runs certain shell scripts based on user selection. The pages are written in html and cgi/perl.
We already have a working ldap server and directory. I need to be able to add security to the web page I created so a user is asked to login using their ldap account when trying to access the home page or any off the sub pages.
How do I add ldap authentication to my web page?
Please be very specific as I am new to all of this. Step by step instructions including code would be greatly appreciated. Thank You
I did a lot of research on google, but all of the solutions are generic, and I don't know where to start.
This is a good article, but I'm not sure where do I put my connection to ldap and the binding (which of my pages)? How do I make sure the authentication will apply to the sub pages as well, or any other one created in the future?
http://www.perlmonks.org/?node_id=32196
Cheers
This is a good article, but I'm not sure where do I put my connection
to ldap and the binding (which of my pages)? How do I make sure the
authentication will apply to the sub pages as well, or any other one
created in the future?
You're now adding state to your app. You might initially think about implementing your authentication (authn) and authorization (authz) in tomcat, and not in your app.
If you decide not to implement in tomcat, and choose to implement in perl, then you've just decided to add state to your application, which means you need to add some kind of session handling. Look at CGI::Session, there are many other session handling modules on CPAN. Avoid Apache::Session. Its lock handling can cause lots of pain if transactions run long. Use a session key in a cookie. Send everything over SSL. if you don't use SSL, then crackers can intercept your session keys, and then hijack the sessions.
Once you have your session infrastructure set up, you need to create a login mechanism, usually a form with username and password. when that form is submitted, the CGI behind it does its magic crypto on the password and then does the LDAP dance:
connect to the directory server is no connection already exists.
2a. bind to the server anonymously or as an application user, search for the user by CN, bind as the user using DN and password
OR
2b. compute the DN form the username, bind with the DN and the crypto's password.
Often, step 3 is to check the user's record for some authorization indicator, it could be a yes/no access indicator, or it could be a list of roles or privileges.
If the user is successfully authenticated, and authorized, then write some authorization info into the user's session.
Each subsequent page of your app will then check to see if the user is logged in and/or has the proper authz to use that page. If unauthorized, you can either send them back to the post-login landing page, or to the login page if they aren't logged in.
Basically, you just replacing the usual "query the user table of the database" with a query to an LDAP to a directory server.
Suppose I have a form on a page at this location...
http://mydomain.com/myform.htm
And the form looks like this...
<form method="post" action="https://secure.otherdomain.com/handleform.php">
....
</form>
Assuming that there is a valid SSL cert installed on the server which receives this form submission will the contents of that form submission be encrypted?
The POST request will be transmitted over HTTPS (so encrypted if configured properly). Submitting a form from a page obtained over plain HTTP to an HTTPS page is bad practice. The initial page should also be served over HTTPS. The reason for this is that a MITM attacker could intercept the response that loads the page with the form and replace the link to point to another target.
See the first rule here (of course, not specific to login pages):
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Use_TLS_for_All_Login_Pages_and_All_Authenticated_Pages
Rule - Use TLS for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated pages must be
exclusively accessed over TLS. The initial login page, referred to as
the "login landing page", must be served over TLS. Failure to utilize
TLS for the login landing page allows an attacker to modify the login
form action, causing the user's credentials to be posted to an
arbitrary location. Failure to utilize TLS for authenticated pages
after the login enables an attacker to view the unencrypted session ID
and compromise the user's authenticated session.
Assuming a valid SSL/TLS session can be negotiated between the server and the client, then yes. This means that the client must be willing to trust whatever certificate the server presents and that the two parties can negotiate a mutually-agreeable cipher set (what algorithms to use, etc). There are plenty of configuration options you can set to alter what is allowed, but in a "normal" implementation where you don't go messing around with requiring a specific, non-normal, algorithm, requiring client-side certificate authentication, etc, everything should work just fine and you'll have a protected session...and if it fails for some reason, you'll know as your client will receive an error about what went wrong.
Note that, in general, while you can do this, and the transmission would be encrypted, you generally should not. Having an unencrypted/protected page submit to one leaves you vulnerable to a couple types of Man in the Middle attacks. You can see the OWASP article on this, and why it's bad, here.
Yes. It will be transmitted securely.
I am working on iPhone application which have login form to access application functionality same as website. now i want to add one button in iphone application that redirects user in to website in safari browser with successfully login.
After success login in to iPhone application, user want to check website in browser so i just need to add functionality that user can directly login in his account and redirect on particular page.
i have some basic idea for that we can do with encrypted username and password with url.
like http://xyz.com/login/username=abc&password=abc
but i know that its not secure way to pass username and password with url.
So please suggest me any other way if possible.
Any idea or alternative that how to implement this.
Thanks in advance.
There are a few ways to do it.
Any time you send password information over the Internet you want it to be encrypted over SSL. This will require an SSL Certificate for your web server though and it's not always possible.
You can also encrypt the username and password yourself in a way that only your web server will know how to decrypt. So the username "foo" could be turned into "oof" and the password "bar" could be turned into "rab". That way if someone intercepted your requests, they couldn't know what the username and password were without knowing how you changed them.
Why not pass the session id?
Here's what I mean: When you log in to a web site, typically you're assigned (or already have) a "session cookie" which essentially tells the server "This visitor has session ID 'XYZ'", and allows it to retrieve the server side information stored for that user (like who they are, that they authenticated, or whatever else you store in the session store.
One of the easier ways of moving to/from applications is to make sure that all logins generate a server side session, and provide a script which will overwrite the user's session cookie and redirect them to the proper page.
session_restore.php?sessionId=12345&redirect=HOME
The doubters here will argue that providing such a script is tenement to a security breach, but I would argue that all of this information is stored client side already, and can be accomplished without the server's intervention anyway. (session hijacking plugins for popular web sites exist for firefox that will grab session IDs from wireless networks - no technical skill needed)
Doing it this way just makes the process friendlier to the user, and if your site provides SSH access (which you really should be doing anyway) then the risk is very minimal.