We have legacy applications written in asp and asp.net on IIS using form based authentication against the Database (Not AD). We are writing a new Java app sitting on glassfish and we want a single sign-on solution to authenticate users so they can move seamlessly between the two without having to sign on again.
Are there any secure solutions to this problem?
I think the best approach in the long term is to decide on a SSO technology / implementation, and then change the legacy applications to use it. I know that changing legacy apps can be painful, but provided it is practical you should do it.
UPDATE
You don't necessarily have to do a complete rewrite of your legacy apps. If you can identify an SSO tech which supports the legacy language too, you can maybe just get away with rewriting the login page and (maybe) access control and/or local account management.
Take a look at spring security (if you're not opposed to using spring for your java app). They support dozens of solutions, probably whatever you're using for your ASP app. http://static.springsource.org/spring-security/site/
Alternatively you could use apache shiro http://shiro.apache.org/ which also supports just about anything out there for security.
I'd advise looking to see if one of these supports what you are using already on your legacy app, it would probably be easier to make the java app support your existing security mechanism rather than trying to backport a new security layer into ASP.
Related
Is there a security Framework available for Java Desktop Applications? When I searched on google I saw persons talking about Spring Security, however it seems to be chiefly web-based. I have been using ordinary java code(Login forms, jdbc) to implement User Level security but I am not comfortable programming this way. Thanks for your assistance
I have decided to use Apache Shiro Security Framework. It is very easy to use and the website host good documentation. Thanks all for the help.
you can still use rolebased access and some sort of directory service for desktop applications and you could do that with spring it's not necessarily only for web access. not that i'm pushing spring specifically.
regards
It's hard to really answer you without knowing what threat model you're thinking of.
Do you doubt that the signed in user has permission to open your application?
Does the application talk to a server and get data from there?
Are you concerned with the user tampering with code?
In the first case, this seems like something that is better handled with OS level permissions.
In the second case, handle your security on the server, you can't trust the client anyway.
In the third case, good luck.
If I started a new project to execute on the Java EE platform and I wanted to be able to do user-friendly login (say pop up a modal dialog for credentials when needed, or have login option available all the time like twitter or SO), what would be the best approach and tools to implement that?
I've found it quite difficult to retrofit an existing project that uses security constraints, so I'm wondering how I can make my life easier in future!
By default, I'd be looking to use Dojo as my JavaScript framework and deploy to a Java EE appserver like WebSphere.
Best approach and tools?
Go for JSF libraries like PrimeFaces!
Check this example
IMO, this is fastest and easiest way to make a rich web application
See the second answer here: Automatic login to JSF application on revisits, after once logged in
If you're using Spring Security or Apache Shiro, both of them support
this with the proper filter. On the backend Spring Security works by
having a persistent store of remember me tokens, and Shiro I think
signs a hash value.
Here's the spring guide:
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/remember-me.html
Here's the shiro guide:
http://shiro.apache.org/java-authentication-guide.html
If you're using Java EE Security (please tell me it ain't so), you're
limited to what your container can support, unless you want to design
a customer login filter. An customer filter could sign a cookie with a
MAC code and validate it against a database. I don't believe tomcat 7
has this built in, you'd probably need to check out GlassFish (which
supports SSO, I don't think it supports remember me).
We currently have a simple portal kind of functionality built based on ASP.NET Forms-based authentication. All the existing apps that make use of this authentication mechanism are ASP.NET based (and run on the same domain). So, all works fine. We have a new requirement to get some new Java-based web applications make use of the same authentication as well. All our apps are accessible over HTTPS.
Can someone advise here please?
Thanks
We opted to use the ASP.NET Application Services for a proof of concept and the output looks promising.
Thanks all
It's hard to understand the specifics of your question, however in general I would guess that Java has the equivalent of Forms/cookie based authentication mechanism in its' web layer, you could then point that API to the same data source as the one your Forms Authentication uses today.
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
I'm currently working on implementing the public API of our web application. The application is written in Java.
This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.
What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).
We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.
The API infrastructure will be on a different sub-domain and on a different server.
The API should use Oauth to authenticate the users.
I looked into Grails, Play!Framework and Restlet to achieve my goals
Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?
Thank you all
I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.
This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.
You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.
I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.
What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).
If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.
REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.