Why the provider prefix in username?
by Thomas Raehalme
Hi,
If I login to Keycloak using a federated identity such as Google, Keycloak
inserts a prefix "google." to my username.
Maybe I'm missing something, but isn't this kind of unnecessary when the
email address is already a unique property?
Best regards,
Thomas
9 years, 12 months
Two Factor Authentication via Email.
by Thomas Darimont
I'm currently working on a PR that provides "Two factor authentication via
email" https://issues.jboss.org/browse/KEYCLOAK-240.
My current implementation comes with a custom EmailCodeAuthenticator
that generates a short code String in the challenge(...) Method and
sends an email to the email address that is configured for the current user.
The user can then copy and paste the code into an input field, similar
to OTP codes are handled. If the user entered the wrong code, a new
email is sent to the user's email address.
The email code is saved as a user level credential.
I wonder whether this is the right approach or whether it would be better
to allow the user to regenerate the code on demand instead of
regenerating it every time?
For the former I'd have to provide a REST endpoint similar to what happens
for verifying an email
during registration - where should this be placed?
For sending the actual email I'm currently using a EmailSenderProvider,
however I think a EmailTemplateProvider might be more appropriate ;-)
May I simply add a method to the EmailTemplateProvider interface?
Btw. I think this would be a good base for having an SMS based 2nd factor
authenticator, as requested here:
https://issues.jboss.org/browse/KEYCLOAK-241
It would make sense to have the mobile phone number as a first-class user
attribute and showing it on the profile page by default instead of just
having it only in the data model.
Another point that comes to my mind is that I could make sense to specify
an email code policy in the same way OTP policies are supported. This could
then be used to differentiate between email
codes that are usually handled via copy&paste whereas codes
that come via SMS are usually typed in by hand and should therefore
be somewhat short ;-)
My current WIP can be found here:
https://github.com/thomasdarimont/keycloak/commits/issue/KEYCLOAK-240-2nd...
9 years, 12 months
Conditional OTP Authentication based on HTTP header or Role
by Thomas Darimont
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
9 years, 12 months
New truststore provider
by Marko Strukelj
The new truststore provider I’ve been working on for the last several
weeks has been merged to master.
It brings some changes in how to configure https connectivity between
Keycloak server and backend services like brokers, LDAP identity
providers, SMTP servers, and client applications for backchannel
events.
Previously it was possible to configure a truststore on HttpClient
provider using the following properties:
"connectionsHttpClient": {
"truststore": "path to your .jks file containing public
certificates you trust",
"truststorePassword': "password",
"hostname-verification-policy": "WILDCARD",
"disable-trust-manager": false
}
Not every outgoing connectivity used HttpClient provider though. LDAP
connectivity uses java’s internal LDAP JNDI factory implementation
that uses java.net.URLConnection, similarly connectivity to SMTP
servers via JavaMail API used java.net.URLConnection directly. These
would bypass HttpClient truststore configuration completely, and
default to JSSE configuration - that is whatever is configured at jvm
level using javax.net.ssl.trustStore system property or fallback to
cacerts file that comes with java.
By moving truststore configuration out of HttpClient provider it can
now be used by all these other facilities as well, and thus we truly
have a server-wide truststore configuration for our services.
The new truststore provider removes truststore and certificate
checking configuration from HttpClient provider. The above mentioned
configuration properties no longer have any effect. Instead, one has
to configure the truststore provider:
"truststore": {
"file": {
"file": "path to your .jks file containing public certificates
you trust",
"password": "password",
"hostname-verification-policy": "WILDCARD",
"disabled": false
}
}
If truststore provider is configured, it is used by HttpClient
provider and other services, if it is not configured (which is a
default - by missing entirely from keycloak-server.json file), or if
‘disabled’, then HttpClient provider will fallback to JSSE
configuration. Note that this is not the same as the removed
‘disable-trust-manager’ setting in HttpClient provider configuration,
which rather than falling back to JSSE, turns off certificate checking
itself - accepting any certificate including self-signed ones. By the
way - that’s something that should never be enabled in a production
system, but was the default configuration. This mode is now no longer
available - you can’t disable certificate checking any more, you can
only delegate it downwards to the JVM.
More docs on this is available in ‘truststore’ section of Server
Installation (https://github.com/keycloak/keycloak/blob/master/docbook/auth-server-docs...)
- marko
9 years, 12 months
Is keycloak Java 8 only now? Where is it documented?
by Vlastimil Elias
Hi,
I rebased my local Keycloak source codes to latest master yesterday, and
got compilation error in
org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
class, because of import of classes from java.util.function package.
Investigation shown me that these classes are available in Java 8+ only.
Does this mean that next version of Keycloak (1.8) is targeted to run on
Java 8 only?
Is this documented somewhere? Main readme at
https://github.com/keycloak/keycloak still states "Ensure you have JDK 7
(or newer)" in build section. And I was not able to find any other info
about required java version in user doc (eg Installation chapter).
And I also realized that Keycloak's parent pom file (and all subprojet
poms also) miss any information about target java version.
There was this definition in pom file a year ago, but looks like Stian
removed it 9 months ago:
<!-- maven-compiler-plugin -->
<maven.compiler.target>1.7</maven.compiler.target>
<maven.compiler.source>1.7</maven.compiler.source>
This brings a small problem when importing the project into Eclipse, as
it is not able to correctly set java version for the project.
But maybe there is some reason why this is not in the pom? (I can
imagine that adapters use lower java version than the Keycloak server)
Is it possible to clear this somehow, at least in the documentation?
Thanks
Vlastimil
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
10 years
1.8.0.CR1 release and remaining work
by Stian Thorgersen
All,
I want all remaining work to be completed by end of Friday, this includes
any features and bugs.
We'll start testing on Monday and aim to release on Wednesday by the latest.
10 years
