Hi Kalle, This is mostly an artifact of an old codebase. The idea was originally that a Realm should have the ability to respond to both authorization and authentication operations for a data source. The Authorizer interface included all possible authorization options, so by having the Realm extend that interface, we guaranteed that a Realm could react to any authorization operation if it needed to. A Realm implementation could return false for all Authorizer methods if it didn't want or need to do authorization, so there was no harm in imposing that interface (at the risk of being less than convenient).
I wouldn't classify AuthenticatingRealm as 'useless' - just not convenient (the authentication workflow it does provide is still worth using IMO). Most people choose to use AuthorizingRealm which basically implements all of those methods and is considered more 'convenient' to get around the pain of stubbing the methods. But, I do see your point, and very much agree that there is a better way to deal with this, and that if we can clean this up for 2.x, I definitely support it. In fact, I've long envisioned an authorization API that is much more coarse-grained, e.g.: AuthorizationResponse response = realm.isAuthorized(AuthorizationRequest request); This would allow supporting a multitude of authorization scenarios, and because of the very coarse-grained nature of the method, the Request/Response APIs could change and/or be modified over time without much impact on the Realm implementations. We could also formulate very robust authorization checks via a Criteria API (e.g. role = 'blah' and in group 'foo' except with permission 'bar', etc.) I don't know if a request/response + Criteria solution is a good idea yet - it would likely add a level of complexity that most Realm implementors may not want to see, but it would provide a tremendous amount of flexibility that may justify it - especially if we're trying to provide a definitive authorization API. It's worth discussing anyhow. It also seems like Authentication should mirror this same approach, for the same benefits, e.g.: AuthenticationResponse response = subject.login(AuthenticationRequest request); This would allow a much cleaner way of performing multi-stage authentication (something I need to solve myself), where the first authentication attempt is successful, but the response dictates that another (different) type of authentication be used to complete the process. I've seen this need in the banking/financial industry, and the only way to solve it now is to do a lot of custom coding in realms and use AuthenticationExceptions to trigger different workflows (yuck). It also mirrors SAML's structure and could work in conjunction with that as well. Anyway, this is probably a lot more than what you were asking for, but I figured now was a good time to 'get it out' to see what others think about it since it stems from the same concern represented by your question. Cheers, Les On Fri, Jan 7, 2011 at 12:18 AM, Kalle Korhonen <[email protected]> wrote: > Why does a Realm extend Authorizer? Shouldn't only the > AuthorizingRealm implement Authorizer? This makes the > AuthenticatingRealm fairly useless since you need to implement a bunch > of authorizing operations even if your realm is not supposed to do > anything more than just authenticate. There's probably a good reason > for Authorizer being the top level interface rather than Realm, but > it's just not immediately obvious for me. Even then, I hope we could > straighten this out in a future release since it just doesn't seem > right to me. Les, care to comment, I bet you have a pretty good > insight into this. > > Kalle
