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). > So far the score between Ki and Spring Security are fairly even in our > evaluation, but the architects who gave us this assignment, are really > looking for alternatives, which also provides either a UI or at least a > sensible API for managing users, roles, permissions etc. – and so far we > have found nothing – I hope some of you security experts out there can point > me in a promising direction… …or tell me, that we have to develop ourselves… > > Authentication is very similar to Spring Security (even too much to my liking, down to some Spring specific conventions e.g. afterPropertiesSet). What makes a difference is the flexible permission model in Ki (dynamic, instance-based permissions are just not in the scope of plain Spring Security). Whether you need it or not, depends on the requirements of your projects - for standard role-based permissions either would work absolutely fine. I wouldn't expect or use any default UI/app for managing users - I mean I'd hate to use a Java standalone app for user management if my application was otherwise inherently web-based or the other way around. There are plenty of CRUD application frameworks that you could use to quickly build up a user management app. Kalle > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Les Hazlewood > *Sent:* Thursday, April 02, 2009 18:58 > *To:* [email protected] > *Subject:* Re: Writing a custom authorization component... > > > > Hi Sune! > > Sorry for the confusion - I replied to the forum earlier today, but you did > the right thing by using the mailing list instead. I'll post my reply here > for your (and others') benefit. I hope it helps. Please let us know if you > have further questions! > > ---- > > Sorry for the late reply - most traffic is on the mailing lists these days. > > Basically, I think you can make this work rather easily actually, even > without overriding most of the infrastructure. Most users configure Realms > and not much else, and I think you can get away with that as well. > > JSecurity (now called Ki) allows for multiple Realms to be configured in > the application's SecurityManager instance. Assuming each 'level' (global, > web site, and sub site) requires accessing a different data source, you > would probably have 3 Realms configured - one for each level. The first time > an authorization check (role, permission) is performed, each realm will do > the required lookup and cache the results if possible. So, the first 2 > realms should work as normal. > > Your third 'sub site' realm can extend the AuthorizingRealm class, and when > a user switches sites, you can write some framework code that calls > yourAuthorizingRealmSubclass.clearCachedAuthenticationInfo(PrincipalCollection) > for that user only. Then the next time a role check occurs on that sub-site > Realm, it will force doGetAuthorizationInfo(principals) to be called again. > Your implementation of this method can then access the appropriate 'sub > site' data source, and the results will be cached for further use until you > clear that cache entry again (presumably upon switching sites). > > Does that help? Feel free to ask more questions, but you might get a faster > response on the Apache Ki mailing lists since the project has moved to the > Apache infrastructure. The jsecurity.org website is just online primarily > for archival purposes. > > Cheers, > > Les > > > > On Thu, Apr 2, 2009 at 1:37 AM, Sune Lindberg Riedel < > [email protected]> wrote: > > Hi! > > I tried to post my question below on the forum, but either nobody knows > the answer or the amount of people who knows that answer and has time to > help are too limited - so I will give it a shot on the mailing list - I > am not looking for an answer that will provide me with the perfect > solution - just some thoughts and ideas about how to make it work using > JSecurity/Ki: > > I am currently working on a web project where some bright people > thought: Hey, we need some authorization... ...cue ME! > > The Setup: > The great thing about this project is, that so far we don't have any > existing security model (like LDAP), so we can pretty much choose what > we like. > > The not so brilliant thing (from a security/authorization point of view) > is that we don't have a setup, where we can use the general user/role > model. > > We have a setup where we have one central backend server - this is where > the global user profiles are stored. > We then have several "local" servers, each of which contains several web > sites (which have their own unique URL's). > > A person only have one global user profile, but may have a local profile > for each web site. The user may log on to any web site, where he has a > local profile, and he may use his global username/password or the > credentials he has for the local web site (if he uses the global > username, we will look at the URL to figure out which local profile he > has). > > Now the tricky part is the roles: > - A user may have certain roles at the global level - these roles (and > their permissions) are valid for all web sites he logs in to. > - A user may have certain roles at the web site level - these roles are > valid for the entire site (and sub-sites). > - A user may have certain roles at a sub-site level - these roles are > only valid for a particular subset of the website (typically a sub-URL) > he is logged into. > > Now, the first two levels of roles can be determined at login time, but > the roles that are only valid for a given sub-site, must be > added/removed to the active set of roles/permissions whenever the user > switches to another sub-site. > > The question: > Now, I've looked a little at the documentation, examples and some source > code of JSecurity/Ki and I am convinced that somehow we can make a > solution with this - a good solution even. Unfortunately I'm no security > expert, so I am struggling quite a bit, trying to figure out which > classes I need replace in the default implementation with my own > implementations to make this work. I figure I need to make a custom > Authorizer at least, but I may also have to do my own implementations of > AuthorizationInfo... > Bottom line: I just don't get it - looking at the sample app, which > instantiates a DefaultSecurityManager and uses Default[everything] - > what do I replace to make a custom security solution, that will help me > solve the scenario described above? > > Heeelp... > > Best Regards > /Sune > > >
