So, I have an web-based application that is using the Wicket 1.4 framework, and it uses Spring beans, the Java Persistence API (JPA), and the OpenSessionInView pattern. I'm hoping to find a security model that is declarative, but doesn't require gobs of XML configuration -- I'd prefer annotations.
Here are the options so far:
Spring Security (guide) - looks complete, but every guide I find that combines it with Wicket still calls it Acegi Security, which makes me think it must be old.
Wicket-Auth-Roles (guide 1 and guide 2) - Most guides recommend mixing this with Spring Security, and I love the declarative style of #Authorize("ROLE1","ROLE2",etc). I'm concerned about having to extend AuthenticatedWebApplication, since I'm already extending org.apache.wicket.protocol.http.WebApplication, and Spring is already proxying that behind org.apache.wicket.spring.SpringWebApplicationFactory.
SWARM / WASP (guide) - This looks the newest (though the main contributor passed away years ago), but I hate all of the JAAS-styled text files that declare permissions for principals. I also don't like the idea of making an Action class for every single thing a user might want to do. Secure models also aren't immediately obvious to me. Plus, there isn't an Authn example.
Additionally, it looks like lots of folks recommend mixing the first and second options. I can't tell what the best practice is at all, though.
I don't know if you saw this blog post so I'm adding it here as reference and I'll just quote the end:
Update 2009/03/12: those interested in securing Wicket
applications should also be aware that
there is an alternative to
Wicket-Security, called
wicket-auth-roles. This thread
will give you a good overview of the
status of the two frameworks.
Integrating wicket-auth-roles with
Spring Security is covered here.
One compelling feature of
wicket-auth-roles is the ability to
configure authorizations with Java
annotations. I find it somehow more
elegant than a centralized
configuration file. There is an
example here.
Based on the information above and the one your provided, and because I prefer annotations too, I'd go for Wicket-Auth-Roles with Spring Security (i.e. guide 2). Extending AuthenticatedWebApplication shouldn't be a problem as this class extends WebApplication. And pulling your application object out of spring context using SpringWebApplicationFactory should also just work.
And if your concerns are really big, this would be pretty easy and fast to confirm with a test IMO :)
We've been using Wicket-security for years now and we have used it together with jaas files and with annotatations. Defining jaas files is quite a hassle and maintaining them is near impossible...
With annotations one has to define actions and principals for every page. This is timeconsuming however it does allow you to let the user define roles and authorizations dynamically. It is also possible to test all the principals using the WicketTester.
Each of the 3 packages has it's (dis)advantages, it's a matter of taste and it also depends on the size of the application.
Related
I am not sure this is the correct place to ask this question but I could not see a forum link in spring-statemachine project(http://projects.spring.io/spring-statemachine/) to ask a question to the developers, I hope this is the correct way to do it.
For a while I wrote a blog,
Extremely Axajified Web Application
concerning about extremely asynchronous web applications, using Spring Webflow with those and the limitations of Spring Webflow for these sort of projects.
In my proposed solution, I used extensively state machine principles. At the timeframe that I wrote this blog there wasn't an out of the box State Machine that I can use, so I implemented my own version of it.
Now to my surprise, I just saw Spring Statemachine project and I considering to convert my sample application to use the Spring Statemachine framework.
I have two questions to ask before really starting investing effort to the subject. I checked the samples of the Spring Statemachine, it seems that the configuration of the State Machine is done via Java Code.
Is this only possible method, in my sample application, I am reading an UML Model (XMI) and create via Eclipse M2T a Spring configuration file to startup the application.
I find it is for practical uses to complex for the end user to configure a complex State Machine via Java code. For this purpose I used graphical user interfaces to create UML model of the State Machine and convert this to Spring application context, so it will be easier to understand for the end user.
Which you can see here.
UML Model (unfortunately Stack Overflow is not letting me post extra link so please use "#sm_model" at the end of the previous link)
Eclipse M2T UML Model conversion (see above "#m2t")
So is it possible to provide an XML file and configure Spring Statemachine with it? I can naturally create Java classes via M2T but I have a feeling end result will be nearly unreadable for end user for complex projects.
Second question I like to ask, can Spring Statemachine support "Nested Statemachines", I found in the project web site a hint about the possibility but in the existing sample project I could not find a concrete implementation.
Biggest hurdle for the usage of a State Machine in a practical web application is the "State Explosion" and best way to deal with it, is the "Nested Statemachines".
Does Spring Statemachine support this concept.
You can find more details about what I mean with "State Explosion" and "Nested StateMachines" in the following links.
State Explosion (see above "#stateexplosion")
Nested Statemachines (see above "#nested_sm")
I hope this was the correct place to ask these questions.
Thx for the answers
Sorry for late answer, I just noticed this tagged question.
We don't yet have any functionality to define machine config outside of annotation based config model(javaconfig). Xml config is in our roadmap and you can track its status in ticket https://github.com/spring-projects/spring-statemachine/issues/78.
For your second question, yes we support nested states and even orthogonal regions. Showcase example shows relatively complex scenarios how nested states and transitions between those can be used http://docs.spring.io/spring-statemachine/docs/1.0.0.RC1/reference/htmlsingle/#statemachine-examples-showcase.
I have a question regarding Java EE security best practices.
What are the advantages and disadvantages of using either annotations or a deployment descriptor to define Security for a web application?
Are there cases where you favor one over the other?
Thank you in advance :)
Well, it is mater of fashion. Some years ago there was massive movement "to sepearate application instrumentation from the programming" (you can read, for example, spec of EJB, where there is special role for this even, this person is not have to be even programmer). In this way use of XML was indorsed (instead of plain txt file or property files). And than annotations bring back those XML file to the code. I think it is due the mass in Spring framework. It was really hard to configure application (there was no good way to "debug" your configuration). Using annotation is "lightweight" way to make configuration. In simple scenarios you can skip defining relationships between your components, because they can be inferred from you code elements.
Using annotations is elegant (you do not require additional XML files) but requires to recompile your code every time you made a change.
I have a Java\Spring\Hibernate application - complete with domain classes which are basically Hibernate POJOs
There is a piece of functionality that I think can be written well in Grails.
I wish to reuse the domain classes that I have created in the main Java app
What is the best way to do so ?
Should I write new domain classes extending the Java classes ? this sounds tacky
Or Can I 'generate' controllers off the Java domain classes ?
What are the best practices around reusing Java domain objects in Grails\Groovy
I am sure there must be others writing some pieces in grails\groovy
If you know about a tutorial which talks about such an integration- that would be awesome !!!
PS: I am quite a newbie in grails-groovy so may be missing the obvious. Thanks !!!
Knowing just how well Groovy and Grails excel at integrating with existing Java code, I think I might be a bit more optimistic than Michael about your options.
First thing is that you're already using Spring and Hibernate, and since your domain classes are already POJOs they should be easy to integrate with. Any Spring beans you might have can be specified in an XML file as usual (in grails-app/conf/spring/resources.xml) or much more simply using the Spring bean builder feature of Grails. They can then be accessed by name in any controller, view, service, etc. and worked with as usual.
Here are the options, as I see them, for integrating your domain classes and database schema:
Bypass GORM and load/save your domain objects exactly as you're already doing.
Grails doesn't force you to use GORM, so this should be quite straightforward: create a .jar of your Java code (if you haven't already) and drop it into the Grails app's lib directory. If your Java project is Mavenized, it's even easier: Grails 1.1 works with Maven, so you can create a pom.xml for your Grails app and add your Java project as a dependency as you would in any other (Java) project.
Either way you'll be able to import your classes (and any supporting classes) and proceed as usual. Because of Groovy's tight integration with Java, you'll be able to create objects, load them from the database, modify them, save them, validate them etc. exactly as you would in your Java project. You won't get all the conveniences of GORM this way, but you would have the advantage of working with your objects in a way that already makes sense to you (except maybe with a bit less code thanks to Groovy). You could always try this option first to get something working, then consider one of the other options later if it seems to make sense at that time.
One tip if you do try this option: abstract the actual persistence code into a Grails service (StorageService perhaps) and have your controllers call methods on it rather than handling persistence directly. This way you could replace that service with something else down the road if needed, and as long as you maintain the same interface your controllers won't be affected.
Create new Grails domain classes as subclasses of your existing Java classes.
This could be pretty straightforward if your classes are already written as proper beans, i.e. with getter/setter methods for all their properties. Grails will see these inherited properties as it would if they were written in the simpler Groovy style. You'll be able to specify how to validate each property, using either simple validation checks (not null, not blank, etc.) or with closures that do more complicated things, perhaps calling existing methods in their POJO superclasses.
You'll almost certainly need to tweak the mappings via the GORM mapping DSL to fit the realities of your existing database schema. Relationships would be where it might get tricky. For example, you might have some other solution where GORM expects a join table, though there may even be a way to work around differences such as these. I'd suggest learning as much as you can about GORM and its mapping DSL and then experiment with a few of your classes to see if this is a viable option.
Have Grails use your existing POJOs and Hibernate mappings directly.
I haven't tried this myself, but according to Grails's Hibernate Integration page this is supposed to be possible: "Grails also allows you to write your domain model in Java or re-use an existing domain model that has been mapped using Hibernate. All you have to do is place the necessary 'hibernate.cfg.xml' file and corresponding mappings files in the '%PROJECT_HOME%/grails-app/conf/hibernate' directory. You will still be able to call all of the dynamic persistent and query methods allowed in GORM!"
Googling "gorm legacy" turns up a number of helpful discussions and examples, for example this blog post by Glen Smith (co-author of the soon-to-be-released Grails in Action) where he shows a Hibernate mapping file used to integrate with "the legacy DB from Hell". Grails in Action has a chapter titled "Advanced GORM Kungfu" which promises a detailed discussion of this topic. I have a pre-release PDF of the book, and while I haven't gotten to that chapter yet, what I've read so far is very good, and the book covers many topics that aren't adequately discussed in other Grails books.
Sorry I can't offer any personal experience on this last option, but it does sound doable (and quite promising). Whichever option you choose, let us know how it turns out!
Do you really want/need to use Grails rather than just Groovy?
Grails really isn't something you can use to add a part to an existing web app. The whole "convention over configuration" approach means that you pretty much have to play by Grails' rules, otherwise there is no point in using it. And one of those rules is that domain objects are Groovy classes that are heavily "enhanced" by the Grails runtime.
It might be possible to have them extend existing Java classes, but I wouldn't bet on it - and all the Spring and Hibernate parts of your existing app would have to be discarded, or at least you'd have to spend a lot of effort to make them work in Grails. You'll be fighting the framework rather than profiting from it.
IMO you have two options:
Rewrite your app from scratch in Grails while reusing as much of the existing code as possible.
Keep your app as it is and add new stuff in Groovy, without using Grails.
The latter is probably better in your situation. Grails is meant to create new web apps very quickly, that's where it shines. Adding stuff to an existing app just isn't what it was made for.
EDIT:
Concerning the clarification in the comments: if you're planning to write basically a data entry/maintenance frontend for data used by another app and have the DB as the only communication channel between them, that might actually work quite well with Grails; it can certainly be configured to use an existing DB schema rather than creating its own from the domain classes (though the latter is less work).
This post provides some suggestions for using grails for wrapping existing Java classes in a web framework.
Security always tends to take the last place in a new project. Or you use a framework like Spring where security is already build-in and can be switched on easily.
I try to find an open security framework that can be plugged-in to both Swing and Web applications (and JavaFX?), maybe easy to digest. I looked at plain JAAS, JGuard and JSecurity but its just too complicated to get started.
Any recommendations or experience to share ?
I am working with NB, Glassfish and MySQL.
Thanks
Sven
I have just taken a view of this http://shiro.apache.org/
Apache Shiro is a powerful and
easy-to-use Java security framework
that performs authentication,
authorization, cryptography, and
session management. With Shiro’s
easy-to-understand API, you can
quickly and easily secure any
application – from the smallest mobile
applications to the largest web and
enterprise applications.
I would strongly recommend learning JAAS. It really isn't that difficult to pick up, and there are some useful tutorials and a reference guide on the Sun web site.
In my experience, JAAS is pretty widely used, so it's definitely something you'll be able to reuse once you're learnt it. It also happens to be one of the building blocks for the Glassfish authentication mechanism!
I have done a similar research in JAAS for web application and has ran into a "mind roadblock" until I finally realize JAAS is a framework addressing security at a different "layer" then traditional web applications in the Java World. It is build to tackle security issues in J2SE not J2EE.
JAAS is a security framework build for securing things at a much lower level then web-application. Some example of these things are code and resources available at the JVM level, hence all these ability to set policy files in the JVM level.
However, since J2EE is build on top of J2SE, a few modules from JAAS was reuse in J2EE security such as the LoginModules and Callbacks.
On the other hand, Acegi, aka Spring Security, tackles a much higher "layer" in the securing web-application problem. It is build on top of J2EE security hence J2SE hence JAAS. Unless you are looking to secure resources in the J2SE level (classes, System resources), I don't see any real use of JAAS other than the using the common class and interfaces. Just focus on using Acegi or plain old J2EE security which solves a lot of common web application security problems.
At the end of the day, it is important to learn which "layer" of the J2EE-J2SE security issue you are tackling and choose the write tool(s) for the problem.
I would recommend you take a look at OACC (http://oaccframework.org). OACC was designed for solving the problem of application security. Unlike most frameworks OACC is able to store/manage the authorization relationships in your application. OACC's authorization model is more powerful that Shiro or Spring Security.
There is alternative from JBoss. A new version for PicketBox. More information here:
https://docs.jboss.org/author/display/SECURITY/Java+Application+Security
apache shiro miserably fails when you stress a web application under JBoss (say 2 million requests of a simple GET with a concurrency of 50 threads).
was very dissapointing to find out this.
it happens when you use filters.
You can read http://code4reference.com/2013/08/guest-posttop-java-security-frameworks-for-developing-defensive-java-applications/
It gives 1000mile view from various Java Security framework, such as JAAS, Shiro or Spring Security. All are depended on your requirements and technology stacks that you choose
I have a mixed UI (Win App, WPF App, and soon an ASP.NET MVC App) setup, so far I'm using Client Application Services for security. I know how to programmatically get a user authenticated and doing so is working beautifully. However...
I want to implement some cross cutting that basically checks to see if the user is authenticated all the time. Since everything will be accessing web services I want to enable this as a standard execution for pretty much everything the UI does. So far I'm thinking the PIAB - Policy Injection Application Block - will serve that function. What I'm wondering is two things;
1 Will the PIAB cover that needed functionality? Verifying authentication at every practical step if used against the UI?
...and...
2 Are there alternatives out there besides the PIAB? I'm curious to do a comparison of aspect oriented policy injection frameworks.
I'm not really familiar with Client Application Services but from my experience, most AOP frameworks wrap interfaces in order to implement the cross-cutting functionality. If CAS uses interfaces, you could probably just wrap them with what ever functionality you require.
Alternative AOP frameworks:
Spring.NET
Castle Dynamic Proxy
Spring.NET and Dynamic proxy seem to work in much the same way and have much the same performance in my Hello World type tests (about half-way between direct calls and invoking through reflection). PIAB is significantly slower than both these frameworks and I found bit more verbose. It does have the ability to be configurable via xml and I'm not sure if that's a good thing or not. Not sure if the other frameworks provide that. It does of course have the MS stamp of approval though :P.