Hi again!
Once more – thanks for answering my questions so quickly – it’s nice to know there is an active community behind Ki. Kalle, if I am understanding you correctly, there is no “total package” for a security solution (meaning API and underlying implementation for both managing and applying security features)? – and the reason or this is, that in most cases when you need to apply security to your application, you already have an existing user database (and then you just extend it with roles and permissions as needed – by hand). But is this what everybody does when they need to apply role-based permissions to a system – code it from scratch (everything from designing database tables to making a UI within your application, that allows the administrators to manage these settings)? Of course I see the problem in making an API, that adapts to all the various ways these data can be stored, but in some (most?) situations you don’t have to that much to apply the security (i.e. read from the model) – you only have to do some configuration, right? …or do you need to extend one of the existing realms to make it understand exactly how your data model is wired? If only configuration is needed, then my next question would be: Couldn’t you just make an implementation for managing permissions, that used the same configuration to figure out how to write to the tables? …or is it more complicated than that? (I’m just talking about making an API available for managing this – not an entire UI application) I learned that Spring Security specifies how to design the data model, when you want to use ACL – how come they do that? Is that because ACL is so freaky, that it needs to be implemented in a certain way (and most likely *not* part of the existing user tables you got) or am I getting it all wrong? I hope you won’t forget my question from my previous mail about having to apply security to an application where part of it has a session with a logged in user, and part of it is stateless and requires all information to be included in the invocation… That was a lot of questions (again) – I hope some of you will find the time to help me along – then someday I hope I’ll be clever enough to help the next new kid on the block… J BR /Sune (apparently I hope a lot) From: [email protected] [mailto:[email protected]] On Behalf Of Les Hazlewood Sent: Monday, April 06, 2009 05:36 To: [email protected] Subject: Re: Writing a custom authorization component... 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.
