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
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 haven't looked at Spring Security's ACL support in a while, so I
can't comment there. However, Ki takes a very simple approach to
ACLs. Check out the JavaDoc on Ki's WildcardPermission. The
underlying model can model the ACL any way it wants and just hand Ki
back some simple strings that explain a user's ACL permissions. In
fact, many applications just store these ACL string permissions in the
database exactly in the format Ki supports so it's extremely easy to
model.
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.
