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.
Geothermal HVAC Install: Finding a Contractor
April 22, 2013
geothermal, hvac Leave a comment
- Geothermal HVAC Part 1: Finding A Contractor
- Geothermal HVAC Part 2: Installing the Loop
- Geothermal HVAC Part 3: Installing In House System
- Geothermal HVAC Part 4: Costs, Savings, and Performance
We have a 23 year old central air heating and cooling system in a small semi-rural town in Massachusetts. My cooling system is pretty much on its last leg, but the oil-burning furnace could probably last another 5-10 years. We do not have any natural gas lines in our neighborhood. Our home is 4000 square feet. The insane oil and electric prices circa 2007-2008 led me to research and think seriously about putting in a Geothermal Heat Exchange system in our home. I decided to pull the trigger in the Fall of 2012. Now today, they’ve started drilling, so I thought I’d start blogging about it. You can find a lot of information online about Geothermal HVAC systems, but I could only really find partial descriptions of installs and costs for these systems from actual home-owners. So, maybe this detailed beginning to end description of the whole process might be useful to somebody.
Why do I want Geothermal?
- I have to replace my existing, ancient, heating and cooling system anyways
- Overall energy cost savings. The install expense over traditional A/C and oil will be paid back over time with the lower cost in energy to run the system. How long does it take for the system to pay for itself? Seems pretty variable. 5-15 years depending on the location, size of home, and quality of install. I’ll get back to you all a year from now to compare the savings from my original system.
- Improved air quality in home
- No more worries of carbon monoxide as I wouldn’t be burning anything anymore.
- Maybe help resell value. At least make my house more interesting when trying to sell it if I ever move.
- Quieter
- I get to be a good Democrat and help save the planet 😉
- The technology is just cool.
Finding a Contractor
I had been procrastinating on pulling the trigger on a Geo system since 2008. We use a well for the water to our home. Last summer, the underground pump for our well failed and had to be replaced. We called up the original drillers of our well, Skillings and Sons, to help us out and they were here for a day installing the new pump. I got to talking with one of the drillers asking if they had ever done a Geo system in an existing home. The driller I talked to was awesome. I wish I could remember his name. He went into tons of detail with me on what was involved, what type of system (open vs. closed loop) I should get. How much area they usually needed to dig. What the install would look like. How a Geo system worked, etc. The guy basically sold me. So, I decided to start the process going.
I must say, it was kind of hard finding a contractor to do this. Maybe it was the time of year (August, September). I also think that most homeowners are ignorant of the significant install costs of a Geo system and contractors might be a little reluctant to put time into a detailed quote because the homeowner might balk. I got the names of a few local guys from Skillings. I pinged my company’s internal mail list, and one Red Hatter gave me the name of a guy that did a geo system for her home in New Hampshire. I’ll list them here:
- Redmond HVAC. Recommended by Skillings & Sons.
- Energy Smart Alernatives. Found them on the Internet. They have a great website and had a nice Facebook with detailed pictures of their jobs.
- Bill Wenzel Heatng and Cooling. He did a system for another Red Hatter in New Hampshire. His name came up a lot in web searches too. Seemed to have the most geothermal experience out of all the contractors.
I pinged two other contractors, but never could get a response from them. For Bill Wenzel I had a hard time getting him to answer an email or phone call. We talked a little bit over the phone, got some rough cost estimates, even faxed him a layout of our home so he could do a detailed quote, but I never heard back from him. Too bad, because he got a really good recommendation from a co-worker of mine. Energy Smart Alternatives came out to our home to do an estimate. They were professional enough, but I ended up picking Tim Redmond of Redmond HVAC. Both had done systems locally, but Redmond HVAC had a significantly lower price than Energy Smart Alternatives and costs in line with the rough cost estimates I talked over with Bill Wenzel and research I had done over the Internet. Honestly, I think if I had had a similar quote from all three, I would have picked Tim because of his Skillings & Sons recommendation and the amount of care and time he took answering questions and putting together the estimate. I’m writing this blog as the system is being install, so I’ll write some overall opinions at the end.
So, if you already have a well for water, I suggest pinging your driller to see if a) They do Geothermal installs (they probably do) and b) can they recommend somebody local. At least when I did an internet search, a ton of people came up in Massachusetts, but it was hard to figure out who was reputable or not.
The quote
4000 square foot home. Closed loop. 2, 4 ton Comfort Aire units. A little duct work, but almost all of it would be reused. Removal of furnace, A/C, and oil tank. 3, 375ft. vertical bore holes. One 15 ft from house, 2 others 15 feet from each other. Cost? A little under $50k before the tax credit of 30%. Honestly, would not have done this job without the federal tax credit of 30% which ends in 2016.
Closed Loop vs. Open Loop
Both Tim Redmond and Skillings recommended a closed loop system. You might be able to save a little bit more with an open loop system, but there are some issues with them. My opinion is that closed loop is the best because any future maintenance on the system is done entirely in your home. You dig the hole, put in the HDPE pipe, bury it, then forget about it. Should last long after I’m dead. Open loop has all the same issues as a regular well. The pumps can fail, and then you have to deal with going in ground to get them. Here is a good article on other problems you can have.
Can your home do Geothermal?
Another core issue with Geothermal is, can you install within your existing home? Do you have the acreage for it? Can you re-use the duct work? Are there any utilities that would impede drilling? Those are just some of the questions you’ll need to get answered by any contractor you pick.
What’s next?
So today they finished 2 of the 3 vertical bore holes. My next blog I’ll describe the whole drilling process and post a bunch of pictures of what they had to do.
Resteasy 3.0-beta-4 and 2.3.6.Final Released
April 10, 2013
See jboss.org/resteasy for relevant links for downloads/documentation.
3.0-beta-4 is our last beta! Everything should be implemented. JAX-RS 2.0 Final is being voted on in the JCP. We’ll be obtaining the TCK soon and starting work on getting certified. There’s also some architectural work that needs to be finished for 3.0. We’ll have a short RC release sometime in May, then a 3.0 Final Release early June.
2.3.6 is just a maintenance release.
Resteasy 3.0-beta-3 – Latest Spec Updates
February 7, 2013
java, JAX-RS, RESTEasy 1 Comment
Resteasy 3.0-beta-3 has been released. Follow the links from our main jboss.org page to download and view the documentation. Here are the highlights:
- The latest and greatest from the master branch of the JAX-RS 2.0 spec. Many of the client builder SSL changes I introduced in 3.0-beta-2 have made it into the spec. Thanks Marek for giving the thumbs up on them.
- There are a few minor features of JAX-RS 2.0 we don’t have implemented yet. You’ll get a NotImplementedYetExceptoin if you invoke them.
Next I’ll be focusing on my book, implementing our missing features, refactoring, and general test coverage.
Resteasy 3.0-beta-2 Released with New OAuth 2.0 Features
January 24, 2013
java, JAX-RS, oauth, REST, RESTEasy 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
November 21, 2012
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
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.
Why do client certs have to be so difficult?
November 6, 2012
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 3.0 Beta 1, JAX-RS 2.0 Preview
October 30, 2012
Now that JAX-RS 2.0 is in Public Draft and has stabilized a bit, API-wise, we finally released Resteasy 3.0 Beta 1. This release implements almost all of the features defined in the JAX-RS 2.0 Public Draft. Many of the key features in Resteasy 2.x have now been standardized in JAX-RS 2.0. There’s a new client API which is similar (actually better) than the current Resteasy 2.x client API. Interceptors have been added to the spec. You’ll find that they map very closely to Resteasy’s. I pushed really hard for this. Finally, there’s the async HTTP apis. Also very similar to Resteasy’s. All and all, if you’re using some of these features currently within Resteasy, you shouldn’t have much problems migrating to the JAX-RS 2.0 equivalent APIs. The only thing we’re missing is the client proxy support, but I couldn’t get other experts to agree it was a good idea to add. 😦
This beta has a few JAX-RS 2.0 examples with the distribution. The Resteasy documentation regarding JAX-RS 2.0 isn’t where I want it yet, but we’ll get there as we get closer to a final release of 3.0. To learn some of the new features, it may be best to take a look at some of the features within Resteasy that take advantage of these APIs. I’ve linked them all below.
- Intro to JAX-RS 2.0 Article
- JAX-RS 2.0 Public Draft Specification
- Resteasy 3.0-beta-1 Download
- Resteasy 3.0-beta-1 Docs
- Resteasy 3.0 client cache implementation code (to see how filters interceptors work on client side)
- Doseta digital signature headers (good use case or interceptors)
- File suffix content negotiation implementation (server-side filter example)
- Other server-side examples (cache-control annotations, gzip encoding, role-based security)
java.dzone.com/articles/whats-new-jax-rs-20
Resteasy 2.3.5 Released
October 22, 2012
JAX-RS, REST, RESTEasy 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.
Bill the Plumber 