[keycloak-dev] Conditional OTP Authentication based on HTTP header or Role

[Bill Burke]

Whoops, ou already submitted a PR! :)

On 1/11/2016 12:39 PM, Bill Burke wrote:
> Thats cool!  Thanks.  Something we've been wanting to add.  If you 
> want to submit a PR we would welcome it.
>
> On 1/11/2016 9:58 AM, Thomas Darimont wrote:
>> Hello,
>>
>> since this was requested multiple times, I implemented a custom OTP 
>> Authenticator
>> that can conditionally show the OTP form over the weekend.
>>
>> You can find more details in the following JIRA issue:
>> https://issues.jboss.org/browse/KEYCLOAK-2040
>>
>> I build something along the lines based on keycloak 1.8 (already 
>> adapted this for Keycloak 1.7) which allows you to conditionally 
>> require OTP authentication - I can contribute that if desired.
>> The solution consists of a custom ConditionalOtpFormAuthenticator 
>> that extends the OTPFormAuthenticator which can be configured with 
>> some conditions via the admin interface.
>> The decision for whether or not to require OTP authentication can be 
>> made based on multiple conditions which are evaluated in the 
>> following order. The first matching condition determines the outcome.
>> The list of supported conditions include:
>> - User Attribute
>> - Role
>> - Request Header
>> - Configured Default
>> If no condition matches, the ConditionalOtpFormAuthenticator fallback 
>> is to require OTP authentication.
>>
>> User Attribute:
>> A User Attribute like otp_auth can be used to control OTP 
>> authentication on individual user level. The supported values are 
>> skip and force. If the value is set to skip then the OTP auth is 
>> skipped for the user, otherwise if the value is force then the OTP 
>> auth is enforced. The setting is ignored for any other value.
>>
>> Role:
>> A role can be used to control the OTP authentication. If the user has 
>> the specified role the OTP authentication is forced. Otherwise if no 
>> role is selected the setting is ignored.
>>
>> Request Header:
>> Request Headers are matched via regex Patterns and can be specified 
>> as a whitelist and blacklist. No OTP for Header specifies the pattern 
>> for which OTP authentication is not required. This can be used to 
>> specify trusted networks, e.g. via: X-Forwarded-Host: 
>> (1.2.3.4|1.2.3.5) where The IPs 1.2.3.4, 1.2.3.5 denote trusted 
>> machines. Force OTP for Header specifies the pattern for which OTP 
>> authentication is required. Whitelist entries take precedence before 
>> blacklist entries.
>>
>> Configured Default:
>> A default fall-though behavior can be specified to handle cases where 
>> all previous conditions did not lead to a conclusion. An OTP 
>> authentication is required in case no default is configured.
>>
>> The code can be found here 
>> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-2040-Conditional-OTP-Authentication 
>> - I can make a PR if this has a chance to get in.
>>
>> Cheers
>> Thomas
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160111/ed1f3ea4/attachment.html