Keycloak 1.0 Final Released

1 Comment

After 1 year of hard work, the team is proud to release our first final 1.0 release of Keycloak.  We’ve stabilized our database schemas, improved performance, and refactored our SPIs and you should be good to go!  I don’t want to list all the features, but check out our project website at for more information.  You can find our download links there as well as screen cast tutorials on our documentation page.

What’s Next?

Keycloak 1.1 will be our integration release where we start bringing Keycloak to different protocols, projects, and environments.  Here’s a priority list of what we’re tackling

  • SAML 2.0 – by merging with Picketlink IDP
  • Uberfire/BRMS adapter
  • Fuse FSW adapter
  • EAP 6.x and Wildfly console integration
  • Tomcat 7 adapter
  • …More planned, but we’ll see how fast we can move before we announce anymore

In parallel, we hope to look into a few new features:

  • Internationalization
  • TOTP Improvements like allowing multiple token generators
  • IP Filtering

Keycloak 1.0 RC 1 Released

Leave a comment

Many bugs fixes and cleanup.  Not much for features although we did add a ton of tooltips to the admin console.  We’re getting very close to a final release and are still on schedule to release 2nd week on September.

See for links to download and documentation.

Keycloak Beta-1 Released!

1 Comment

Keycloak Beta-1 has been released!  We’re edging closer to 1.0! Please visit the Keycloak website for links to documentation and downloads.  A lot of hard work the last few months by Stian, Marek, myself and other contributors to bring you loads of new features and improvements:

  • LDAP/Active Directory integration built on Picketlink.  Thanks Marek!
  • User Session management – can now view login IP address and which applications and oauth clients have open tokens.  Works with any type of app too.  Can view and manage sessions through user account pages or admin console
  • Audit log for important events.  Integration with admin console and ability to receive emails on certain events.
  • Account log viewable in user account management pages
  • Export database.  Allows you to export a full dump of keycloak database into an encrypted file.  Will help out tremendously to migrate between Keycloak versions.
  • Authentication SPI.  Allows you to plug in different mechanisms to retrieve and authenticate users.
  • Theme support for the admin console and any sent email.
  • Per-realm admin console.  You can now designate a user within a realm that is an admin of that realm.
  • Documented the Admin REST API finally.  (Docs still kinda suck here)
  • CORS support for Admin REST API
  • Improvements in Javascript adapter.  Including OpenID Connect session iframe style for single-sign out and support for Cordova.
  • Support for relative URLs when configuring admin console
  • Server configuration file
  • Social Only Logins
  • Installed application adapter
  • Expanded the number of example projects

What’s next? This is the last major feature release of Keycloak.  We will now be focusing on performance, clustering, security audits, testing, documentation, and usability for the next few releases.  We hope to release 1.0 Final sometime in July.


Keycloak SSO Released – Alpha 1


Keycloak is an SSO authentication server and appliance for securing web applications and RESTful web services.  After 7 months of hard work, the Keycloak team (Bill Burke, Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz) is proud to announce our first release, Alpha-1!  There’s still a lot to do, but there’s a lot you of features you can try out.  Besides written documentation, we’ve put together a bunch of video screencasts that you can view to learn and experience the features of Keycloak.

These are some of the core feature of Keycloak:

  • SSO and Single Log Out for browser applications
  • Social Broker. Enable Google, Facebook, Yahoo, Twitter social login with no code required.
  • Openshift Quick Start so you can deploy Keycloak on the cloud
  • Optional User Registration
  • Password and TOTP support (via Google Authenticator). Client cert auth coming soon.
  • Forgot password management
  • OAuth Bearer token auth for REST Services
  • Integrated Browser App to REST Service token propagation
  • OAuth Bearer token auth for REST Services
  • OAuth 2.0 Grant requests
  • CORS Support
  • CORS Web Origin management and validation
  • Completely centrally managed user and role mapping metadata. Minimal configuration at the application side
  • Admin Console for managing users, roles, role mappings, applications, user sessions, allowed CORS web origins, and OAuth clients.
  • Deployable as a WAR, appliance, or on Openshift.
  • Supports JBoss AS7, EAP 6.x, and Wildfly applications. Plans to support Node.js, RAILS, GRAILS, and other non-Java application

Go to the Keycloak website and follow the links to download, view documentation and videos, browse our source code, and submit bugs.

What’s Next?
As I said before, there’s still a lot to do, but here’s some things that will get in sooner rather than later:
  • Stan Silvert has written a Wildfly subsystem for Keycloak that didn’t get into the Alpha 1 release.  When we get this in, it will be super easy to secure web applications within a Wildfly environment.  You won’t have to crack open your WARs to add Keycloak configuration and enabling Keycloak security may be as easy as a doing a few clicks in the admin console.
  • Storage protection.  We’ll be adding support for more secure password hashing as well as storage encryption capabilities for the Keycloak database.  Its uber important to be able to have a 2nd level of defense for hacks.
  • Revocation policies. We need to be able to expire all tokens just in case somebody gets hacked and broadcast this information to deployed applications.
  • User session management.  This will allow you to view which users are logged in and give you the ability to log out one or more users.
  • Composite roles.  This will be the concept of a role group.  This will make it easier to change role mappings for a large set of users.

Thank You!

Finally, I want to give a huge thank you to everybody that helped make this release possible (Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz).  Especially Stian for being such a great co-lead and Gabriel for doing such awesome design work.  This has been the best team I’ve been on since the good old JBoss Group days years and years ago, pre-aquisition when JBoss was young.

Open Source’s Talent Advantage

1 Comment

Was reading an article on about Why Wall Street Hates Open Source.  I think one of the things that business people often don’t know about is the talent advantage open source companies have.  Answer this question:  What are our hiring practices?  How do we hire people?

We know they can do the job

Most of the developers that come to the JBoss division of Red Hat were/are contributors to at least one of our open source projects.   Think about that for a second…Before we start paying somebody a dime, we’ve worked with our potential new employees months, sometimes years at a time.  We know what they are capable of.  We know the quality of their work.

We can hire anybody anywhere

The world is our labor market.  We can hire anybody anywhere without having to move them because we already have distributed development model.  A development model that our employee has already participated in.

Our developers have initiative and are self-motivated

Open source developers are uncommon.  Why?  It takes initiative, and lots of it.  You have to have the gumption to download the code and figure out how to build it.  Then you have to have the skills to be able to understand and dive into somebody else’s code so you can add your pet feature or fix a bug that is holding you up.  You have to go beyond the scope of your job description and learn something new.  When we hire a contributor, we know we have somebody that isn’t afraid to take initiative and drive things on their own.

Our developers already know our products

In my experience, the vast majority of our contributors are actually users of our products.  They’ve come to help, because they are missing a feature or bug that hinders the progress of the work they are being paid to do.  They know our products, but more importantly, they know what’s wrong with our products and what they don’t like about our products.

Our developers enjoy what they do

Core contributors often contribute during their free time.  People aren’t willing to give up free time if they don’t a) enjoy what they are doing, b) don’t like our products.

Our developers are part of a movement

Richard Stallman aside, open source is not socialism, yet it is a movement.  A movement most developers are proud to be part of.

Anyways, this is one of the many reasons I think Red Hat is built to last.

Mocks are a Mockery


There were some interesting side conversations going on in the comments of my Java EE wins over Spring blog.  In particular, a few people were arguing over the value of Mocks.  I always considered Mocks a bogus pattern.  Only time I ever use them is when I’m initially starting a project and I don’t have full implementations of a particular subsystem and I need to test that something works.  You see to me, your GIT master branch, or your SVN trunk is a sacred place.  I fully believe in the idea of continuous integration.  But to have a pure Trunk, you have to test your code, as close as possible, to the target environment it is supposed to run in.  Mocks go counter to this idea.  And give you false sense of security.

My colleague, Stan Silvert said it best:

When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.

What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.

The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.

I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.

Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.

Personally, I’m a very paranoid person when it comes to development.  Earlier in my career I did a lot of demos and live coding in front of an audience.  When you’re in this type of environment you live by the mantra that anything that can go wrong will.  So, when rehearsing, you always mimic as much as possible what your setup will be.  I carried this paranoia to Iona (an Irish company), when I worked on Orbix there.  We had a rule, that if even one test (integration or whatever) failed, you were awarded the Guiness Penalty.  If you broke the build, you had to buy every one on the team a pint of Guiness.  IN this environment, Mocks are a waste of time, both in build CPU and in coding time as you still had to run integration testing before you committed anything (unless of course you just wanted an excuse to have a few beers).

So unless a particular integration test is ungodly slow, don’t use mocks.  Stan again, said it best:

…the days of the 2 hour in-container smoke test are over.
Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.

But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.

With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore.

Apache damaging to Open Source


I just read an interesting blog by Savio questioning the value of LGPL.  IMO, he has something right, the OSS license chosen for a project is not that important as far as adoption or business goes.  The most important driver for OSS is and always has been the brand of the project.  Like their commercial counterparts, how the project is perceived by consumers is what drives both adoption and business.  So, I agree, LGPL doesn’t add a lot of value.  But, it goes both ways, the Apache license is also not that important either.

If you boil it down, the distinctions betwen GPL, LGPL, and ASL are pretty much meanlingless to most consumers of OSS.  How so?

1. The viral nature of GNU bases licenses is only triggered when binaries are distributed.  Most consumers of open source do not distribute software publicly.

2. LGPL is also not an issue for ISVs as long as they leave the binary as-is.  Its viral nature is triggered when the project is both modified and distributed.

So, when you take these two points together, the number of people affected by the differences between GPL, LGPL, and ASL become fewer and fewer.  GPL does not affect > 90% of OSS consumers.  For LGPL, the number of people actually affected by the license becomes a number that you can probably count on one hand.  The ones affected are the ones who actually want to use derivatives of the project within their own competing initiatives that are not LGPL-based.   So, do you see how meaningless it truly is?

Why making these distinctions is damanging

This all brings me to my final point.  The whole push by and its minions that ASL is the one true license is just damaging to open source.  When you consider the handful of individuals affected, you got to question the motivation for it, especially when you match it up to LGPL.  The thing is though, highlighting the differences only helps those handful of people that have selfish motives and/or want to exploit OSS for commercial gain.  Believe me I’ve lived this.

Back in 2003, a group of JBoss contributors tried to fork both the JBoss code base and the JBoss business.  IMO, their motives were mostly financial.  They wanted a bigger piece of the pie that Marc Fleury was unwilling to give up.  Whether or not they were right to do this is besides the point, there are good arguments on both sides, and whats done is done.  They initially derived themselves from the JBoss codebase, went to Apache, and thus Geronimo was born.  We complained that their derivation was both a copyright and LGPL violation.  In the end, they started over from scratch (don’t think the LGPL had value for JBossians back then?  think again!).  When Geronimo 1.0 came out, their feature set was vastly inferior to JBoss so their push was that it was the only Java EE implementation that was ASL.  That LGPL was scary and the only way to get over the fear was to use ASL-based projects.  IBM got into the act when they purchased Gluecode (and all the Geronimo developers) and embraced Geronimo as their children’s edition of Websphere.  Again, the main push was that Geronimo was ASL based.

We then come full circle to 2010 with history repeating itself (well, sort of).  You have Tom Bayerns leaving Red hat for Alfresco to create a competing BPM engine.  Now, I consider Tom a friend, and I completely understand his reasons for leaving Red Hat.  That being said, launching a new open source BPM engine with the premise being “we want to create something in ASL because it is better for our business”, is not the way to go about it.  Again, it smacks all over of having nothing but the zero-add of the ASL distinction.  And, is just completely irresponsible.

If you are an Apache guy, you should be appalled by behavior like this when it happens.  Individuals and companies that use ASL as a weapon to further their own selfish and commercial needs should be castigated and called out instead of championed as the reason why ASL is so cool and LGPL is so bad.  Respect the choice of other open source developers, propagating the myth that an ASL project is superior to a LGPL project because of license distinctions does nothing but hurt the open source movement as a whole.  We need to stop eating our own.

Finally, I just don’t want to bash on Apache and ASL.  Joining the GPL revolution isn’t so hot either.  The fear of GPL virality is used extensively in the dual-licensing ploy of commercial interests.  Think MySQL.  For me, I would never pick GPL, because I believe in the freedom of letting ISVs distribute my stuff as-is.  As for LGPL vs. ASL?  I could care less, it really doesn’t matter.  You don’t see JBoss caring so much either.  Drools is still ASL as well as a number of other projects.

Anyways, have fun with this, and remember taking any one position to seriously is unhealthy.

dm to Eclipse: Does it really matter?


I was just reading on Adrian Coyler’s blog that Spring’s dm Server is moving to  Cutting through all the blah blah blah, this is what I came up with as the reason for this move:

“At SpringSource we know that open source development and community involvement can play a huge role in evolving simple, pragmatic solutions that enable a technology to bridge from early adopter to mainstream usage. We know because it is a path we have successfully taken many times. In creating the Virgo project at, we seek to accelerate the journey of the dm Server and of enterprise OSGi along this path.”

What I extrapolate from this is that they want to accelerate adoption.  I have a simple fundamental question:

Does it really matter if you host your project at an OSS organization like or Apache?

I’ve been living in the Java OSS community for about 9 years now.  IMO, based on my experiences with JBoss, the only thing that or Apache really gives you is an established brand to promote your project.  I’ve always felt that a move to Apache or Eclipse, while may be beneficial in the short run with a bump in your adoption curve, in the long run it is bad for both your project and ultimately your business.  Why?  Because you lose control of both your brand and the governance of your project.  Brands cost money and time to build.  Governance introduces the inefficiencies of any bureaucracy (see my previous blogs on problems at  So, with both of those disadvantages, I question the advantages of moving dmServer to  JBoss has never had a problem starting a new project and building new communities on our own.  Neither has Spring for that matter.  Our brands are strong enough so that we don’t need the bump of an Apache or Eclipse to drive adoption.

The only real benefit I see to move to Eclipse or Apache is if you’re trying to build a consortium of companies that build off of a base core technology.  I really don’t see that happening with dmServer, even if that is there goal.  I know we wouldn’t use the technology.  Would Oracle?  IBM?  SpringSource is no longer the little guy.  VMWare is a serious competitor to all of us.

Standardization more important

IMO, a better route to grow adoption is standardization.  Hibernate got a huge bump in adoption by aligning itself under the JPA banner and EE 5.  We are seeing the same with Seam->CDI->Weld and Bean Validation.  Standardization drives adoption because it frees competing companies from having to depend on a competitor’s code base.  Since the APIs are public, vendors can provide their own implementations and value add on their own terms.  At the same time, standardization gives an easier entry point for vendors that want to enter into the space and gives users the peace of mind that they have less vendor lock-in.  Just because something is open source doesn’t mean that it is immune to lock-in.  The lock-in here is to the implementation.  Standardization breeds multiple implementations.

With dmServer, yeah, it is built upon the OSGi specification (and OSGi implementations), but that is just not the same.  You have to bring your innovations to a standards body to create the ecosystem.

What do you think?

So please help me optimize my personal algorithm for professional open source.  Do you think it really matter if you bring your project to an established organization if you yourself are already established?  I say no…

We’re listening: REST-*.org changes

1 Comment

Message Change

  • It is now an open source project.
  • We will be publishing the final content on IETF as a set of RFCs.
  • We’re still focusing on middleware and middleware services.

“REST-* is an open source project dedicated to bringing the architecture
of the web to traditional middleware services.”

“REST has a the potential to re-define how application developers
interact with traditional middleware services. The REST-* community
aims to re-examine which of these traditional services fits within the
REST model by defining new standards, guidelines, and specifications.
Where appropriate, any end product will be published at the IETF.”

Governance Changes

  • *No more trying to be a better JCP. We’ll let the IETF RFC process govern us when we’re ready to submit something.
  • An open source contributor agreement similar to what Apache, Eclipse, or JBoss has to protect users and contributors.

(FYI we already required ASL, open source processes, NO-field-of-use
restrictions, etc…)

If you have any other suggestions, let me know:

RESTful Interfaces for Un-RESTful Services

Many traditional middleware services do not fit into the RESTful style
of development. An example is 2PC transaction management. Still, these
services can benefit from having their distributed interface defined
RESTfully. The nomenclature will be RESTful Service vs. RESTful Interface.

  • 2PC transactions would be considered a RESTful interface under REST-*.org. Meaning using it makes your stuff less-RESTful, but at least the service has a restful interface.
  • Messaging, compensations, and workflow services would be considered “RESTful Services” that fit in the model.

Guidelines Section

This is where I want to talk about how existing patterns, RFC’s and such
fit in with the rest of what we’re doing. An example here could be
Security. What authentication models are good when? When should you
use OAuth and OpenID? How could something like OAuth interact with
middleware services?

Some of this stuff is already up on the website. (You may have to reload
it to see it due to cache-control policies.)

Finally, apologies for the redirection. We don’t want is as a project.  It was meant to be a separate entity.  It is a problem with
our infrastructure.

Yet another reason to avoid


I find  it strange how allows for competing projects as they don’t really position themselves as a Sourceforge or Google Code.  I know I’m pretty stupid for creating buzz about a competitor, but IBM and HP have launched a new JAX-RS effort at  The thing is, the Apache CXF project already has a pretty good certified JAX-RS implementation.  If I were Sergey or Dan I’d be pretty pissed.  This just solidifies my opinion that is a horrible place to host an open source project or to build start an open source business.

Not only do you have to worry about some Apache bureaucrat pulling rank on you or disallowing you to commit too much work to a project, you also have to worry about sharing your already diluted brand with a  competing project.  With a competing project the “Apache” in front of your project’s name ceases to add any value to the uniqueness of your project.

BTW, I don’t mean to pick on IBM and HP.  I’m just annoyed at  While it may be a great place for big vendors to collaborate at a neutral site, is just a horrible place for the little people of the world.

I also shouldn’t pick on so much.  They are a good organization with a good message and good ideals.  I just want to encourage future OSS developers to try and go at things on their own.  Learn to promote their project on their own without relying on the Apache brand.  Its better for them in the long run.

Older Entries

%d bloggers like this: