You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by gcollins <ga...@gmail.com> on 2014/01/15 07:38:53 UTC
Asynchronous Authentication
Hello,
I was wondering - any thoughts of extending the Shiro API to support
asynchronous authentication/authorization e.g.:
interface Authenticator {
ListenableFuture<AuthenticationInfo> authenticate(AuthenticationToken
authenticationToken)
throws AuthenticationException;
}
I ask because I am working with an authentication backend which may have
significant latency (thus blocking a lot of threads). I am thinking of how
to fit it best in with Shiro. I am also using Shiro via ServletFilters so I
would be looking to see if I can take advantage of Servlet 3 asynchronous
features as well to minimize thread usage.
Just seeing if anyone may have thought about this.
thanks in advance,
Gareth Collins
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Asynchronous Authentication
Posted by Josh Berry <ta...@gmail.com>.
Still not sure I understand. If the service is async, it probably already
has a bound on number of requests it can handle, right? At some level, you
can get more requests than it can handle. With that, you will have to
somehow provide some sort of buffer layer. I guess you could push this
configuration into shiro, but you will still have to manage it in your
application.
That is, it seems like it would be easier to take that into your domain as
early as possible. Your authentication realm will simply block for as many
requests as your executor can take, if it hits the limit, it starts
returning unauthenticated. Right?
On Jan 20, 2014 11:21 AM, "gcollins" <ga...@gmail.com> wrote:
> Josh Berry wrote
> > On Thu, Jan 16, 2014 at 5:14 PM, gcollins <
>
> > gareth.o.collins@
>
> > >wrote:
> >
> >> Hello Les,
> >>
> >> Thankyou very much for the answer!
> >>
> >> Yes I could do that but it doesn't really solve my problem. When
> requests
> >> for authentication spike, I would either need to allocate a large number
> >> of
> >> threads for the ExecutorService thread pool...or slow down
> authentication
> >> for users by queueing the requests up (the authentication request could
> >> take
> >> several seconds to complete).
> >>
> >
> > I'm curious on how this wouldn't be the case for any asynchronous
> > approach.
>
> The underlying custom authentication mechanism itself is asynchronous. Only
> trying to keep
> to existing Shiro interfaces would force me to hold threads.
>
> thanks,
> Gareth
>
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507p7579536.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Asynchronous Authentication
Posted by gcollins <ga...@gmail.com>.
Josh Berry wrote
> On Thu, Jan 16, 2014 at 5:14 PM, gcollins <
> gareth.o.collins@
> >wrote:
>
>> Hello Les,
>>
>> Thankyou very much for the answer!
>>
>> Yes I could do that but it doesn't really solve my problem. When requests
>> for authentication spike, I would either need to allocate a large number
>> of
>> threads for the ExecutorService thread pool...or slow down authentication
>> for users by queueing the requests up (the authentication request could
>> take
>> several seconds to complete).
>>
>
> I'm curious on how this wouldn't be the case for any asynchronous
> approach.
The underlying custom authentication mechanism itself is asynchronous. Only
trying to keep
to existing Shiro interfaces would force me to hold threads.
thanks,
Gareth
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507p7579536.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Asynchronous Authentication
Posted by gcollins <ga...@gmail.com>.
Brian Demers wrote
> Is this something where caching, or some sort of replication would speed
> up
> your auth?
I cannot cache as the authentication server is not under our control (we are
middleware).
Also certain session information must be initialized in the backend as part
of the authentication
process.
thanks,
Gareth
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507p7579537.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Asynchronous Authentication
Posted by Brian Demers <br...@gmail.com>.
Is this something where caching, or some sort of replication would speed up
your auth?
On Fri, Jan 17, 2014 at 10:26 AM, Josh Berry <ta...@gmail.com> wrote:
>
>
>
> On Thu, Jan 16, 2014 at 5:14 PM, gcollins <ga...@gmail.com>wrote:
>
>> Hello Les,
>>
>> Thankyou very much for the answer!
>>
>> Yes I could do that but it doesn't really solve my problem. When requests
>> for authentication spike, I would either need to allocate a large number
>> of
>> threads for the ExecutorService thread pool...or slow down authentication
>> for users by queueing the requests up (the authentication request could
>> take
>> several seconds to complete).
>>
>
> I'm curious on how this wouldn't be the case for any asynchronous
> approach.
>
Re: Asynchronous Authentication
Posted by Josh Berry <ta...@gmail.com>.
On Thu, Jan 16, 2014 at 5:14 PM, gcollins <ga...@gmail.com>wrote:
> Hello Les,
>
> Thankyou very much for the answer!
>
> Yes I could do that but it doesn't really solve my problem. When requests
> for authentication spike, I would either need to allocate a large number of
> threads for the ExecutorService thread pool...or slow down authentication
> for users by queueing the requests up (the authentication request could
> take
> several seconds to complete).
>
I'm curious on how this wouldn't be the case for any asynchronous approach.
Re: Asynchronous Authentication
Posted by gcollins <ga...@gmail.com>.
Hello Les,
Thankyou very much for the answer!
Yes I could do that but it doesn't really solve my problem. When requests
for authentication spike, I would either need to allocate a large number of
threads for the ExecutorService thread pool...or slow down authentication
for users by queueing the requests up (the authentication request could take
several seconds to complete).
OK, I will need to think about this a little more. Perhaps I will need to go
a bit further off the reservation here.
Thanks again!
Gareth
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507p7579524.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Asynchronous Authentication
Posted by Les Hazlewood <lh...@apache.org>.
I'm not quite sure this belongs in the Shiro API proper, that is, not
at least until we would support async operations in a much more
fundamental way across the framework - which I'm not sure would work
or not without rewriting significant parts of Shiro :)
Why not just wrap the call in a Callable and use an ExecutorService?, i.e.
final AuthenticationToken token = //create or get from somewhere
Future<AuthenticationInfo> future = executorService.submit(new
Callable<AuthenticationInfo>() {
public AuthenticationInfo call() {
return authenticator.authenticate(token);
}
});
This seems like a good/clean solution to me. Thoughts?
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Tue, Jan 14, 2014 at 10:38 PM, gcollins <ga...@gmail.com> wrote:
> Hello,
>
> I was wondering - any thoughts of extending the Shiro API to support
> asynchronous authentication/authorization e.g.:
>
> interface Authenticator {
> ListenableFuture<AuthenticationInfo> authenticate(AuthenticationToken
> authenticationToken)
> throws AuthenticationException;
> }
>
> I ask because I am working with an authentication backend which may have
> significant latency (thus blocking a lot of threads). I am thinking of how
> to fit it best in with Shiro. I am also using Shiro via ServletFilters so I
> would be looking to see if I can take advantage of Servlet 3 asynchronous
> features as well to minimize thread usage.
>
> Just seeing if anyone may have thought about this.
>
> thanks in advance,
> Gareth Collins
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507.html
> Sent from the Shiro User mailing list archive at Nabble.com.