shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: Realm extends Authorizer, why?
Date Fri, 07 Jan 2011 17:45:40 GMT
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
<kalle.o.korhonen@gmail.com> 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

Mime
View raw message