JAX-RS async can be enabled per resource, so its really up to you to
decide if Authz needs it.
Async doesn't make sense for core KC autthentication. KC Identity
broker does not wait/block for a response on a login. Authenticators are
not waiting/blocking for responses either. Waiting/blocking only happens
on backchannel logouts and background admin operations. Somebody is
going to have to show me real tangible benefits before we switch core KC
to use Async JAX-RS or some async event driven SPI, because right now,
with our currently functionality and our roadmap, there is no need for
an async model.
On 3/29/2016 9:57 PM, Raghuram Prabhala wrote:
+1. Makes sense for even KC (as Identity broker waiting for a
response
from Identity provider or as Identity provider waiting for a response
from Authenticators)
------------------------------------------------------------------------
*From:* Pedro Igor Silva <psilva(a)redhat.com>
*To:* keycloak-dev <keycloak-dev(a)lists.jboss.org>
*Sent:* Tuesday, March 29, 2016 9:47 PM
*Subject:* [keycloak-dev] Async HTTP Request Processing
Hi,
I'm working with the AuthZ Java API in order to make it more
event-driven and non-blocking. During our F2F, I've discussed some
very interesting requirements with Marc Savy around that.
I would like to know if makes sense to enable JAX-RS Async support
to some AuthZ REST endpoints, which are basically using this API to
evaluate policies using different providers (where these providers can
be executed in parallel).
Regards.
Pedro Igor
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com