Resteasy 2.3.3.Final Released

1 Comment

A bunch of bug fixes. Also added a couple new features:

  • A few people were asking for a servlet-free embedded HTTP engine.  Integration with Sun JDK’s com.sun.net.HttpServer was added.  See documentation for more details.  Support for different HTTP engines is in the works.
  • Support for some more formats of the Atom Publishing Protocol.  Thanks to contribution from Kurt Stam.

Links to release notes, downloads, and documentation are available from the main Resteasy Web Page.

Resteasy 2.3.1 Released

1 Comment

This is a maitenance release of 2.3.x series.

As always, to download and see documentation follow the links from our website.  Take a look at our Jira release notes.  You might also want to check out the Migration guide to view what has broken as far as backward compatibility if you’re upgrading from an earlier version.

Resteasy 2.3-RC1 Released, Please Testdrive!

3 Comments

Resteasy 2.3-RC1 has just been released.  Please follows links on main resteasy page to see documentation and download links.  We do have some backward-incompatibilities, so see the Migration Guide.  If you can, please testdrive it!  We will be doing a 2.3.GA release in 2 weeks so its up to you to find any critical blocker bugs we might have introduced!

After 2.3 is released we will be starting to work on Resteasy 3.0, a JAX-RS 2.0 implementation.  In conjunction we will also be moving source control to github.

Resteasy 2.2.2 Released

Leave a comment

This is just a maintenance release to fix a few minor and critical bugs found by the community.  You can download 2.2.2 here.  Release notes are here.

Hopefully we can now focus on getting a 2.3 beta out the door.  Currently I’m working on S/MIME integration as well as a decentralized auth protocol discussed in previous blogs.

Resteasy 2.2.1 Released

4 Comments

This is just a maintenance release to fix a few minor and critical bugs found by the community.  You can download 2.2.1 here.  Release notes are here.

Brainstorming REST Security Part I

6 Comments

If you went to my presentations at JUDCon/JBossWorld/RHS 2011 or read my recent blog posting you’ve probably noticed that I’m starting to focus on REST+Security.  This will be the start of a series of blogs that attempts to solidify a common vision around Security+REST and spec out what we’re going to do for RESTEasy and JBoss.

Internet Security is A Ghetto

One thing I’ve noticed is what a ghetto Internet security is, or even security in general.  There are old and new specifications, various industry collaborations efforts that succeed sort of (OpenID), start to succeed then have mutinies (OAuth), WS-* specs trying to bleed into the Web space (SAML), and promising specs that have had success in the email world (DKIM).  That’s just the small list of examples.  Its a freakin mess!  One common thread seems to be that most of them focus on providing security for the Internet (Internet with a capital ‘I’) and most have their roots in providing security for browser based apps.  Enterprise apps, while they can build off of security specs defined for the Internet, can often have very different requirements.  Web services can also have different requirements as well as a human (browser) may not be involved with client/server interactions.  In summary, I guess what I’m saying is that there are too many specs, no clear winners, too browser focused, and very little Enterprise focused.

What I’m trying to do with this and subsequent blogs is to brainstorm what high-level requirements for security enterprise apps should have, how can we make deployment of a security solution easier, what existing specs are applicable, what existing specs are open to input, what new specs have to be implemented, how can we make the protocols as easy to implement as possible in multiple languages, and finally, how can we design security services to make it as easy as possible to deploy to our Enterprise applications.

If I had to deploy a security solution…

A security solution I’d like to have would take enterprise as well as the difference between browser and non-browser clients in mind.  Its gotta balance strong security with ease of deployment, ease of use, and ease of implementation.  Many of these will be obvious, but I want to write it down.

  • For browser based clients I’d to authenticate using a user password and a one-time-password (OTP) generated by a soft or hard token generator.  Plain passwords are just not viable.   I myself have had both my GMail and World of Warcraft accounts hacked.  A combo of password + random key allows users to have simple to remember passwords yet be secure enough not to get hacked.  With smart phones like iPhone and Android, its easy to acquire a soft key generator (or implement one) without paying RSA an arm and a leg.
  • After authentication, the browser client should obtain an expirable cookie that it forwards with each request that contains authentication information the server will use to authenticate subsequent requests.
  • For non-browser clients,  I like the idea of digitally signed requests.  Verification of a digitally signed request would be the authentication mechanism.  What’s good about this (like the OTP of browser-based clients) is that credentials are different per request in that they are part of the attached signature.  A nonce and/or an expiration can be included within the digital signature to avoid replay attacks.
  • I foresee the need for non-browser clients to make requests on behalf of other services to other services.  Attaching multiple signatures to a request might be the way here.
  • It would be really cool to have a decentralized way to to both authenticate and authorize.  The hub and spoke approach that Picketlink STS uses creates a bit of a single point of failure and can require extra network round trips.  This decentralized mechanism should be able to work in an environment where services are making requests to other services on behalf of one or more identities.
  • A user had a really interesting case where they wanted to provide access to content through signed URLs.  The idea is that they would generate a signed URL and email it to a user to click on.  Very interesting.

Applicable Specs

Here’s some specs that I thought of off the top of my head that could be useful.  If anybody has ideas of others, let me know.

  • Time-based One Time Password Algorithm (TOTP).  Anil already did some work in Picketlink to implement this protocol.  We still need to integrate it as a Authenticator Valve in JBossWeb.  There’s also a nice iPhone app that supports TOTP.  I actually forked and re-implemented a lot of it on my own when I was learning Objective C a few months ago.  We’re looking at creating an Apple App Store account to distributed this forked implementation so we can brand it Red Hat.
  • SAML.  This may be what we need to do decentralized authorization.  I’m not fully versed in the spec, but I have read up on their HTTP bindings.  I’m not sure if there is any way to tunnel assertions through an HTTP header. (We don’t want to send SOAP requests).  If we can use SAML, we can piggyback off of a lot of the efforts already done in the Picketlink project.
  • Doseta.  I’ve already blogged about this protocol.  Using DNS to distribute keys is a little weird, but cool.  I’m asking that working group for this spec to break out Doseta into a few different specifications so that we can re-use the signature calculation algorithm in a standard way and to also make DNS public key publication optional and maybe also to provide an HTTP way to distribute keys.
  • Amazon REST Authentication.  Specs out how to sign URLs.  Maybe this could be standardized at IETF.
  • OpenID.  OpenID seems interesting for decentralized authentication, but I’m not sure if it can be used as a mechanism to do decentralized authorization.  OpenID is also more of a browser-based technology.
  • OAuth.  OAuth has both browser and non-browser bindings.  OAuth 2.0 pretty much leaves out what a token looks like.  I also don’t really want a token based system for non-browser clients

Possible Middleware Services

Here’s some ideas for services/integration we would implement.

  • HTTP Identity Proxy.  While implementing just an HTTP Proxy Cache is boring what might make these feasible is applying Identity to the mix.  This would delegate authentication and even authorization to an outside service.  Requests would be authenticated/authorized through the proxy, digitally signed, then forwarded to the target service.  The target service then only need to verify the signed request using the public key of the proxy.  While there’s obvious performance drawbacks, what’s interesting about this is that the application doesn’t have to think much about security and it could possibly be added even after the service is deployed.
  • TOTP Authenticator Valve.  Nuff said…I tihnk Anil already has this.
  • Better Auth integration with JBossWeb and the JBoss Security Domain abstraction.  Right now there’s just too many steps to enable things.
  • Various auth plugins for JBossWeb to realize our vision here.

Resteasy 2.2 Released

2 Comments

After baking in the oven the last few months, Resteasy 2.2 has been released to the world and is available for download.  You can view our documentation here.  We fixed a lot of bugs since the 2.1 release which can be viewed in the release notes of previous beta and RC releases:

Features wise we’re starting to focus on security solutions for RESTful web services.  In this release we focused on a digital signature framework based on DOSETA and DKIM.  I wrote a blog a few months ago about some possible use cases for digital signatures.  It will be interesting to see how people use our digitial signature framework, but more importantly how and if they want to use the DOSETA and DKIM protocols for digital signature propagation.  We are extremely interested in feedback and suggestions for improving the protocol and how it might solve (or not solve) any security use cases you might have.

Beyond that, writing the digital signature framework also helped to flush out the Resteasy interceptor API.  For instance, we found that it was very useful to hold off marshalling header objects into string formats until the stream is written to.  This allowed us to pass information through header objects to the interceptors that are performing signing and verification.  Writing down these requirements will be very applicable to the JAX-RS 2.0 JSR as we’re currently focusing on interceptors there.

What’s Next?

Further 2.x releases will focus mainly on adding security features.  We’re also going to be developing Resteasy 3.0 in parallel.  Here’s some points:

  • message body encryption with both multipart/encrypted and develop a new Content-Encoding. This will also help us flush out interceptors more I think
  • SAML/Picketlink. I think we may be able to integrate with SAML, specifically Picketlink to provide some hub/spoke authentication/authorization.
  • Clean up our OAuth support.
  • JAX-RS 2.0 has started which we will implement in Resteasy 3.0. The client API is shaping out and I might deliver a prototype of it when the next revision is submitted by the JAX-RS spec leads.

Older Entries Newer Entries

%d bloggers like this: