On Sun, Apr 5, 2009 at 10:46 PM, Kalle Korhonen <[email protected]>wrote:
> On Sun, Apr 5, 2009 at 3:00 PM, Sune Lindberg Riedel < > [email protected]> wrote: > >> Another huge black hole in our solution is: where is the API for ** >> declaring** the roles and permissions for the different realms – I don’t >> see methods for setting roles and permissions anywhere in the Ki API’s (and >> neither in Spring Security, which we have also been investigating). In eg. >> JDBCRealm, there are nice queries for resolving roles and permissions, but >> how does the data get into these tables in the first place. What do people >> do when it comes to declaring this stuff? Is there a standard way to do >> this? Or some widely used standard products (that I have just missed)? >> > Just comments from another user of Ki, but I also have lots of experience > on Acegi/Spring Security as well CMA (Container Managed Authentication) and > JAAS. There are too many ways to map roles and permissions to your > persistence model to make any default implementation. In real world, users > often start with an existing user database (LDAP, Windows domain users, NIS > accounts etc.) and adapting it to a default implementation is often > impractical. Ki could supply some generic base interfaces that users can > choose to implement (which Spring Security does to some extent). > Yep, this is exactly why Ki is mostly a 'read only' API. Data models vary so dramatically across multiple applications that there is no way we could impose conventions on end users - which would be required if Ki managed the CRUD operations for said data model. For example, a common convention is that a User has one or more Roles. Roles can have one or more Permissions. But that's usually where the similarities end. That is, could a User have Permissions assigned to them directly? In my apps, I don't do that - I always have a private Role to which permissions are added, just like any other Role, which gives me per-user permissioning capability - this keeps my permission-check code consistent. But that's not to say that another application would do that. Or, do you use Groups? In my apps that need them, a Group has a collection of one or more Users and also has a collection of one or more Roles. By transitive association, if a user is in a group, then they also have the group's roles. This is purely a convenience mechanism - many applications (I dare say most) don't have the need for Groups at all. Similarly, many simple applications don't use Permissions at all and get by on Roles only. Hopefully the number of permutations based on application requirements can give you insight as to why we don't provide 'write operations'. There's no way to predict how application's will declare their data model. I hope the above examples give some insight in to our decisions and perhaps some ideas for your own data model. Cheers, Les P.S. There has been some discussion to provide an out-of-the-box data model that would employ what the Ki team feels are best practices, specifically to kick-start many users who don't really want to think about the data model design of flexible security systems. If created, it would definitely be purely optional.
