Keycloak 1.0 Final Released

September 10, 2014

billburke java, javaee, JAX-RS, jboss, Keycloak, oauth, openid connect, opensource, REST, security, SSO 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 1.0 RC 1 Released

August 20, 2014

billburke java, javaee, JAX-RS, Keycloak, oauth, openid connect, opensource, REST, RESTEasy, security, SSO 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 keycloak.org for links to download and documentation.

Keycloak Beta 4 Released

August 6, 2014

billburke java, JAX-RS, jboss, Keycloak, oauth, openid connect, REST, security, SSO, wildfly 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!

 

Keycloak Beta 3 Released

June 19, 2014

billburke Keycloak, oauth, openid connect, security Leave a comment

Mostly a bunch of bug fixes that we needed to push out for users.  We’re still pretty focused on performance and hope that Beta 4 will allow Keycloak to run in a cluster with some caching capabilities.  See keycloak.org for links on downloading, docs, and jira release notes.

Keycloak Beta-1 Released!

May 29, 2014

billburke java, JAX-RS, Keycloak, oauth, openid connect, opensource, REST, security, SSO 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 Alpha 3 Released

March 12, 2014

billburke Keycloak, oauth, openid connect, security, SSO Leave a comment

Another big feature release for Keycloak.  As usual, go to keycloak.org to find documentation and download links.  Here are the highlights of Alpha 3:

  • Minimal support for OpenID Connect.  Claims like email, full name, etc. can now be transmitted and viewed with IDToken passed after login.
  • Configurable allowed claims.  What identity claims are made in id and access tokens can be configured per application or oauth client within the admin console
  • Remote logout and session stats available from management console
  • Refresh token support
  • Not before revocation policy.  You can set it per realm, oauth client, or application.  Policies are pushed to applications that have an admin url
  • Fine grain admin console permissions and roles.  You can now specify which realms a master user is allowed to create, view, or edit.  An awesome side effect of this is that if you enable registration in the master admin realm and set a default global role of create only, keycloak can become a SaaS for SSO.
  • Installed Application feature to support non-browser applications that want to use Keycloak
  • You can now add social network links through account management

What’s next?

Our next release will be Beta-1 and will be our last big feature release.  One of the features we want to add is support for using an existing LDAP/Active Directory server.  We’re going to take a look at Picketlink IDM API for this.  We also need more fine grain support for importing and exporting various pieces of the keycloak database.  That’s minimally what we want to get in.  We’re looking at a May timeframe for this release as in April many of us will be busy with Red Hat Summit.

Keycloak SSO Released – Alpha 1

January 23, 2014

billburke jboss, Keycloak, opensource, REST, security, SSO, wildfly 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.

New Keycloak Project: SSO for Browser, Social, and REST Services

December 3, 2013

billburke security 4 Comments

I’d like to officially announce the new project I’m co-leading with Stian Thorgersen: Keycloak!  Some of you may already have heard hints about this on the Resteasy dev list, but since July I’ve been working with some great Red Hat guys (Stian, Gabriel, Villiam, Bolek, Alexandre, and Marek) to put together an SSO solution for browser, social, and REST service applications.  There is no release yet!  But we’re getting close to releasing our first Alpha.

Check out our screencast presentation and demo of what we got and what we’re doing:

Here’s a list of features we have or are planning to add over the coming months.

  • SSO and Single Log Out for browser applications
  • Social Broker.  Enable Google, Facebook, Yahoo, Twitter social login with no code required.
  • Optional User Registration
  • Password and TOTP support (via Google Authenticator).  Client cert auth coming soon.
  • OAuth Bearer token auth for REST Services
  • Integrated Browser App to REST Service token propagation
  • 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 an Openshift  cloud service (SaaS).
  • Supports JBoss AS7, EAP 6.x, and Wildfly applications.  Plans to support Node.js, RAILS, GRAILS, and other non-Java applications.

We would love to see anybody interested drop by on the keycloak-dev email list.  We looking to do our first alpha release sometime before Christmas.  The code was taken from the RESTEasy OAuth work I did earlier this year as well as the social broker service Stian Thorgersen and the portal team were prototyping early this year.  We’re also trying to leverage Picketlink where appropriate.

Scoping out Resteasy Skeleton Key Security

November 21, 2012

billburke REST, RESTEasy, security Leave a comment

I’ve been heavily prototyping a security solution for Resteasy code named Resteasy Skeleton Key. The solution has the following requirements:

  • Central auth server
  • Works with browsers.
  • Works with machine clients (code).
  • Single sign-on solution for simple web apps
  • Granting permission to third-parties to access your resources.
  • Maps well to the role-based security model of Java EE
  • Optional client certificate support for increased security
  • Supports SOA.  Distributed applications that have complex interactions between different services.
  • Cloud-ready authentication server/identity server.
  • Integrate tightly and seemlessly to JBoss AS7

 

The Implementation

You can take a look at my code as it progresses.  Here’s generally what I’m doing:

  • OAuth Bearer Token authentication for machine-based clients.
  • Bearer token will be our own extension to Json Web Token (JWT).
  • Bearer tokens will be distributed using  Json Web Signatures (JWS)
  • Bearer tokens are issued for a user and also define role allowed for each distributed resource a user might interact with.
  • OAuth 2.0 and our bearer token implementation will be used to provide browser single-sign-on.
  • Oauth 2.0 and our bearer tokens will be used to provide browser authenticated third-party access grants.  (What OAuth2 was actually designed to do).
  • Client certificates can be  required at any authentication point depending on how you configure things.  Browser to IDP, Browser to resource, client to resource.
  • Implementing an Authentication Server to support all this.

As of 11/21/2012, I have implemented a JAX-RS friendly JWS implementation.  I have speced out and implemented our bearer tokens.  I’ve written a LoginModule for AS7 that can perform OAuth2 Bearer token authentication using our bearer token format and JWS.  Token format allows you to require SSL with client-certificates.  If you have this enabled, it also supports the idea of a surrogate, that is, one principal performat a request on behalf of a specific user.  Finally, I’ve started to scope out and implement an Identity/Authentication server to support all this stuff.  This isn’t complete yet.  I’ll document this stuff in more detail as I get closer to a beta release.

 

Relationship to Picketlink

The plan is to take this prototype and eventually work with the Picketlink project somehow later on.  Either just to funnel requirements, use parts of picketlink, share code, or even have them fully take it over.  The prototype will be fully functional, but will not have many persistence options or a management UI.  There will be a REST management interface though.  Whether or not a UI is introduced will be dependent on what the relationship with Picketlink ends up being.

 

Do you really need OAuth2?

November 15, 2012

billburke oauth, REST, security 4 Comments

For those of you you didn’t know, OAuth2 has now gone to the RFC phase at IETF.  I have a lot of mixed feeling about it now that I’ve read it a few times and am starting to write code around it.  Firstly, I think the spec is very solid, well thought out, and built on top of ideas and solutions that have been around for while.  Unfortunately though, ,OAuth 2 is not a security solution in and of itself.  It isnt even a complete protocol.  It is a framework for building security protocols and solutions.  This holdstrue with frameworks stating they support OAuth2.  They can’t support Oauth2, because Oauth2 is incomplete.  Any framework with OAuth2 support will require you to write a bunch of integration code unless they are targeting a specific provider like Google or Facebook for example.

You may not need OAuth

For all the noobs writing RESTful services, they think, if I’m doing REST, I need REST security.  Given that I do REST talks every once in awhile, often I see the perception that OAuth == REST security.  So, before you say “I need OAuth”, actually understand your security needs.

  • Does your app already manage user logins and authorization?  Are your clients only going to interact with this app?  If so, you don’t need OAuth.  From the Java EE Servlet perspective,  you just need Basic, Digest, Client-Cert, or FORM authentication with user-role mapping declarations.
  • Do you *not* need the ability to grant permission to a thirdparty to access your data?  Then you don’t need OAuth

I may need OAuth

  • Do you want a central authentication server that manages authentication and authorization for all your web apps?  Then you may need OAuth
  • Do you want the allow users to grant temporary permission for third parties to access services on behalf of them?  Then you may need OAuth

Why is OAuth Incomplete?

  • OAuth2 does not define how a user authenticates.  If you are looking for OAuth to be an SSO solution, your code-driven clients will have to have specific integration with each and every auth server to pass credentials.  OAuth2 does not define what credentials should be passed around.  It does not define how those credentials are transmitted.
  • OAuth2 only suggests an app auth method.  After user authenticate, the app must turn an auth code into an access token.  OAuth2 does not require a specific authentication mechanism for this, but does require authentication.
  • OAuth2 doesn’t define the scope token or access token format.  The OAuth 2 protocol is all about acquiring a temporary access token with a defined scope.  The scope defines what a client is allowed to do. Each target service will need to understand specific scope or access token formats in order to grant specific permissions.
  • OAuth does not define how third-party authenticates.  After obtaining an access token, OAuth does not require any specific mechanism to authenticate a third-party to the target resource.  It does offer suggestions, specifically the Bearer and MAC token RFCs.

So what does this mean?  Writing generic OAuth2 support for a framework is not possible.  Users will have to implement integration code for each OAuth2-compliant auth-server they want to integrate with both on the client side of things (i.e. JAX-RS Client) or the application side (your web apps).  While it may be possible to provide some helper code, IMO, you’d be better off just coding the entire thing yourself as, IMO, you’ll understand the protocol better.

How will Resteasy support OAuth 2?

Resteasy will focus on full solutions rather than helper classes.  I’m not convinced there’s enough helper code we could write that would add enough value for users to build on top on.  Instead we’ll do the following:

  • Resteasy token formats.  We will define our own token formats that map well to JAX-RS and Java EE environments.
  • We will define specific authentication protocols for user authentication and protocols for auth code to access code conversion.
  • We will provide or own IDP/Auth-server solution.  This will be a lightweight solution with simple file-based persistence.
  • We will write specific end-to-end solutions to things like Google OAuth APIs and Picketlink and any other OAuth2 provider that is really popular
  • For each OAuth2 provider, we will have a JAX-RS only solution so you can run in any environment you want.  We will also have specific AS7 integration so you that you can use web.xml role mappings as well as Subject propagation to other Java EE component layers.

Older Entries

%d bloggers like this: