wood burning stoves 2.0*
The moose likes Spring and the fly likes Question about Spring Permissions and why they extend java.security.Permission Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Question about Spring Permissions and why they extend java.security.Permission" Watch "Question about Spring Permissions and why they extend java.security.Permission" New topic
Author

Question about Spring Permissions and why they extend java.security.Permission

Jon Fisher
Greenhorn

Joined: Sep 30, 2008
Posts: 3
What was the driving decision to have the Spring permission classes extend java.security.Permission?

IMHO it's a PITA.

First, the bitmask in the java.security.Permission class cannot be used like an actual bitmask.
Second, things like 'create, update, delete, insert' are very relevant in a CRUD application, but have little value across an enterprise.
Third, because the Permission class is a hard class, security cannot be remoted over RMI, without synchronizing your permission classes across your enterprise applications.
Fourth, Spring requires hard classes for Permissions, but doesn't really use the benefits of having concrete implementations anywhere, since the existence of a permission type isn't checked at compile time.
Fifth, it's a PITA to new permissions, making it difficult to create a fine grained infrastructure!
Sixth, Spring permissions don't correspond to business permissions.

Because of these limitations, Spring Security makes a very poor enterprise security solution, whereas Spring is a very excellent enterprise framework.

My organization came up with a pretty good plan that solves most of these problems...

We decided that 'Permissions' are simple Strings, eliminating the need to have permission classes distributed across the enterprise. Then, we implemented the PermissionEvaluator interface as a stateless EJB. We still have to distribute our domain objects across the enterprise, but since we do that anyway, and we have an anemic domain model, this is not a problem.

Our permission checks are now very fined grained, and they correspond to very granular business functions... example:

hasRole(ROLE_SOME_WEBSERVICE) and hasPermission(PERM_TRANSFER_REMAINING_BALANCE)

This is a greatly simplified implementation compared to the Spring default. The permission evaluator is also strategy based depedending on the target permission. Some permissions are looked up in a database, some are done via code, where appropriate.
Peter Mularien
Author
Ranch Hand

Joined: Sep 06, 2007
Posts: 84
Hi Jon,

Wow, great message! I'm not sure if this question was directed towards me, so I'll try to answer.

#0: I'm curious why you reference java.security.Permission - as far as I can find, this class isn't used in Spring Security at all (feel free to correct me, I checked in both Spr Sec 2.0.5 and 3.0.3); however, some of the points you make are (or, in some cases, were) true of the Spring Sec ACL module.
#1: This is true and a long-standing bug/feature of the Spr Sec ACL module - I'd suggest browsing the Spr Sec JIRA repository and voting up issues you think are important.
#2: This is true, but very easy to replace BasicPermission with your own implementation, and/or map the bits to your own business meaning (we cover this in a limited fashion in the ACL chapter of the book). The more typical problem is that 32 bits just aren't enough for complex business scenarios.
#3: See #0 (although I can't guarantee there aren't other classes that aren't Serializable, I think most are).
#4: True!
#5: This is much less true in Spr Sec 3, which has some important enhancements in the usability of the ACL module.
#6: See #2.

It sounds like your implementation is a great alternative solution - I think there's been a lot of grumbling about the Spring Sec ACL module, and my suggestion would be that (if you feel there's any value to it at all!) you use Spring Sec JIRA to file / vote issues that you feel will enhance the framework.

I hope this answers your question!

Best,
Peter


Author, Spring Security 3 (the Book), Packt Publishing, 2010
SCJP, OCP
Jon Fisher
Greenhorn

Joined: Sep 30, 2008
Posts: 3
Peter Mularien wrote:Hi Jon,

Wow, great message! I'm not sure if this question was directed towards me, so I'll try to answer.

#0: I'm curious why you reference java.security.Permission - as far as I can find, this class isn't used in Spring Security at all (feel free to correct me, I checked in both Spr Sec 2.0.5 and 3.0.3); however, some of the points you make are (or, in some cases, were) true of the Spring Sec ACL module.
#1: This is true and a long-standing bug/feature of the Spr Sec ACL module - I'd suggest browsing the Spr Sec JIRA repository and voting up issues you think are important.
#2: This is true, but very easy to replace BasicPermission with your own implementation, and/or map the bits to your own business meaning (we cover this in a limited fashion in the ACL chapter of the book). The more typical problem is that 32 bits just aren't enough for complex business scenarios.
#3: See #0 (although I can't guarantee there aren't other classes that aren't Serializable, I think most are).
#4: True!
#5: This is much less true in Spr Sec 3, which has some important enhancements in the usability of the ACL module.
#6: See #2.

It sounds like your implementation is a great alternative solution - I think there's been a lot of grumbling about the Spring Sec ACL module, and my suggestion would be that (if you feel there's any value to it at all!) you use Spring Sec JIRA to file / vote issues that you feel will enhance the framework.

I hope this answers your question!

Best,
Peter

I've got my foot-in-mouth on extending java.security.Permission. I thought I had saw that in the code, but you're correct, the Spring-Security Permission is it's own interface!

The driving decision on our end was that GrantedAuthority is essentially a String, so why should Permission be the same? Additionally, a Java integer can only hold 31 flags if I remember right. We don't want to place that limit on ourselves.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question about Spring Permissions and why they extend java.security.Permission