shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: Rememberme vs authentication
Date Thu, 18 Jun 2009 01:09:20 GMT
On Wed, Jun 17, 2009 at 10:44 AM, Les Hazlewood<lhazlewood@apache.org> wrote:
> Fair enough, although this does take quite a bit of effort to set up
> compared to the other approach, which I have to say I've used successfully
> on many commercial web sites with no ill-effect.  That doesn't mean the
> existing approach is the best it can be, it just means that, as is the case
> of so many things in the security world, that it hasn't been exploited yet
> on anything I've been involved with.  There is _always_ room for improvement
> in a security framework.
> So, do you think 1) this paradigm could be easily incorporated into the
> framework in a 'hands off' approach where it would work out of the box with
> no required configuration and 2) if so, should it be the default
> implementation used at startup?

No, I don't think it can be easily implemented in plain Shiro. The
reason is the same as to why Shiro's Realm API is read-only: since
Shiro cannot rely on any particular persistence model to exist, it's
difficult to implement any more complex server-side authentication,
identification or verification logic that would work out-of-the-box.
Since I'm not bound to these limitations (the security module I'm
working on requires JPA persistence) I can implement it fully as a
drop-in functionality - users of the library won't even need to know
how it works.

> If the onFailedLogin and onSuccessfulLogin methods are not suitable, I'd be
> more than happy to add a 'beforeLogin' method to the interface if you think
> that would be sufficient.  This would provide proper AOP-ish 'around advice'
> for an authentication attempt.
> Interestingly enough, both the RememberMeManager and the
> AuthenticationListener are nearly identical.  I think if we add a
> 'beforeLogin' method it should go into the AuthenticationListener interface
> and the RememberMeManager should just extend that interface.  Anyone have
> any objections on this?

Even adding onLogin won't help me since I want to do something after a
remembered identity was retrieved. But yes, I see a lot of custom
logic dealing specifically with rememberme when it mostly looks like
an authenticationListener (except for the added
getRememberedPrincipals). So I think making RememberMeManager extend
the AuthenticationListener is a good idea.

> If you think this is a good approach and would allow you to do what you
> need, please open a Jira issue and I'd be more than happy to push it
> through.  If this won't allow you to do what you desire, please let me know
> why not and we can see how other mechanisms might be made available to do
> what you need.  At the end of the day, you have the ability to create
> Subject instances however you want via a custom implementation of the
> SubjectFactory interface (which is still in flux and might change to reflect

I was going to write that I think my best short term approach is to
override the DefaultSecurityManager which I didn't particularly like
because it would have created a lock-in for users, but yes I see that
SubjectFactory is new and might be exactly the extension point I need.
I can use the default RememberMeManager exactly as intended and keep
the rolling tokens separate, then use a custom SubjectFactory that
will do the token reading and comparison and invalidate the remembered
identity as needed. Thanks for that - I've been using 0.9 javadocs so
I missed SubjectFactory but I'm looking at trunk source now.

Kalle

Mime
View raw message