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.
Related
I am currently working on a website built with Backbone.js. The site has a RESTful API built in Symfony with FOSRestBundle. Developing was going fine, until I stumbled in to some user-related tickets.
From what I understand, the best way to handle this type of problem is with a token based system, where the user gets an access token after an approved login. I will describe my current perception of the workflow, and ask questions along the way. More importantly, please correct me if I have misunderstood.
First, the user the accesses the login form, then the user types in credentials, and an AJAX request is send to the server. From what I understand this should all be handled with SSL, but with Backbonejs, you can't simply say that the login page should be accessed with HTTPS, as Backbone is a one-page framework. So will this force me to use HTTPS through out the application?
In the next step, the REST server validates the credentials, and they are approved, then the REST server sends an access token to the client. Is this token saved (on the client-side) in local storage or a cookie?
Also is the login stored at the server, so that the REST server can log the user out after a certain amount of time?
Now, the client sends this access token along with other request, so that the server can identify the client, and approve the request or not. So the access token is also stored on the REST server?
Lastly is this what the smart people call "oauth", or does it relate to it?
Thank you.
Let's take your questions one at a time.
From what I understand this should all be handled with SSL, but with Backbonejs, you can't
simply say that the login page should be accessed with HTTPS, as Backbone is a one-page
framework. So will this force me to use HTTPS through out the application?
Ok, there's a lot to unpack there. Let's start with SSL/HTTPS. HTTPS is a protocol; in other words it defines how you send packets to/from the server. It has nothing whatsoever to do with whether your application is single or multi-page; either type of site can use either HTTP or HTTPS.
Now, that being said, sending login info (or anything else containing passwords) over HTTP is a very bad idea, because it makes it very easy for "bad people" to steal your users' passwords. Thus, whether you're doing a single-page or a multi-page app, you should always use HTTPS when you are sending login info. Since it's a pain to have to support both HTTP and HTTPS, and since other, non-login data can be sensitive too, many people choose to just do all of their requests through HTTPS (but you don't have to).
So, to answer your actual question, Backbone isn't forcing you to use HTTPS for your login at all; protecting your users' passwords is forcing you.
In the next step, the REST server validates the credentials, and they are approved, then
the REST server sends an access token to the client. Is this token saved (on the
client-side) in local storage or a cookie?
While any given framework might do it differently, the vast majority use cookies to save the token locally. For a variety of reasons, they're the best tool for that sort of thing.
Also is the login stored at the server, so that the REST server can log the user out
after a certain amount of time?
You've got the basic right idea, but the server doesn't exactly store the login ... it's more like the server logs the user in and creates a "session". It gives that session an ID, and then whenever the user makes a new request that session ID comes with the request (because that's how cookies work). The server is then able to say "oh this is Bob's session" and serve the appropriate content for Bob.
Now, the client sends this access token along with other request, so that the server can
identify the client, and approve the request or not. So the access token is also stored
on the REST server?
If you're running two separate servers they're not going to magically communicate; you have to make them talk to each other. For this reason your life will be easier if you can just have one (probably REST-ful) server for your whole app. If you can't, then your REST server is going to have to ask your other server "hey tell me about session SESSION ID" every time it gets a request.
Lastly is this what the smart people call "oauth", or does it relate to it?
Kind of, sort of, not really. OAuth is an authorization standard, so it's sort of tangentially related, but unless your login system involves a whole separate server you have no reason to use it. You could use OAuth to solve your "two servers, one REST-ful one not" problem, but that would probably be overkill (and regardless it's outside the scope of what I can explain in this one Stack Overflow post).
Hope that helps.
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.
Is it possible to do optional kerberos authentication?
What I want is: if the client (browser) is not on the domain it is redirected to a username/password web login. Otherwise it will do SPNEGO do Kerberos authentication.
If I just send the WWW-Authenticate: Negotiate header to a non domain browser it just does nothing further.
Is there some option to tell the browser to try something different if it doesn't know how to authenticate? Or do I have to determine if user is part of the domain before sending the "WWW-Authenticate" header?
I haven't found anynone who has solved this publicly and in a standard way. Yes, as mentioned, one could fall back to Basic but that doesn't work for authentication schemes which involve requesting a username and password from a CGI form where, as far as the browser sees things, you're falling back to no authentication if Negotiate fails. Maybe that is suggestive that the authentication scheme is broken? I don't know.
I'll tell you what I know, first. Our site is, effectively, Cosign-protected, so we have a similar problem to you: only specially-configured machines respond to the WWW-Authenticate header, so by default we must send all users to our Cosign login page. The trick is that the Cosign server also allows authenticated GSSAPI/Kerberos hosts to complete the authentication process without entering login details, but only on certain browsers, by means of a workaround.
This workaround consists simply of a block of JavaScript within the login page which attempts a HEAD of an SPNEGO-protected resource; if successful, the script redirects the browser to an SPNEGO-protected version of the same page, which grants appropriate Cosign cookies and completes the process without password entry. If the browser lacks any one of JavaScript, Kerberos support or adequate credentials, then the user will see the cosign login page as usual.
So, the above alone might count as an answer to your question; personally though I don't think this goes far enough and what follows is more of a discussion...
The above seems unsatisfactory as it insists that any connecting user agent supports either JavaScript (unlikely to be the case for text-based browsers and HTTP client libraries) or knowledge of the arbitrary path to which we redirect Kerberos-capable users (useless to anything which has not been hard-coded for our site). I've come to the conclusion that there might be a better workaround, or if not, a gap where a standard should be. The best practical suggestion I have is this:
A normal part of the SPNEGO process is that the client attempt to retrieve a page whose initial response is an HTTP 401 but with the header WWW-Authenticate: Negotiate. This is the cue for a GSSAPI/Kerberised client to respond appropriately; a "regular" client will simply display the error page. Perhaps the solution is simply to modify the Cosign server to deliver the human-friendly login page as part of this error response?
It might be technically difficult with off-the-shelf Apache and modules, and might go against various standards (or at least principles). I'm no expert on the systems involved, so can only speculate unless (or until) I get a chance to try it out...
Send additionally WWW-Authenticate: Basic for username/password challenge.
It depends on the application server, for example in JBoss you can set <auth-method>SPNEGO,FORM</auth-method> in web.xml and it should fall back to a login form "in cases where Kerberos/SPNEGO tokens are not present":
See https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html/how_to_set_up_sso_with_kerberos/additional_features
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 have an MVC3 web app that does auth to a customization of StarterSTS. I require the realm to be known and the authentication to require SSL.
It works, great.
The problem is when the user lands back onto my website they are browsing with https. This isn't really the experience I want. My site is not a bank or anything of the like. I feel the authentication conversation should be secure (I think) and the token encrypted (I'm sure). But if I manually change the url from https to http on my replying party web app after authenticating it says I'm not authorized.
1) why?
2) Is it possible to fall back to http ? or ... Should I not require https for the authentication, but leave the token encrypted?
Well - what's wrong with SSL?`
The token should be always transmitted using SSL - even when it is encrypted, it could be replayed etc.
Also the resulting session token needs to be protected. So I would go for SSL (easy to setup) and not worry about possible attacks that result from not using it (hard to implement).
That all said - you can turn off the SSL requirement on the wsFederation (requireHttps="false") and nested cookieHandler (requireSsl="false") configuration element.