I have a web app running with Grails looking after the view and controller and calling into a spring-mvc backend via the service layer (Grails app using services from spring-mvc backend). Now I need to implement Spring Security (SS) for the app.
Its at this point I'm not sure how to marry both. The backend already has a fully functioning spring security implementation but to get the Grails app to work I needed to exclude all transient spring security dependencies coming from the spring-mvc app and go with a purely Grails solution (maybe this was the wrong decision?). The backend already has User and Role objects complete with a user_roles table modelled via a joinTable annotation in the User domain.
Questions:
Am I on the right track? Ignore everything from java backend in terms of SS bar using its data objects and go with Grails impl with SS plugin? I've seen posts saying I don't even need to use the Grails plugin but they're quite old now and I'm not sure how I'd annotate my controllers and services.
If Grails is the way, I'm not sure what I need from by backend and what I need to reimplement/extend in Grails.
I have an SS extended User and UserDetailsService in the backend app but cannot use them as I've completely excluded all the SS jars that they depend on so I presume I have to roll my own?
So I implement a UserDetails object, a custom UserDetailsService (should this implement the GrailsUserService?) and expose the latter as a bean and everything should work? Wishful thinking maybe.
Any guidance, even at a high level would be much appreciated as I'm struggling to determine my approach at this point, never mind implementation.
I have managed to implement what I need to get this working. I have gone with the purely Grails approach and so have my own implementation of userDetails, an instance of which is returned by my custom userDetailsService.
One thing to look out for, if getting a proof of concept working, is to make sure that you are reading back your password in the format you are storing it in. Spring Sec will hash your password to compare against what is in your database and so you will not successfully load a user if your storing your password as plain text. One way around this is to use the following config in resources.groovy.
passwordEncoder(PlaintextPasswordEncoder)
But of course I would not advocate this as being the long term solution from a security point of view.
Related
I have been working on a Spring-mvc webapp that takes some form data and emails this accross to the administrator.
I wish to expand this webapp into a CRUD application. I have lined up some hibernate lessons and just need to do some work on my SQL skills before I start working on this.
What I need help with is the things to consider when expanding. The amount of work that will go into this means I cannot afford many mistakes when working on the foundations of this project.
The main component will be an admin panel that can work with submitted forms.
+After this the system may be further developed by adding a user database where after each form completion a user would be created.
So really the main points of my question are:
Do I just go ahead and start designing the DB and learning Hibernate?
Do I need to consider anything NOW if I wish to have user
authentication down the line?
Am I considering the most appropriate technologies? (Hibernate, mysql + Spring Security I presume for auth?)
Firstly you should learn how to design a database. Making huge changes on database after creating the application can lead serious problems.
You can set up spring security later. Just take look at here.
You can have an idea of hibernate implementation from here: a web application CRUD example shows how to integrate Spring MVC and Hibernate frameworks. Technology choice is appropriate (Hibernate, mysql + Spring)
Here's my situation: I'm running a JBoss 7 in Domain Mode with several nodes. One node is in charge of my Liferay 6.2 another one runs several other web applications. Now I'd like to implement some kine of Single Sign On routine. So to use my web applications you have to go through liferay first. Authenticate agains liferay, then go one to one of the web applications.
So the question is whether there is a way to expose some of liferays methods to access the user store and check if the user, who's accessing a web application is the same as logged in on liferay. Developing some sort of bridge is fine with me. I'm thinking of a portlet which does all the interaction with liferay and exposes some methods like readUser(). Maybe I can do a jndi lookup for this portlet or a component embedded in this portlet to call readUser() from my other web applications. I think this sounds a bit like EJB stuff.
Using Liferays API, Services and LocalServices to read user information etc. shouldn't be that difficult (already played a little with that). I just don't know how to establish a communication between a web application and liferay.
If it's not working this way, I would settle for something else, maybe a webservice or an other way that makes sense but I'd like to try the EJB/JNDI approach first (except this makes completely no sense). Maybe someone can point me in the right direction.
Turning my applications into portlets is not really an option because these applicaions are quite large and already exsist for quite some time. So I'd like to leave them mostly unchanged - outside of auth stuff.
Thanks and regards
Sebastian
You can use a service builder and you expose your service as remote.
Several Options:
Just access Liferay's API methods from your applications. You can access the JSON API at http://www.example.com/api/jsonws.
There's also a SOAP interface (http://www.example.com/api/axis), that's typically available only from localhost (you can configure otherwise in portal-ext.properties)
You can encapsulate calls to those services by creating your own services. Use the tool of your choice or Liferay's servicebuilder. You can create empty entities and just refer to Liferay's own entities. Servicebuilder will generate JSON or SOAP WS if you let it. (what Slimen Belhajali mentioned)
As you specifically talk about the check for user identity, you might even want to think of a completely different solution and just look at single-sign-on (SSO) solutions. This way you'd sign in only once (to the SSO server) and automatically (implicitly) to your webapp as well as to Liferay. This works best if both access the same userstore, e.g. on LDAP.
Is there any java cms for websites which uses spring hibernate annotation , which can make building sites easy.
Like user registration from with fields , login with spring security and some basic functioanlity.
Actually i am not sure what product i want but i will tell you the bsic requirement.
I am looking for something where i can select e.g registration form fields , login with spring security , user can edit those fields as weel .
forgot password thing , confirm email address and a model all java spring files are created automatically and from there i can add my new features.
Because these things are basic in every web application and there has to be easy method to generate those things
The Magnolia CRM (Magnolia Community wiki) has a module called Blossom that provides Spring integration for Magnolia. (That works for Spring 3 too)
Magnolia store its Content in Java Content Repository and not in a Data Base. That works very well for the cms content, because Mangolia provides a good Api for accessing it.
If you have your own business domain model and want to store it in a Data Base, you can add your JPA / Hibernate functionality like you do in "normal" Spring applications. (or like Sean Patrick Floyd suggested: invoke an other layer/server via for example Web Service).
I have running such a System (Magnolia, Blossom, Magnolis JCR, Spring 3, Hibernate) with a small domain model stored "outside" of Magnolia in a seperate Database, and it worked very well. (But at the moment I am thinking of integrate the Domain Database in the JCR, not because of technical problems, but to reduce the amount used technologies/systems.)
Anyway: Magnolia, Blossom, Magnolis JCR, Spring 3, Hibernate is worth to have a look at.
I don't think there should be one. Persistence Layer and Web Layer are two separate concerns, and it would be smelly to tie one to the other. The standard way to connect those two is through a service layer, and that is usually where the application's most important logic is. A CMS could simply not provide an abstraction that makes a service layer unnecessary without seriously restricting your application.
That said: Spring Roo goes in the right direction, it automatically creates Web Controllers from your entity classes. I'd say that's probably the best you can hope for.
Typically in any web application, the major security concern is securing the resources from the malicious users who are trying to access un-authorized resources. They can change a value in the request parameter and try to access something that doesn't belong to that particular user.
For Example:
http://blah.com/id=foo
a user can change this to http://blah.com/id=bar and try to access the bar resource to access it.
With restful services this may lead to greater security concerns as the restful URL's are rather self explanatory.
eg:
http://hotels.com/hotels/1
a user can easily guess and change the id to 2 to see the details of it..
One design is to check at every request manually to see the access rights for the resources and deny it if needed.
but this is a cumbersome and not maintainable.
So the question is "Is there any tool/framework that can help achieve this in a easy manner? I know spring security supports static rules not dynamic.
Over the last couple of years, the de-factory standard for this has become Spring Security. This sits in frotn of any old java webapp (not just Spring webapps) and provides an interception authentication and authorization layer of your choice.
It's very powerful, although also rather complicated (over-complicated, IMO).
I would highly recommend looking into Seam Security. It can even be tied into a rules system.
edit: I believe you would need the Seam Core package for this to work. However, I have never tried using it without Seam, so I can't be positive about its dependencies.
What if you don't want to start a separate project for grails but instead sneak it into an existing webapp?
I have to build an admin interface/crud for some new entities and thought it would be a perfect way to learn grails.
I'm trying to make one application with a Grails app and a Spring app.
I've tried to sneak the Grails App into the Spring one, but this is "impossible". It's easier to sneak the Spring app into the Grails app. Grails knows what Spring is, but Spring has no idea of what Grails is.
In this article you can find useful information about how to use your hibernate mapping files or annotations in Grails, so you don't have to remap everything. Also you can use all your java clases (put them into src/java). You can put the beans defined in the ApplicationContext.xml in conf/spring/resources.xml. You can leave them in ApplicationContext, but I've had some problems.
I don't have ended the job (almost) and it looks good.
It would be hard to "sneak it in" unless the existing app has the correct dir structure that maps exactly to how grails likes it - after all, convention over config is where the power of grails comes from.
You can try doing the admin interface as a "seperate" app to the original/existing spring app, and map the existing database to the grails domain objects. though i m not sure how you would run them side by side easily without more information on the existing app. It is possible definitely though.
I agree that building your admin interface is a good exercise to learn Grails, and also agree with the previous answer that Grails is difficult if not impossible to integrate with an existing Spring application. You could probably get it done, but the headache would not be worth it.
Grails is built on top of Hibernate for its ORM, so if you're already using Hibernate with this Spring app you can work this to your advantage. It's not too difficult to configure a Grails app to use pre-existing Hibernate models, and this is explained well in Grails documentation.
So, I'd recommend building up your admin console as an independent Grails app but make use of the Hibernate models you already have, if in fact you've used Hibernate.