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 >
