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.

My new book! RESTful Java with JAX-RS 2.0

14 Comments

My 2nd edition of RESTful Java is out!  RESTful Java with JAX-RS 2.0 covers the spec additions to JAX-RS 2.0 including 3 new chapters:

  • JAX-RS 2.0 Client API
  • Asynchronous Client and Server APIs
  • Filters and Interceptors

The book has also been revised here and there to cover some of the smaller features that were added to JAX-RS 2.0 like ParamConverters, Link, an the extensions added to UriBuilder.  The workbook examples and chapters have been revised and expanded to cover this new content as well, so you really get 6 new chapters in total.    Many thanks  to Fernando Nasser, Melanie Yarborough, Meghan Blanchette, Meghan Connolly, and Charlie Roumeliotis for making this happen.  I’d also like to thank the JAX-RS 2.0 JSR Expert Group, especially Marek Potociar, Santiago Pericas-Geertsen, and Sergey Beryozkin.

 

Resteasy 3.0 Final Released!

1 Comment

Resteasy 3.0 has been released, follow links on the Resteasy web page to find downloads etc.  After sitting on the JAX-RS 2.0 JSR for two years and implementing it in the Resteasy master branch we’re finally ready to release!  I’d like to first thank the JAX-RS 2.0 JSR especially Marek, Santiago, and Sergey.  We butted heads a lot on the JSR and I could be difficult at times, but I think JAX-RS 2.0 is a great spec because of it. I’d also like to thank Weinan Li, Ron Sigal, and Gunnar Morling for fixing bugs and getting Bean Validation integration working in the last minute.

It is really really really important that you read the migration guide. We had to change a bunch of stuff and behavior because the JAX-RS 2.0 got really strict, specifically the request dispatch algorithm, so you really need to view it.  We also refactored some SPIs and such.  So, again, read the migration guide!

Features

  • JAX-RS 2.0 compliance.  Once Wildfly supports HTTP Digest Authentication we can officially certify Resteasy 3.0.Final.  Since this is really just red tape, I decided to release 3.0 now instead of waiting, weeks for another Wildfly release.
  • SSO and OAuth2 for browser and RESTful web services.  Built to work on AS7 and EAP 6.1, allows you to add these features on top of existing AS7 security domains
  • Bean Validation 1.1. integration support
  • More comprehensive generics support for all component types

Deprecated APIs

JAX-RS 2.0 standardized many features that existed in Resteasy 2.3.x and earlier.  Going forward we will not support these deprecated APIs in Resteasy 3.0.  They are there to ease your migration from proprietary Resteasy APIs to the JAX-RS 2.0 equivalent.  If you have a bug, you need to either provide a patch/pull request yourself, or upgrade to the JAX-RS 2.0 equivalent API.  As soon as Resteasy 3.0 gets into our commercial distribution, we will be removing these deprecated APIs from Resteasy, so you should switch sooner rather than later.

  • Resteasy Client API org.jboss.resteasy.client.ClientRequest etc.  Proxy API has been ported to work on top of JAX-RS 2.0 api.
  • Resteasy interceptor framework: MessageBodyReaderInterceptor, MessageBodyWriterIntereptor, PostProcessorInterceptor, etc… These all have JAX-RS 2.0 equivalents
  • Resteasy async API.  This also has a JAX-RS 2.0 equivalent

What’s Next?

Next few months we’ll be focusing on some point releases to mature 3.0.  I’ll also be finishing a revision of my O’Reilly JAX-RS book and you’ll see some new workbook examples in the distribution soon.  I’m also starting a new project that is going to pull in the OAuth2 work I’ve done.  More on that later though.  As for future Resteasy features, I’m looking for somebody to drive a RESTful database service interface.  If you’re interested, please ping me or our development list.

 

 

Resteasy 3.0-beta-5 Released

5 Comments

Did a bit of refactoring of the SPIs to improve generics support among other bug fixes.  A side effect to this is that there is now a programmatic interface that allows you to register un-annotated resource classes.  Also, bumped Jackson to 1.9.12 and also added an additional Jackson2 provider.  See docs for more details.

http://jboss.org/resteasy

Resteasy 3.0-beta-2 Released with New OAuth 2.0 Features

3 Comments

Resteasy 3.0-beta-2 has been released.  Follow the links from our main jboss.org page to download and view the documentation.  Here are the highlights:

  • Added a new ResteasyClientBuilder class to make it easier to create HTTPS/SSL connections on the client side
  • Extensive work on OAuth 2.0 support including tight AS7 integration.

You can find out more about our OAuth 2.0 stuff here, and the distribution comes with an extensive example.  Here’s the overall features of it:

  • Turn an existing servlet-form-auth-based web application into an OAuth 2.0 provider.
  • Provide Distributed Single-Sign-On (SSO) from a central authentication server. Log in once, and you can securely access any browser-based app configured to work in the domain.
  • Provide Distributed Logout. Following one link from any application can log you out of all your distributed applications configured to use SSO.
  • Web apps can interact securely with any remote restful service by forwarding access tokens through the standard Authorization header.
  • Access tokens are digitally signed by the oauth2 framework and can be used to access any service configured to work in the domain. The tokens contain both identity and role mapping information. Because they are digitally signed, there’s no need to overload the central authentication server with each request to verify identity and to determine permissions.

What’s next for Resteasy?  Next release I’ll be focusing on getting it up to date with the latest JAX-RS 2.0 snapshot.  I also have to get started on my O’Reilly book.

Scoping out Resteasy Skeleton Key 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?

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.

Why do client certs have to be so difficult?

8 Comments

Now that Resteasy 3.0-beta-1 is out, I’ve been thinking a lot about some custom security protocols I’d like to prototype.  Client cert authentication has always been a part of that thinking, but when it comes to browsers, client certificates are complex and even scary for most users.  Why does it have to be this way?

Current web authentication uses cookies to set up a secure session between an authenticated user and his browser.  Cookies are allocated and stored per-domain and forwared with HTTP requests to those domains.  Why can’t we do something similar with SSL and client certificates?

For example, what if when you registered at Google.com, it asked you, “Do you want to authorize this device?”.  You would click on a “OK” button and Google would generate a key-pair and a digitially google-signed certificate for your device.  The HTTP response to clicking that “OK” button would provide a base 64 encoded headers that contained the generated private key and signed certificate:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Private-Key: 23423ab1123affaccde12312
Set-Certificate: 11ab332789dff


<h1>All Set</h1>
<p>Your machine is now authorized</p>

For the google.com domain, your browser would store the private key and certificate in your browser’s persistent store.  The next time your browser makes an HTTPS connection to google.com, it would use this certificate to connect.  When you think about it, this isn’t much different than google setting a persistent cookie to remember who you are.  Now its remembering you in a much more secure way.

Additionally, what would be cool, if this google-generated client-cert could be negotiated and sent to other domains/websites on the internet.  For example, let’s say you had a social media site that exchanged sensitive information and wanted to use HTTPS.  The social media site could send a redirect, with an additional certificate negotiation header stating which client-cert domains it prefers

HTTP/1.1 307
Location: https:/.../
Accept-Certificate: google.com, facebook.com

Here, the server is redirecting us to an HTTPS based URL.  The Accept-Certificate says that it requires a google.com or facebook.com generated client certificate.  The browser would then make an SSL connection to the redirect URL using a stored client cert from one of the preferred domains.

There’s a bunch of cool things about this.  For one, you could have SSO to multiple different social media sites and applications without the need to enter one password.  Secondly, there’s a lot of secure protocols you could implement on top of this to make the internet as a whole, more secure.  Most importantly, there’s no knowledge the human user has to have as to install a client certificate.  It really sucks that the microsofts, mozillas, apples, and googles of the world haven’t put much more thought into client-certs and making them easier to use.

Resteasy 2.3.5 Released

2 Comments

After a bit of delay, Resteasy 2.3.5 is finally out.  It is pretty much a maintenance release.  I want to thank Ron Sigal and Wei Nan Li.  They did almost all the work for this release (minus patches submitted by users).  Resteasy 3.0 beta later this week!

Go to Resteasy website for links on how to download, you can check out the release notes too.

json-home format: resource discovery

7 Comments

Thank you Mark Little for turning me on to the JSON-Home format Internet Draft.  “application/json-home” is a format that describes resources available from a particular site as well as possible hints on how to interact with those services.

   GET / HTTP/1.1
   Host: example.org
   Accept: application/json-home

   HTTP/1.1 200 OK
   Content-Type: application/json-home
   Cache-Control: max-age=3600
   Connection: close

   {
     "resources": {
       "http://example.org/rel/widgets": {
         "href": "/widgets/"
       },
       "http://example.org/rel/widget": {
         "href-template": "/widgets/{widget_id}",
         "href-vars": {
           "widget_id": "http://example.org/param/widget"
         },
         "hints": {
           "allow": ["GET", "PUT", "DELETE", "PATCH"],
           "representations": ["application/json"],
           "accept-patch": ["application/json-patch"],
           "accept-post": ["application/xml"],
           "accept-ranges": ["bytes"]
         }
       }
     }
   }

While I like the format, my own personal opinion is that hints are not needed.  Most(99%?) non-browser clients already know how to interact with the resources.  What they are looking for, really, is the actual URL to the resource.  IMO, a separate format(s) should be defined for resource description and the link relation URL can offer up that representation if it wants to.

Another beef I have with this (and the atom link XML format too) is that the value for the relationship, rel, can be a URL.  I’d much rather define a logical name, and have a separate attribute that specifies a URL that describes the relationship.  For applications, especially intra-net based ones, URLs can change more frequently than their Internet counterparts.  A logic name attribute could remain fixed and the description URL could be more dynamic.

BTW, I’m glad that the powers-that-be at IETF are showing some love to non-browser clients. Json-home is something similar I’ve done for a few of the RESTful services I’ve written.

Older Entries

Follow

Get every new post delivered to your Inbox.

Join 691 other followers

%d bloggers like this: