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-Condi...
> - I can make a PR if this has a chance to get in.
>
> Cheers
> Thomas
>
>
> _______________________________________________
> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev