[keycloak-dev] Authentication Provider chaining

Marek Posolda mposolda at redhat.com
Thu May 19 16:06:59 EDT 2016


For example you can create 2 subflows of the top flow and mark them as 
ALTERNATIVE. Then if you create "children" execution of subflow1 
pointing to your authenticator inside it, then in the code of your 
authenticator you can switch the state to ATTEMPTED and if the 
authenticator execution is required, it will cancel subflow1 and go to 
subflow2. At least I hope it will work like this :-)

If you want some more complex logic and dependency of authenticator on 
the state of other authenticator etc. you can maintain the state inside 
clientSession notes. Then authenticators will be executed in the fixed 
order, but for example in the code of authenticator2 you can do 
something like :

if 
("true".equals(clientSession.getNote("wasAuthenticator1FinishedSuccessfully")) 
{
    // skip this authenticator2 as authenticator1 already authenticated 
user or did something, which allows you to skip authenticator2 and move 
directly to authenticator3 etc.
   context.attempted();
   return;
}

etc.
Marek

On 19/05/16 16:31, Rashmi Singh wrote:
> Could someone please tell me if this is even possible? I do not want 
> the execution engines/authentication providers to be executed in a 
> fixed order defined in the admin console. But, need to be able to 
> switch to any in the chain depending on some response I get upon 
> invoking an external service. I needed to know if this is possible and 
> if yes, then how? Any help would be appreciated.
>
> On Wed, May 18, 2016 at 4:21 PM, Rashmi Singh <singhrasster at gmail.com 
> <mailto:singhrasster at gmail.com>> wrote:
>
>     Thanks a lot for your response. I went through the chapter. What I
>     understand is we can create multiple executions (authentication
>     providers) but they are executed in a serial fashion in a fixed
>     order defined. Is there a way to be able to switch between them
>     (so, not have it executed in the default serial way but depending
>     on the response we get from an external service we called, we can
>     switch to the corresponding one). Any ideas?
>
>     On Tue, May 17, 2016 at 3:49 AM, Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>         The docs is here :
>         http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
>
>         We have also example for authentication SPI. Note that you can
>         create sub-flows in the "top" flow, which might be a way to
>         split the authenticator into multiple ones. For example see
>         "Forms" flow in default "Browser" flow. Also maybe you will
>         need to implement some logic programatically in your
>         authenticators based on various conditions etc. Depends on the
>         usecase though...
>
>         Marek
>
>
>         On 16/05/16 23:52, Rashmi Singh wrote:
>>         Hi,
>>
>>         I am looking for a way to do authentication provider chaining
>>         with keycloak. Basically, I want to have multiple
>>         authentication providers, example username, Suregrid etc. On
>>         submitting username, we call a service and if that service
>>         tells us to use SureGrid, then we should be able to pass
>>         control to the corresponding authentication provider. So
>>         basically, I want to spilt one authentication provider into
>>         multiple and be able to chain them based on the response from
>>         the service called. I have not found any documentation that
>>         explains this. Could you suggest how to achieve this?
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160519/30aac30a/attachment-0001.html 


More information about the keycloak-dev mailing list