Keycloak 2.5.0.CR1 Released

We've released Keycloak 2.5.0.CR1 just in time for Christmas. This release mainly focuses on bug fixing and we've resolved an impressive 165 issues in this release! Due to Christmas holidays the final release won't be until early January.

Highlights of the release includes:

• User Storage SPI - We've removed the old User Federation SPI in this release. If you have custom user federation providers you will need to migrate them to the User Storage SPI.
• HMAC Key Provider - We've added a secret key provider to be able to do HMAC signatures. These are faster than RSA signatures and are used for signing cookies.
• Ability to disable Impersonation - If you don't want to allow admins to be able to impersonate users you can now fully disable this feature.

This is the second to last release in the Keycloak 2 series. Expect one more round of bug fixing and a 2.5.1.Final release towards the end of January. After that we'll get started on Keycloak 3!

Plans for Keycloak 3 are not finalized, but some things we're hoping to do next year include:

• Multi data center support - It's kinda possible at the moment, but we are planning to do a lot of improvements in this area
• Authentication SPI - We're aiming to cleanup the authentication SPI and may also be adding more built-in authentication capabilities
• Validation on Admin Endpoints and Console - There's currently a lack of validation on the admin endpoints which could result in bad configuration
• Profile SPI - Single configurable and extensible place to define validation for user validation for self-registration, account management and the admin console
• New Account Management - New modern and easier to use account management console
• Testing and CI - More automated testing, better test coverage and more Jenkins!

I'd like to wish everyone a merry christmas and a happy new year on behalf of the Keycloak team. We're looking forward to a adding loads more features and improvements to Keycloak in 2017!

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Considering removing Mongo from Keycloak

We are considering removing Mongo support from Keycloak in 3.x. The reasons behind it is that there are a fair few issues in the current implementation, especially around consistency due to lack of transaction support in Mongo and often we update multiple documents. In many cases we rely on transactions to rollback to prevent partial updates, but this obviously doesn't work in Mongo.

With the fact that Mongo is already partially broken and the constant maintenance involved we're considering removing it and rather focus purely on the relational database back-end.

Another point to make is that we are not considering supporting Mongo in the supported version of Keycloak (Red Hat Single Sign-On). So we are never able to provide the same level of care and attention to it as we can for relational databases.

If we do decide to remove it we would make sure we provide a seamless and easy option to migrate from Mongo to a relational database!

I would like to gather some feedback from the community before doing anything. So please vote on the following Doodle:

http://doodle.com/poll/nnimebpkx774ppus

Also, comments on this post is more than welcome!

I'll end with a comment - Time spent by core developer on maintaining Mongo could be better spent on awesome new features, testing and bug fixing!

Keycloak 2.4.0.Final Released

Keycloak 2.4.0.Final has just been released.

There are no changes since 2.4.0.CR1. To download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Keycloak 2.4.0.CR1 Released

We've just released Keycloak 2.4.0.CR1. This release is mainly a maintenance release and we've done a lot of minor improvements and bug fixes.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Registering new clients from shell

Keycloak comes with a powerful web admin console that is a primary tool for configuring everything in Keycloak. As powerful as it is it does not lend itself to scripting. Automation requires the ability to script the admin tasks, and to facilitate that we've been working on CLI tools that would be friendly for automation as well as interactive shell use.

The first of the CLI tools - Client Registration CLI - is now available as part of Keycloak distribution. It allows creating and updating new clients - operations you would otherwise have to do in Web Admin Console under Clients section.

Client Registration CLI can be used by application developers that integrate their applications with Keycloak server, and don't necessarily have administrative privileges on the server itself. That is possible by way of special client creation tokens called Initial Access Tokens that can be issued by realm administrator, and distributed to developers for them to self-service. In that case developer doesn't even need a user account, Initial Access Token is their means of authenticating to perform client creation operations.

The Client Registration CLI can also be used by applications and services to dynamically self-register themselves. This makes it possible to automate the creation and management of client configuration by applications and services themselves.

In theory such self-service can be performed by using generic tools like curl or wget, but in reality the mechanics of handling the tokens requires writing code or shell script and debugging it before it starts to work properly. Client Registration CLI takes care of all of that. It can maintain state between invocations, it can handle tokens for you, and it's very easy to use.

You can find the tool in your KEYCLOAK/bin directory - it's called kcreg.sh (or kcreg.bat on Windows).

Here's a little tour to give you a sense of what you can do with it.

Register an Initial Access Token received from admin

$ kcreg.sh config initial-token --server http://localhost:8080/auth --realm demo

You will be prompted for the token issued to you by realm admin. The token will be saved to default configuration file at ~/.keycloak/kcreg.config

Declare which server and realm to use by default

$ kcreg.sh config credentials --server http://localhost:8080/auth --realm demo

Any operation from now on will use the set server, and realm as default values.

Alternatively you can login as user with client management rights - admin for example:

$ kcreg.sh config credentials --server http://localhost:8180/auth --realm master --user admin --password admin --secret db2cd162-aa86-4154-a16e-a393c9db4f76

By default kcreg identifies to Keycloak server as client with clientId 'admin-cli'. It's a client automatically configured for every new realm to represent client tools like kcreg. We assume here that 'admin-cli' client has Access Type set to 'Confidential', and uses 'Client Id and Secret' for authentication. That's how we got the secret - from Credentials tab of Master realm's Clients section.

Create a new client configuration

$ kcreg.sh create -s clientId=app-profile-jsp -s protocol=openid-connect -s rootUrl=http://localhost:8080/app-profile-jsp

That is enough to create a new public client using a standard flow for authentication - one for static html5 applications.

Get client configuration

To see the configuration we just created we can use:

$ kcreg.sh get app-profile-jsp

Update client configuration

For this little tour we want to create a client for a dynamic web application hosted on a server, so we'll make the client `confidential`.

$ kcreg.sh update app-profile-jsp -s publicClient=false

Get Keycloak Adapter configuration file

Now we want to get a configuration file to put inside our packaged web application:

$ kcreg.sh get app-profile-jsp -e install > keycloak.json

We can now put keycloak.json in WEB-INF directory of our .war file.

Delete client configuration

We may not need some client configuration any more. We can easily delete it:

$ kcreg.sh delete app-profile-jsp


This was a very simple tour tailored to interactive use. Client Registration CLI also supports more complex usage.

For example, it's possible to perform one time authentication for individual command, that doesn't save any tokens into a config file:

$ kcreg.sh create --no-config -s clientId=app-profile-jsp -s protocol=openid-connect -s rootUrl=http://localhost:8080/app-profile-jsp -s publicClient=false --server http://localhost:8180/auth --realm master --user admin --password admin --secret db2cd162-aa86-4154-a16e-a393c9db4f76

All the kcreg commands accept additional options which you can learn about by using --help.

Client Registration CLI doesn't use Keycloak Admin REST, but rather a separate Client Registration REST service. It is thus limited in its scope, and tailored to the special use case of configuring new clients in a self-service manner.

Another more general Admin CLI tool is in the making that will use Keycloak Admin REST, and eventually allow all Web Admin Console operations to be performed through CLI.


Why not give Client Registration CLI a try, and let us know what you think.

Keycloak 2.3.0.Final Released

Keycloak 2.3.0.Final has just been released.

For the list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Keycloak 2.3.0.CR1 Released

We've just released Keycloak 2.3.0.CR1. This release brings a number of new existing features!

Highlights of the release includes:

• OpenID Connect certification - We've now completed the work on making our OpenID Connect implementation pass the OpenID Connect certification and we're currently passing all 5 profiles!
• User SPI - We now have a new simpler User SPI. This will make it easier to implement a custom user provider to pull in users from any external user store. In the next release we'll port our LDAP provider to this SPI, which will make it possible to pull in users from LDAP without syncing data to the Keycloak database. Once this work is completed we'll remove the old User Federation SPI.
• Realm Key Rotation - We now support multiple keys in a realm. This makes it possible to seamlessly rotate keys without any impact to applications and users.
• Client Registration CLI - A while back we added dynamic client registration capabilities, we've now created a CLI that makes it easy to register and update clients from the command-line.
• Dynamic Client Registration Policies - We've introduced a mechanism to control what clients can be dynamically created. This includes the ability to define policies to allow clients to register without the need to authenticate.
• Node.js Adapter - We've had a Node.js adapter a while, but we've now polished it a lot and made it a first class citizen.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 2.2.1.Final Released

Keycloak 2.2.1.Final has just been released. This release fixes an issue in the JavaScript adapter that was introduced in 2.2.0.Final, for more details see KEYCLOAK-3586.

To download the release go to the Keycloak homepage.

keycloak-server.json, RIP

All Keycloak Configuration in One Place

We have moved configuration of the Keycloak server from keycloak-server.json to standalone.xml, standalone-ha.xml, or domain.xml.  Which xml file you use will depend on how you run your server.  I'll reference standalone.xml from here on out, but configuration is the same for each file.

As of version 2.2.0, keycloak-server.json will no longer be shipped with Keycloak.  We do provide a conversion tool to help you make the switch.

So now, you can configure the entire server from a single xml file.  Keycloak server configuration is done in the same file where you configure data sources, socket bindings, logging, and clustering.

But there are other advantages...

Managing Keycloak with the Command Line Interface (CLI)

While you can still edit standalone.xml by hand just like you did with keycloak-server.json, you can now manage your configuration with the jboss-cli tool.  Whether you are managing a single Keycloak server or an entire domain of servers, you can use jboss-cli to configure Keycloak remotely.

But the best part about jboss-cli is scripting.  CLI commands can be run as a script for common configuration tasks.  This is all explained in the Keycloak documentation, complete with examples and recipes.

It's Clearer and Safer in XML

I don't want to start a flame war about config files in json vs. xml.  But for Keycloak configuration, XML is definitely a step forward.

First, your XML is validated via XML Schema along with a custom parser that understands exactly what Keycloak is expecting.  Keycloak won't boot if you have specified an invalid tag or value.  This was much less true when we used keycloak-server.json.  More bad data could get past the initial boot and cause problems later.

Second, our XML layout is much easier to understand than the old json.  Consider the old declaration for the realmCache provider:

Until I started on the "convert to standalone.xml" project, I didn't really know what the json fully meant.  From just looking at keycloak-server.json, it was hard to tell.

So here is what the json above actually means.  realmCache is the name of an SPI type.  Inside the realmCache declaration, you can specify a value for provider.  But that really means, "default provider name".  After that you can make zero or more provider declarations.  In this case, default is the name of a provider.  Inside the provider declaration, you can always specify if the provider is enabled.  At the same level as the enabled flag, you can also add other properties that only that particular provider understands.

Now consider the same declaration in its new XML format:
I think you'll agree, this is easier to understand.  It really doesn't need much explanation does it?

Conclusion

So like I said, all this is fully explained with lots of examples in the latest documentation.  And as always, feedback is much appreciated.

So long, and thanks for all the fish.

Stan

Keycloak 2.2.0.Final Released

Keycloak 2.2.0.Final has just been released.

For the list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Keycloak 2.2.0.CR1 Released

Keycloak 2.2.0.CR1 has just been released. The final release will follow next week if no major issues are reported. Few highlights of this release:

• OpenID Connect certification - We've continued to work on our OpenID Connect implementation and we're now passing the basic, implicit, hybrid and config profiles. We'll get the dynamic profile sorted in the 2.3 release.
• Server config moved to standalone/domain.xml - In the past some server configuration was done in keycloak-server.json and some in standalone/domain.xml. We've now moved all config to standalone/domain.xml and keycloak-server.json is now deprecated. This brings the option to use jboss-cli including offline scripts to automate configuration.
• Manual DB migration - We've had automatic migration of the database for a long time, but we now have an option to have Keycloak write a SQL migration file instead of applying the changes directly.
• Fuse adapter download - There is now a Fuse adapter download that makes it possible to install Keycloak support in Fuse without access to external Maven repository.
• Hot deployment of providers - It's now possible to hot deploy custom providers from within a JEE deployment. We've not had the chance to write documentation around this yet and it could do with a bit more testing so consider it a preview feature. Take a look at the user-storage-jpa provider example though, it's great stuff!
• Identity Provider Authenticator - In the past redirecting to identity providers was hardcoded in the Keycloak code, we've now refactored this into a new authenticator.
• Norwegian, Japanese and Lituanian translations - Keycloak now comes with 11 translations. 10 of them contributed and maintained by our excellent community.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 2.1.0.Final released

Keycloak 2.1.0.Final has just been released. This release only contains one fix related to Authorization services since 2.1.0.CR1 release.

For the list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Keycloak 2.1.0.CR1 released

Keycloak 2.1.0.CR1 has just been released. The final release will follow next week if no major issues are reported. Few highlights of this release:

• Password Policy SPI - Now it's possible to plug your own implementation of password policy. This is useful if available builtin policies are not sufficient for you.
• Jetty 9.3 adapter - Allow you to secure your applications deployed on Jetty 9.3 server.
• Authorization fixes & improvements - There are lots of fixes and improvements in authorization services, which were recently added in 2.0 release. It really worth to check this out and eventually provide us some feedback.
• Better OpenID Connect interoperability - There are lots of minor fixes related to OpenID Connect support.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Loading Providers and Themes from Maven Repository

Keycloak has a number of SPIs where you can provide your own providers to hook in custom behavior. The custom providers can be deployed by copying the JAR into the providers directory or it can be deployed as a module which provides greater control of the classpath for the provider.

Keycloak also has the ability to create themes to customize login pages and account management console. These can either be copied to the themes directory or they can also be deployed as modules.

In this post I'll show how you can load custom providers and themes from a Maven repository. This could either be from the local Maven repository or a remove Maven repository.

Loading providers and themes from a Maven repository can be useful for development and also as a distribution mechanism, especially when Keycloak is clustered and you want to make sure all nodes have the same providers and themes.

Before going through these examples make sure you have the Keycloak server installed. If you don't you can get it from keycloak.org. We'll refer to the directory where you have the Keycloak server as KEYCLOAK_HOME.

You also need to download the Keycloak examples as we'll use one of the example providers. You can get them from keycloak.org. Then extract the archive somewhere. We'll refer to the directory with the examples as EXAMPLES_HOME.

Deploying Provider as a Module

Before we load the example provider from Maven we'll first deploy it as a module. There's two reasons for this. Firstly, we'll make sure that we have everything configured correctly and that the provider is working as expected. Secondly, loading the provider from Maven is actually a feature of the JBoss Modules which is what provides the support for modules in the first place.

To deploy the provider go through the following steps: Stop the Keycloak server, then build and install the example provider with the following steps:

cd $EXAMPLES_HOME/providers/event-listener-sysout
mvn clean install
$KEYCLOAK_HOME/bin/jboss-cli.sh --command="module add \
 --name=org.keycloak.examples.event-sysout \
 --resources=target/event-listener-sysout-example.jar \
 --dependencies=org.keycloak.keycloak-core,org.keycloak.keycloak-server-spi"

This will create a module for the example provider. Next we need to configure Keycloak to load providers from the. Open $KEYCLOAK_HOME/standalone/configuration/keycloak-server.json in a text editor and update the providers section to:

"providers": [
    "classpath:${jboss.home.dir}/providers/*",
    "module:org.keycloak.examples.event-sysout"
],

Once you've done that start the Keycloak server and login to the Keycloak Admin Console. Select Events from the menu, then click on the Config tab. Remove the jboss-logging listener, add sysout and click on Save. The sysout event listener is the custom event listener provider we just deployed as a module.

To check that the provider is working as expected logout, then login again. You should see some events on the standard output from the Keycloak server:

10:52:01,844 INFO  [stdout] (default task-50) EVENT: type=LOGOUT..
10:52:04,792 INFO  [stdout] (default task-54) EVENT: type=LOGIN..
10:52:04,976 INFO  [stdout] (default task-57) EVENT: type=CODE_TO_TOKEN..

Loading Provider from the Local Maven Repository

Loading the provider from the local Maven Repository is very easy. In the previous steps we already built and installed the provider into the local Maven Repository so we just need to make the module use the Maven artifact instead of the JAR directly from the module.

First stop the Keycloak server. Then delete the file modules/org/keycloak/examples/event-sysout/main/event-listener-sysout-example.jar. Next open $KEYCLOAK_HOME/modules/org/keycloak/examples/event-sysout/main/module.xml in a text editor and change it to:

<?xml version="1.0" ?>

<module xmlns="urn:jboss:module:1.1" name="org.keycloak.examples.event-sysout">

    <resources>
        <artifact name="org.keycloak:event-listener-sysout-example:2.0.0.Final"/>
    </resources>

    <dependencies>
        <module name="org.keycloak.keycloak-core"/>
        <module name="org.keycloak.keycloak-server-spi"/>
    </dependencies>
</module>

Note: if you are not using version 2.0.0.Final of the examples remember to change the version.

You can now start the server again and try login. You'll hopefully see that the events are still being printed to standard out. As you deleted the JAR from the module directory the provider is now being loaded from the local Maven repository.

Loading Provider from a Remote Maven Repository

Let's start by creating a Nexus repository we can use to deploy the provider to. We'll use Docker and the official Sonatype Nexus image. You can obviously use any Maven Repository you want, but for the sake of completeness we'll include steps to setup the repository as well. Make sure you have Docker installed then run: docker run -d -p 8081:8081 sonatype/nexus After a while you'll have a Sonatype Nexus Maven Repository running at http://localhost:8081. You can login to this with username admin and password admin123. Now let's deploy the example provider to this repository. First edit the file .m2/settings.xml in your home directory and add the credentials for the Sonatype Nexus repository:

<settings>
    ...
    <servers>
        <server>
            <id>local-nexus</id>
            <username>admin</username>
            <password>admin123</password>
        </server>
    </servers>
</settings>

Then edit $EXAMPLES_HOME/providers/event-listener-sysout/pom.xml. Add a distributionManagement element:

<distributionManagement>
    <repository>
        <id>local-nexus</id>
        <name>Local Nexus</name>
        <url>http://localhost:8081/content/repositories/releases</url>
    </repository>
</distributionManagement>

Also, you need to enable the deploy plugin as it's been disabled in the parent POM:

<build>
    <finalName>event-listener-sysout-example</finalName>

    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <configuration>
                <skip>false</skip>
            </configuration>
        </plugin>
    </plugins>
</build>

Now you can run the following to deploy the provider to the repository:

mvn deploy

Check that it was indeed deployed by opening http://localhost:8081/content/repositories/releases/org/keycloak/event-listener-sysout-example/.

Stop Keycloak. To make sure the provider can indeed be retrieved from the remote Maven repository delete the directory .m2/repository/org/keycloak/event-listener-sysout-example. This will remove the provider from the local Maven repository. You can try to start the Keycloak server again, but you will get a warning. To enable the remote Maven repository start the Keycloak server with:

bin/standalone.sh \
 -Dremote.maven.repo=http://localhost:8081/content/repositories/releases

Keycloak should now start successfully and should download the provider from the remote Maven repository. It'll get cached in the local Maven repository so it won't have to retrieve it every time Keycloak is started.

IntelliJ IDEA Review

Everyone is different and everyone has a favorite IDE. On the Keycloak team you'll find someone that uses each of the major IDE's, Eclipse, Netbeans, and IntelliJ. We don't discriminate and let each person decide which they want to use rather than impose one IDE on everyone.

Both Eclipse and Netbeans are available free of charge and are open source, which is obviously ideal. IntelliJ IDEA usually has a license fee, but JetBrains have provided our team with a free-of-charge IntelliJ IDEA license in exchange for displaying a JetBrains logo on our project website and an objective review of the software in a blog post.

In the modern world of Java software development it's nearly impossible to get far enough with notepad and great memory. This programming language and all those popular frameworks have nowadays gone so far that every new Java software developer has to deal with choosing the right instrument which will help him all along on the harsh journey of Java development. He has to choose an IDE.

Today market is not very rich on the variety of Java development environments. The most popular of the existing ones are probably Netbeans, Eclipse (also some of it's derivatives, including Jboss Developer Studio) and IntelliJ IDEA, developed by JetBrains.

It should not be a surprise for the reader, that our team uses all of the mentioned IDEs. Many software developers, being quite a conservative folk, tend to quickly get used to a single instrument and are not willing enough to try the shiny other ones, being quite reasonable on the point that this adventure might just consume all of their precious time and give none positive result in return.

So, this is the reason why this article originally came out, to help anybody interested take a peek at the IDE which is getting more and more popular around our team. I am going to write about IntelliJ IDEA.

Different Bundles

IntelliJ IDEA is distributed in two different bundles - community edition and ultimate edition. It's not difficult to guess that first one is free to use with somewhat limited functionality, but it's license (Apache v2.0) allows it's users to work on commercial projects with this IDE, and even modify and extend IDEA in order to create a new commercial product on top of it.

Ultimate edition is meanwhile not free at all. To be honest it's price is not that low as to be affordable by an average student. There are a lot of different modules out there for ultimate edition which are not compatiable with community edition of IDEA. Among them are modules for Java EE and Spring integration, which, among other features, provide possibility to debug applications running inside application servers, nice injected beans navigation and many others.

At the same time JetBrans has created a vast amount of other products, which are developed on top of IDEA. Most well-known of them all are probably WebStorm (Javascript IDE) and PyCharm (Python IDE). There also exist IDEs for C++, ruby, iOS development and more. Recently JetBrains family received a new member called Datagrip. It is an IDE for RDB stored procedures and SQL development, which supports all the most popular databases. The thing which most distinguishes DataGrip from it's rivals is that DataGrip caches all the database schemas user needs during the first connection to the database, and after that provides reliable and fast autocompletion during the user's interaction with these schemas. Unfortunately, DataGrip does not have anything like community edition, it's a product one will have to buy. It provides 30-days trial period though, in case you would like to get familiar with it and see if you really need it.

It also should be said, that JetBrains provides free ultimate edition licenses for developers involved in opensource products. If you're one of those developers and want to get your ultimate edition license, you probably should get in touch with JetBrains and discuss this topic with them.

Look and feel

When I first started IDEA after a long time working with eclipse (please don't consider this being some sort of advertising, eclipse is a great opensource product!), I was very surprised, how fast IDEA was at doing all those little things developer needs from an IDE. That was the first time I believed that even desktop applications written in Java might be really competitive on the market.

When you first import or create a project in IDEA, it will cache a lot of different things related to it. IDEA will cache all the classes with there properties and methods, all project dependencies, annotations and all the other things needed to run the application. Maven dependencies will also be downloaded and added to project classpath.

Obviously, miracles never happen, so this pro has it's own con. Project import might take a really long time. For example, Keycloak import takes at least two cups of coffee. Fortunately this is not the task one has to do very often.

One more nice thing about IDEA is that this IDE is fully customizable. There are two color schemes out of the box, light theme for daylight Java development, and dark one, for midnight hacking. What is the most important, on the contrary to most other IDEs, which only allow users to change editor color, IDEA has a customizable interface. User can change everything, from window colors to fonts in settings area.

Of course, editor customizing is also available. More than that, user can set different color schema for every language he works with in IDEA. Every keyword type has it's own color setting, and every language has it's own color page in IDEA settings, fonts can be changed, and even font styles can be used for different language elements. For example, user can set class names to be bold and class static methods to be written in italic. This customization can actually save a lot of time while navigating code.

Usually software developer, working with code, prefers to restrain from using mouse and work with keyboard only. Thus, good IDE should provide as many keymaps, as possible, for different kinds of things. IDEA is doing a really great job here. User can choose from keybindings which come from Eclipse, Visual Studio, Netbeans, Emacs and even Vim (full Vim emulation can be installed with IdeaVim plugin). User can also create his or her own keybindings.

Plugins

IDEA supports loads of very different plugins. Some of them extend development environment with new languages, others with version control systems. There are plugins for different class hierarchies and diagrams, plugins for refactoring, there are ones, which provide highlighting for different configuration and markup files.

For example, I really fancy a Markdown support plugin, which provides source highlighting and markdown files preview. User can extend IDEA by adding Gerrit or Github plugins and Scala plugin, which provides Scala autocompletion, syntax highlighting, built-in SBT (Scala Build Tool) and REPL for testing code. Needless to say that in this case IDEA will adopt new run configurations, for Scala specifically, and new VCS menu with actions, usual for Gerrit and Github.

There are also plugins which introduce such languages as Groovy (with Gradle), Kotlin, Clojure (with Leiningen) and many others.

Every willing person can take part in community's life, develop plugins he or other people might need and distribute them to others. It should be mentioned though, that modules, which rely on ultimate edition functionality, will not be available in community edition IDEA. For example, not a single module which works with Java EE, can be installed in the free version of IDEA.

Maven Integration

Nowadays Java is tightly coupled with Maven. One can hardly find a Java project which is not built by maven. Both Spring boot and Java EE use maven dependency management a lot, and it's nearly impossible to develop a modern project without it.

Therefore, it's fortunate that JetBrains have done quite a big job on IDEA Maven integration. Maven is bundled with IDEA out of the box. Though the bundled version is quite old, it's easy to point IDEA towards Maven installation somewhere in the OS, if one needs the more modern one.

On Maven project import IDEA scan it for Maven modules and caches them afterwards. After that it downloads all the artifacts needed by the project to be built and run and puts them into this project's classpath. Both IDEA editions, community and ultimate, have a handy Maven tool, which makes it easier to manage lifecycle of the application. This instrument lists all maven modules available in the project with their goals, and also the full list of Maven profiles available to run those goals with.

It also should be mentioned that IDEA has quite a good autocompletion when dealing with Maven configurations. It can even suggest artifact version in maven repositories on filling dependencies of maven project, which often comes very handy.

IDEA also has nice support of Ant scripts, in case your projects are built with it instead of Maven.

Java EE and Spring Integration

Unfortunately, Java EE and Spring integration is only available to users of ultimate edition of IDEA.

And, while Spring heavily relies on it's maven dependencies, and is able to embed almost everything it needs into the application being developed, which makes Spring applications easily run even in community edition, Java EE is not anywhere that easy to cope with. Of course, user can start application server by hand, deploy Java EE application to it with maven or any other tool and setup debug flags to the application server, it's not easy and comfortable to do this all the time during application development. That's why if one works with Java EE a lot and has growing interest in IntelliJ IDEA, he might think about obtaining an ultimate edition license. This can save a lot of time and effort. Don't forget about the 30-days trial!

Meanwhile, there's nothing very much special about Java EE integration in IDEA. It's presumably the same thing as Java EE in eclipse, JBDS and others. Though, in my opinion, Java EE configuration in IDEA is one of the most comfortable of all the IDEs I've worked with, nobody spends more time configuring their tools than actually developing applications with them.

In IDEA settings user can setup multiple application servers, which have to be preinstalled into the system, with a little bit of configuration involved, usually default settings do the trick. After that user specifies application server in project settings, and that's it. It's now possible to start the AS, deploy application, debug, see logs and do all the other funny things related to application servers, all from the IDE.

Of course, IDEA also provides nice tools for navigation around the enterprise code. It's easy to see all the places bean is injected to, to find all the observers of the CDI event, etc. This works for both Java EE and Spring.

Conclusion

In my opinion, IDEA is one of the best development tools for the vast majority of programming languages on the modern market. It's fully customizable, it provides all the instruments I would ever like to see in the IDE, if not from scratch, then installed as a plugin. It's nice to work with, never lags or freezes, and always quickly responds to my thoughts and wishes. I don't have to wait for and IDE to remember what is in classpath, so I can switch my attention to software development instead of getting mad with instruments.

Meanwhile main disadvantage of IDEA is it's price, especially if you don't work with opensource and your employer refuses to pay for cool shiny toys. In this case it's going to be your decision, whether to spend money on the operating tool or not. Fortunately, community edition exists, and ultimate edition is always available for a 30-days trial period, so you at least have enough time to try it and decide if you really need it.

Keycloak 2.0.0.Final Released

Keycloak 2.0.0.Final has just been released. This release only contains some minor fixes since 2.0.0.CR1.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Keycloak 2.0.0.CR1 Released

We're finally back to adding new features. This release is just the beginning and we've planned loads of existing new features in the coming months.

I'm really exited to introduce the authorization services we've just added. Through the authorization services you can centrally define and manage fine-grained permissions for your services. For more details check out the Authorization Services Guide.

There's a brand new website at www.keycloak.org.

Finally we've also completely reworked and significantly improved our documentation.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. Before you upgrade refer to the migration guide

Productized and supported Keycloak now available from Red Hat

For nearly 4 years ago Bill Burke and myself started two individual proof of concepts, both focusing on making it easier for developers to securing applications and services. Keycloak was born out of combining these two proof of concepts. There was barely any overlap and the two perfectly complemented each other.

Fast forward to today and we now have a huge community with over 100 contributors and over 400 forks of our Github repository. It's no longer just myself and Bill working on Keycloak, we now have a strong team working on it and I'm very exited about the future of the project.

You may have noticed that lately we've stopped adding new features and focused on improvements and testing. There's a good reason behind that! We've been working on creating a productized and supported version of Keycloak.

I'm extremely pleased to announce that Red Hat now offers a productized and supported version of Keycloak!

For more details on how to get support for Keycloak check out the product pages at https://access.redhat.com/products/red-hat-single-sign-on.

Finally, I'd like to thank everyone that's been involved. All the core developers, quality engineers, others at Red Hat and last but not least our community!

Keycloak 1.9.8.Final Released

We're now shifting our focus from polish and testing to adding new features, so this will be the last 1.9.x community release. Who knows, maybe that means a product release is around the corner?

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.7.Final

Keycloak 1.9.7.Final has just been released.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.5.Final Released

Keycloak 1.9.5.Final has just been released. There's one change worth highlighting in this release. We've increased the default password hashing intervals to 20000. Yes, you read that right. We've actually recommended using 20000 for a while now, but the default was only 1. This is a clear trade-off between performance and how secure passwords are stored. With 1 password hashing interval it takes less than 1 ms to hash a password, while with 20000 it takes tens of ms.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.4.Final Released

We've just release 1.9.4.Final. This release only has two bug fixes, but comes with a fair bit more automated testing.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.3.Final Released

We've just release 1.9.3.Final. This release has a few bug fixes, but mainly we've focused on increasing test coverage for this release.

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.2.Final released

The team has done an awesome job this time around and we've spent the last few weeks polishing and fixing! With 141 issues resolved this release takes us one step closer to having a supported version of Keycloak. For the next release we will focus on extending our testsuite as well as improving documentation. If you haven't already upgraded to 1.9.x now is the time!

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.9.1.Final Released

For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage.

Commercial support

We're very pleased to announce that Red Hat is working on a commercially supported version of Keycloak. At the moment we can't give any details around product name, release date or subscription model. What we can tell you is that the supported version will be based on Keycloak 1.9.x.

Rather than working on new features we're currently focusing on performance, bug fixes and general polishing. We will be releasing minor releases of 1.9.x every few weeks going forward. This means that we highly recommend you upgrade to 1.9.x now. It will get continuous fixes, including security fixes, until the commercially supported version is ready. Going forwards we'll also be very unlikely to answer questions or help with problems unless you've upgraded to 1.9.x. We'd also appreciate all the review and feedback we can get on this release. We want to make it as good as possible.

Keycloak 1.9.0.Final Released

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Musing on JSON Web Tokens

I just got back from the DevNexus conference in Atlanta.  There, I attended several security-related talks.  One of them was on using JSON Web Tokens (JWT).  The presenter explained that JWT is "session cookies done right".

Afterward, I was discussing the talk with an old colleague I hadn't seen in years.  He seemed impressed and told about how this was just what he needed to secure some of his legacy REST endpoints.  I remarked that yes, JWT is good and we use it in Keycloak as part of our OpenID Connect implementation.  I also said that I thought it was a mistake to roll your own.  You wouldn't really do this yourself.  You would use a tool that manages the tokens for you.  He didn't seem convinced, and I didn't have a good coherent argument so I dropped the subject.

Then that evening there was another talk that mentioned JWT.  This presenter told us, no, JWT is bad.  He says, well, it's not really bad.  It's probably the best choice if you know what you are doing.  Then he proceeded to tell us about security problems in old versions of JWT libraries and how even with the latest code you might not get it right.

Though it wasn't really the focus of his talk, this guy seemed to be saying that the best solution is to "roll your own" token.

Uh, no.

But I wish my friend had seen that talk as well.  Now I had my answer for him.  Security is hard.  Use Keycloak or use some other product.  Just don't get cute and try to do JWT yourself.

Stan

Keycloak 1.8.1.Final and 1.9.0.CR1 released

Today we have two releases. As 1.8.0.Final was released before WildFly 10 Final was available, we decided to release 1.8.1.Final which is now built on top of WildFly 10 Final.

The bigger release today is 1.9.0.CR1, this release contains a large number of bug fixes and improvements, but no major new features.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.8.0.Final Released

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Internationalization (i18n) and Localization (l10n) of Keycloak

Keycloak's admin console needs to be fully localized.  That is, we need to replace all of our static English text and replace it with something that can display readable text in the user's local language.  I've done this sort of thing many times in Java, but our admin console is written in AngularJS, which is rather new to me.


So I set out to discover what i18n/l10n libraries might help.  I found three candidates.

angular-localization

angular-localization is a relatively new library written by Rahul Dashi.  I must say I was pretty impressed with this talk he gave at an AngularJS user group.

I also checked out the GitHub repo and documentation.  This was definitely in the running.  Worth a test-drive.

angular-translate

angular-translate is very similar to angular-localization.  angular-translate's founder and primary author is Pascal Precht.  "Pascal" is a phenomenal name for a programmer, so his library must be good.  But just to check, I did watch a talk, looked at GitHub, and the docs. This one would get a test-drive too.

angular-gettext

Among the three, angular-gettext wins the award for best web site.  But beyond that, I didn't like what I saw.  The approach is completely different from the first two.  You annotate your code and run it against a tool that tries to figure out where the static text is.  Then it uses the English text as keys to put into .po files for translation.  Magical!  But as any Harry Potter fan knows, while magic can be fun, it can also go horribly wrong.

The more I read about angular-gettext, the more it just didn't seem right for Keycloak.  I hate an over-reliance on tools.  I don't like forcing developers and translators to learn new tools either.  Plus, I don't think our translators ever use .po files.

Maybe I was punting on third down*, but I just couldn't justify spending more time on angular-gettext.

(*Note that "punt on third down" is an American football reference that that can not be localized to soccer. :-) ) 

angular-localization vs angular-translate

So it's down to two candidates.  To try these out, I created a simple app that localizes the Keycloak login page.  In Keycloak today, this page is already localized using Freemarker.   But for this exercise I just grabbed the raw HTML and created two AngularJS pages, one to test each library.  You can see the code or try it yourself.  I've uploaded the source to my GitHub account.

Here is how it looks with both libraries.  Both allow you to change languages with the press of a button:

So both libraries work, and the code I had to write for each is very similar.

Here is a simple translation for angular-localization:

 <label for="password">{{'password' | i18n}}</label>

Here is the same translation for angular-translate:

 <label for="password">{{'password' | translate}}</label>

Both let you do translations with directives or filters.  Both use JSON resource bundles for translation mapping.  Both let you parameterize your messages, and both have support for AngularJS features like pluralization and two-way binding.  Both meet Keycloak's requirements.

So which do we choose?

The maturity heuristic

There are indeed some technical differences between the two libraries.  And judging from what I've seen, angular-localization probably learned some things from its older, more mature cousin.  But therein lies the rub.  angular-translate is considerably more mature.

The great thing about open source is that I can assess this maturity.  It's quick and easy to look under the hood and see how far along a project really is.  You can see the frequency of commits.  You can see the diversity of the developers who have submitted pull requests.  And most important, you can see if the project is still "alive" with recent commits and releases.

In other words, you can assess the community.  Software is only as good as the company or community that stands behind it.  So in the end, the choice was pretty easy.  We went with angular-translate.

Keycloak 1.8.0.CR3 Released

A few more fixes, hopefully this will be the last CR and we can release Final next week.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.8.0.CR2 Released

We had a few issues reported against 1.8.0.CR1, so we're doing another CR release with the fixes. If everything is OK, 1.8.0.Final will be released next week.

There was also a feature that sneaked in. We now support sign-on with Microsoft Live.

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.

Keycloak 1.8.0.CR1 Released

Keycloak 1.8.0.CR1 has just been released. As usual we will follow with a final release next week as long as no major issues are reported.

• Default Admin User Removed - we no longer have a built in admin account, instead a new account has to be created initially from http://localhost:8080/auth or with the bin/add-user[sh|bat] script
• Client Templates - with the introduction of client templates it's now possible to share mappers and scope configuration between clients
• Partial Import - it's now possible to import users, clients, identity brokers and user federators from a json file into an existing realm
• Truststore SPI - we've introduced a Truststore SPI which provides a centralized place to manage the truststore for clients, email, user federation and identity brokering
• Password Hashing SPI - if you want to import existing users into Keycloak you can implement a password hashing provider so existing hashed passwords can be used (thanks to tsudo for the contribution)
• Identity Brokering Login Flow - this allows customizing the flow used when a user logs in through an identity broker
• SAML v2 Enhanced Client or Proxy Profile (ECP) - this SAML profile is useful for non-browser based clients (for example a desktop application)
• OAuth2 Token Introspection - the OAuth2 token introspection specification provides a standard way to obtain the active state of a token
• Conditional OTP - requiring OTP used to be either enabled or disabled for a realm, it's now possible to conditionally choose which users require OTP based on for example a role or a request header (thanks to thomasdarimont for the contribution)
• Realm Display Name - a display name has been added to realms, which makes it possible to set a human readable name to be shown on login screens, emails, etc.
• WildFly 10.0.0.CR5 - Keycloak is now built on top of WildFly 10.0.0.CR5. Deploying the server overlay to WildFly 9 is no longer supported

For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage.