(newbie) replacing osuser?

[greg_greg]

Hi,

I was very recently introduced to Acegi. It looks very interesting, complete and flexible, has apparently very good docs and nice support. So all this is making me enthousiastic.
I was about to use osuser for a new web application at work; I find it very it easy to get started with, but it has a few limitations that Acegi probably covers.

However, I'm also concerned by simplicity and ease of use (have to deal with a couple of junior developers...) So I'm currently left with a few questions about Acegi vs. osuser that i'd be pleased to get an answer to.

- Is the term Authority, in Acegi, an equivalent to the notion of a "permission" ?
- Is there any notion of "group" in Acegi? I didn't see any trace of that, but I find it quite surprising. Maybe the fact that Authorities can be inherited can circumvent this? I'm used to the idea of a user->groups->roles->permissions hierarchy, where groups and roles are just sugar for the admin's job, to avoid having to give grants, permission per permission, for each and every user. Maybe this is a misconception, or maybe not, and maybe this actually exists within Acegi and I just did not see it.
- Are the services of user creation and the likes (managing users/groups/roles associations, cfr question above) a concern of Acegi or not? Osuser provides easy ways to manage these things, and not finding that in Acegi would make my decision harder, since I don't really feel like re-inventing that. Maybe it's just there, and once more, I did not see it, or maybe it's available through some other project that I don't know?
- Is there any notion of user profile in Acegi ? Again, to compare with osuser, there I have a simple PropertySet per group and per user where any property can be set (email address, number of pets, application preferences, you name it)

I think that's it for now.
Please note that I really appreciate the work on Acegi, and by no means I want to sound rude by comparing to osuser, which obviously has different concerns/priorities. I just want some help in making the right decision

Cheers,

greg

[Ben Alex]

In Acegi Security, GrantedAuthority represents permissions.

In terms of the remainder of your questions, they are mostly related to user administration. This is totally pluggable in Acegi Security, but most people use DaoAuthenticationProvider which works with an AuthenticationDao. Your AuthenticationDao is responsible for returning a UserDetails implementation.

Your UserDetails implementation provides the principal (username), credentials (password) and GrantedAuthority[]s. These are directly used in the Authentication object and by the various Acegi Security interfaces and classes.

The UserDetails itself is also stored in the Authentication object, so this is the way you add extra user-specific properties. Typically people extend the User object, which is a base implementation of UserDetails.

Regarding groups and user management more generally, Acegi Security does not implement them. These are considered application responsibilities and part of the AuthenticationDao contract. I know this might sound a bit harsh, but the notion of users varies widely between applications. For example, a basic tool might just want a simple username and password. A project I'm currently working on has a hierarchial party management requirement with Party, Organization, Person and RelatedParty objects. In addition, people have their favourite web framework, view technology (JSP vs Velocity vs FreeMarker etc), decoration system (Tiles vs includes vs SiteMesh) and persistence framework, so all this variation makes it difficult to provide a basline user management tool that most people would employ. We might add it in the future, but most people find implementing their AuthenticationDao pretty straight forward and we do provide several examples (including a JDBC-based AuthenticationDao).

[greg_greg]

ok, thanks for your reply. all of this makes much sense. That will just give me some extra work