Keycloak 1.1.Beta 1 Released: SAML, Clustering, Tomcat 7

Leave a comment

(Copied from Stian’s announcement) Pretty big feature release:
  • SAML 2.0 support.  Keycloak already supports OpenID Connect, but with this release we’re also introducing support for SAML 2.0.  We did this by pulling in and building on top of Picketlink’s SAML libraries.
  • Vastly improved clustering support.  We’ve also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We’ve also added support for nodes to dynamically register with Keycloak to receive for example logout notifications.
  • Adapter multi-tenancy support.  Thanks to Juraci Paixão Kröhling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It’s up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there’s a simple example that shows how to get started.
  • Tomcat 7 Adapter.  A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven’t had time to document, test and make it a supported adapter until now.
What’s next?
The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty.
For a complete list of all features and fixes for this release check out JIRA.
I’d like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don’t hesitate, it’s easy to get started and we’re here to help if you need any pointers.

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 http://keycloak.org 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 Beta 4 Released

2 Comments

After a summer of multiple vacations from various team members, we’re finally ready to release Keycloak 1.0 Beta 4.  There’s not a lot of new features in the release because we focused mainly on performance, creating new SPIs, refactoring code, improving usability, and lastly fixing bugs. 64 issues completed.  As usually go to the main keycloak.org page to find download links and to browse our documentation, release notes, or view our screencast tutorials.  Here are some of the highlights of the release:

  • Server side memory cache for all UI pages.
  • Cache-control settings for UI pages
  • Server side cache for all backend metadata: realms, applications, and users.
  • In-memory implementation for user sessions
  • New Federation SPI.  Gives you a lot of flexibility to federation external stores into Keycloak
  • Improved LDAP/Active Directory support
  • Token validation REST API
  • Support for HttpServletRequest.logout()
  • Lots and lots of bugs fixes and minor improvements

You should see a big performance increase with this release as everything is cachable in memory and the database can be fully bypassed.

1.0 Final is on the way!

What’s next for Keycloak?  This month we will be focusing on resolving the remaining issues logged in Jira, improving our test coverage, and updating our documentation and screencasts.  No new major features.  We’ll have a RC release around 3rd week of August, then our first Final release 2nd week of September!

 

Resteasy 3.0.7.Final Released

Leave a comment

Ron fixed a few bugs in validation. Netty improvements. A few other bug fixes here and there.

As usual, follow links from jboss.org/resteasy to download and view documentation and release notes.

April talk on Keycloak

1 Comment

I’ll be doing a talk on Keycloak April 17th at Devnation in San Francisco.  Devnation is running the same time as Red Hat summit and JUDCon.  I should be around earlier in the week too.  For those that suffer through all my “errs” and “uhms”, I’ll be giving away 2 copies of RESTful Java with JAX-RS 2.0.  Hopefully that’s enough of a bribe to come and listen!  If anybody wants to talk Resteasy or Keycloak earlier in the week, ping me on the keycloak-dev list.

Keycloak SSO Released – Alpha 1

5 Comments

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.

Resteasy 3.0-RC-1 Release – Test drive before Final!

Leave a comment

Resteasy 3.0-RC1 has been released today.  We are fully TCK compliant now, just need to have Wildfly support HTTP DIGEST auth, then we can officially certify.  RC1 will have a 1 week lifetime and we’ll be doing a 3.0.Final release next week.  So, *LAST CHANCE TO SUBMIT BUGS!*.

Go to: http://jboss.org/resteasy to find the docs and downloads links.

Open Source’s Talent Advantage

1 Comment

Was reading an article on TheStreet.com 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.

Creating a JBoss Modules zip

Leave a comment

I’ve extracted some of the build files from AS7 to create a maven project that can create a modules/ directory structure for Resteasy.  I wanted this so that people can easily patch/upgrade AS7 to the latest resteasy release.  It should be fairly easy to use the project as an archetype if you want to do it for other things.

Improved HornetQ Spring Integration

6 Comments

I’ve been doing some work on HornetQ SVN trunk to improve the embeddable HornetQ experience (you’ll see these improvements in the next HornetQ release).  You can disagree with me, but I thought that embedding HornetQ was a bit verbose, especially for JMS, so first of all, I wrote two wrapper classes to make this easier.  While these classes will be in the next release along with a full docbook explanation, here’s what configuring JMS looks like now:

import org.hornetq.jms.server.embedded.EmbeddedJMS;

...
EmbeddedJMS jms = new EmbeddedJMS();
jms.start();

This class will look for hornetq-configuration.xml, hornetq-jms.xml, and hornetq-users.xml within your classpath.  It also has the option of manually creating configuration objects via pojo instantiation if you desire (or if you want to wire it with Spring for instance).

Simple Spring Integration

Another thing I did was to provide some simple Spring integration with the HornetQ JMS implementation.  I wrote a simple class that extends EmbeddedJMS that will register any configured queues, topics, and ConnectionFactorys direction within the Spring application context so that other beans can reference them.  Here’s an example of bootstrapping HornetQ JMS and referencing a queue within a Spring message listener container.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

   <bean id="EmbeddedJms" 
                class="org.hornetq.integration.spring.SpringJmsBootstrap" 
                init-method="start" destroy-method="stop"/>

   <bean id="listener"
             class="org.hornetq.tests.integration.spring.ExampleListener"/>

   <bean id="listenerContainer"
             class="org.springframework.jms.listener.DefaultMessageListenerContainer">
      <property name="connectionFactory" ref="ConnectionFactory"/>
      <property name="destination" ref="/queue/exampleQueue"/>
      <property name="messageListener" ref="listener"/>
   </bean>

</beans>

Again, this assumes you have configured HornetQ properly within HornetQ specific configuration files.  You can also manually declare HornetQ config objects within Spring and inject them into the EmbeddedJMS bean instance too if you don’t want to use HornetQ config files.

Right now, the code does not also register HornetQ objects within JNDI.  Do you think I should add this capability?  Anyways, I hope you’ll find this HornetQ + Spring integration useful in the next HornetQ release.

Older Entries