Could somebody advice me the best solution about JavaFX (JDK8) and security concept? Under security I mean authorization and authentication. Thank you in advance.
I might be a bit late in answering this, but you are very right Maryan. JavaFx doesn't seem to have good interoperability with any standard security mechanisms.
The only option is to use a 3PP to solve this. Examples are: Spring security, Apache Shiro etc. In order to eliminate the dependencies with a particular 3PP, I encourage you to wrap the 3PP implementation.
Unfortunately, This is just the beginning of a long list of issues(that are yet to come up) for you, even after you implement the security measure, you will still have to come up with ways of storing and managing security tokens(similar to browser cookies) so that your JavaFx client doesn't need to authenticate with server for every call.
If this is only the beginning of your project, I suggest you really think about whether to use JavaFx or go with web based UI.
Related
I need of an information. I'm new in develop web application. I should use php and javascritp but it 's possible, in the future, I could use other languase like Java. During these days I'm following a course on the best practice to write secure code.
Is there any guide/book or any other valid resource, where I can find an explanation about the differrent kind of attaks on a web application and the ways to solve them?
Thanks
Luca
If you're looking for resources to secure your applications on the internet, the first thing to try is OWASP, or Open Web Application Security Project. Here are some useful articles about what you're looking for:
OWASP: Web Security Testing Guide
OWASP: Cheatsheets
OWASP: General Information
All of the resources above will show you the recommended ways to secure your web application against threats. I think it's more than enough for the first step in the security world.
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
I am looking at developing a web application that will need to work with personal health information. I am looking at the possibility to using KendoUI for the interface. However, can it be secured to not allow anyone to cross script, bypass or spoof the javascript code since it is on the client side? Or is it better to stay with standard server side controls that require a postback?
Your question lacks detail, but if you are talking about the Kendo DataSource sending data to the server, it is basically a wrapper around jQuery.ajax, so just about anything you can do with jQuery.ajax() you can do with Kendo DataSource.
The truth is the less complicated the security the less reliable it is. Just making a simple call to a datasource in kendo will not be very secure but heading the other way with something like o2auth will be a lot more secure but way harder to implement.I would recommend reading this before you continue down this path. You will have to consider how much effort you are willing to go through to protect your app/website from an encroachment. if this is for a commercial environment you will have to take as much precaution as possible to prevent a security breach.
For 90% of every security-related Grails tutorial, they tell you to store your User objects in a session-scoped variable. That's all nice and easy, but I wonder if it's too good to be true, especially with plugins like Spring Security that offer many times more features.
For the simple, "I am a user and therefore I am entitled to view/edit my own domain objects" applications that I develop, I store my User objects in a session. However, this got me thinking how Grails supports J2EE security and sessions in its own implementation (it does use a temporary session ID in the cookie, right?). Furthermore how vulnerable is it to attacks like cookie injection and cross-site/stray JS?
I don't want to actually invest the time in learning, integrating, and maintaining a plugin for an app that might not need it, so my question is, is Grails's session implementation secure enough for simple applications, and is there a very good reason I should use a security plugin even for these trivial tasks?
On a side-note, if anyone can point me to a good OpenID/Facebook login implementation, that would be terrific.
Regarding security concerns I would always suggest to prefer proven and widely adopted solutions over your own rolled security implementation. Spring Security was founded in 2003 under the name Acegi and brings you more than eight years of experience and development for your security concerns.
As you already pointed to the Grails Spring Security plugin you should have a look at the OpenID plugin Spring Security OpenID which extends the Spring Security Core and brings you the OpenID support.
reason I should use a security plugin even for these trivial tasks?
... on a basic level it's also trivial to use the plugin so what's there to lose? Screencast to get you started
I'm working on a web site and I plan to use strictly OAuth in for user authentication. I've never implemented session management/user authentication before; and so - naturally - I'm reading up on a lot of how tos to get this done.
The problem I'm running into is that a lot of examples out there for doing things like setting up your realm, authenticator, etc etc seem to rely on the user/password paradigm for authentication. The whole point of going for OAuth is to avoid this in the first place!
That being said; I'm actually not looking for examples of full OAuth implementations right now. I understand that I need to understand that for myself. BUT with a future OAuth implementation in mind; how should I structure my user authentication/session management FOR THE TIME BEING in a way that will allow me to move forward on developing the functionality on my site that I really care about? I suppose I could throw some stuff together for that; but I'm just afraid that down the road I will be shoe horning an OAuth implementation as opposed to do something now which allows me to lay down the basic framework for it and then move on to other things.
So; does anyone know of a good example of laying the groundwork for OAuth on Tomcat 7? For example, which authentication mechanism (Basic, digest, etc) I should use or how I should represent user credentials in my database?
I know that this is kind of a vague question; so I'm not expecting someone to come out and tell me all of the answers I need to know. I'm just looking to get pointed in the right direction here.
Perhaps Spring Security would be useful? Your webapp could leverage Spring Security and use whatever login mechanism you need (i.e., you could do the default form-based authentication or Basic Auth for now, and replace the login/auth piece with an OAuth implementation when you're ready), but still have Spring Security manage authorization to particular resources in your webapp.
Someone has also built OAuth for Spring Security, so it may be a useful addition to your web app all around.