Tardate 2016

Can You Keep a Secret? / 宇多田ヒカル

cancannible is a gem that has been kicking around in a few large-scale production deployments for years. It still gets loving attention - most recently an official update for Rails 4 (thanks to the push from @zwippie).

And now also some demo sites - one for Rails 3.2.x and another for Rails 4.3.x so that anyone can see it in action.


So what exactly does cancannible do? In a nutshell, it is a gem that extends CanCan with a range of capabilities:

• permissions inheritance (so that, for example, a User can inherit permissions from Roles and/or Groups)
• general-purpose access refinements (to automatically enforce multi-tenant or other security restrictions)
• automatically stores and loads permissions from a database
• optional caching of abilities (so that they don't need to be recalculated on each web request)
• export CanCan methods to the model layer (so that permissions can be applied in model methods, and easily set in a test case)

(blogarhythm ~ Points of Authority / Linkin Park)

I recently got my hands on a review copy of Learning Devise for Rails from Packt and was quite interested to see if it was worth a recommendation (tldr: yes).

A book like this has to be current. Happily this edition covers Rails 4 and Devise 3, and code examples worked fine for me with the latest point releases.

[フレーム]The book is structured as a primer and tutorial, perfect for those who are new to devise, and requires only basic familiarity with Rails. Tutorials are best when they go beyond the standard trivial examples, and the book does well on this score. It covers a range of topics that will quickly become relevant when actually trying to use devise in real life. Beyond the basic steps needed to add devise in a Rails project, it demonstrates:

• customizing devise views
• using external authentication providers with Omniauth
• using NoSQL storage (MongoDB) instead of ActiveRecord (SQLite)
• integrating access control with CanCan
• how to test with Test::Unit and RSpec

I particularly appreciate the fact that the chapter on testing is even there in the first place! These days, "how do I test it?" should really be one of the first questions we ask when learning something new.

The topics are clearly demarcated so after the first run-through the book can also be used quite well as a cookbook. It does however suffer from a few cryptic back-references in the narrative, so to dive in cookbook-style you may find yourself having to flip back to previous sections to connect the dots. A little extra effort on the editing front could have improved this (along with some of the phraseology, which is a bit stilted in parts).

Authentication has always been a critical part of Rails development, but since Rails 3 in particular it is fair to say that devise has emerged as the mature, conventional solution (for now!). So I can see this book being the ideal resource for developers just starting to get serious about building Rails applications.

Learning Devise for Rails would be a good choice if you are looking for that shot of knowledge to fast-track the most common authentication requirements, but also want to learn devise in a little more depth than a copy/paste from the README and wiki will get you! It will give enough foundation for moving to more advanced topics not covered in the book (such as developing custom strategies, understanding devise and warden internals).

(blogarhythm ~ Can you keep a secret? - 宇多田ヒカル)

Megar (“megaargh!” in pirate-speak) is a Ruby wrapper and command-line client for the Mega API.

In the current release (gem version 0.0.3), it has coverage of the basic file/folder operations: connect, get file/folder listings and details, upload and download files. You can use it directly in Ruby with what I hope you'll find is a very sane API, but it also sports a basic command-line mode for simple listing, upload and download tasks.

If you are interested in hacking around with Mega, and prefer to do it in Ruby, give it a go! Like this:

# do a complete folder/file listing
session = Megar::Session.new(email: 'my@email.com', password: 'my_password')
session.folders.each do |folder|
 folder.files.each do |file|
 puts file.name
 end
end
# upload a file
file_handle = '../my_files/was_called_this.mp3'
session.files.create( name: 'First.mp3', body: file_handle )

Or from the command line:

$ megar -e my@email.com -p my_password ls
$ megar -e my@email.com -p my_password put *.pdf

I would still call it "experimental" at this stage because it needs more widespread hammering, and of course the Mega API is not fully documented yet. There are many more features of the API that it would be good to support, and I'd love for others to pitch in and help - go fork it on github!

I was keen to get a Mega account and check it out when the launch publicity hit, and was immediately impressed by the web interface. Very slick. Notwithstanding some of the intense analysis and some criticism (for example by SpiderOak and Security Now), the "trust no-one" design approach is very interesting to contemplate and hack around with.

The Mega API is still evolving. The documentation is thin and the main resource we have to work with is the Javascript reference implementation that actually runs the Mega site. But there has been quite a bit of work in the community to hack on the API - particularly in Python (with API analysis and projects like mega.py).

It didn't take me long to realise there was nothing much going on with Ruby. After a bit of messing around, I think the main reason for that is the pretty wretched state of cryptographic support in Ruby. Unlike Python (which has PyCrypto amongst others I'm sure), in Ruby we still on the whole get by with thin wrappers on OpenSSL that look and smell distinctly C-dy. But that's a challenge for another day...

For now I'm pretty happy that Megar has all the main crypto challenges solved (after a bit of low-level reverse engineering supported by a healthy dose of TDD). Now I wonder what I'm going to use it for?

Doing more than just talking about viruses: he fires up a few classics in a DOS box and pokes around with a binary editor before looking at current threats and live infection data. Very cool and entertaining. Not many are brave enough to do live demos, but if you watch to the end you'll get to see how prepared he was for failure;-)

Best served with sides of:

• Daniel Suarez's Daemon - for the extreme version of how bad things can go wrong,
• Rebecca MacKinnon: Let's take back the Internet! - because maybe organised crime is the perfect distraction as we rush headlong to enslave ourselves to the Sovereigns of the Internet, and
• Security Now! #291 - for Steve Gibson's deconstruction of stuxnet, the most spohisticated Internet-borne "weaponised payload" ever discovered... and perhaps a plausibly-deniable warning from Government(s) that "you call that a knife? THIS is a knife!"

[埋込みオブジェクト:http://video.ted.com/assets/player/swf/EmbedPlayer.swf]
PS: better quality vid on youtube. And yes, that is a 5 1/4" floppy.

Blogarhythm: Security - Jo Jo Zep & The Falcons

I've argued for some time that it is crazy for most websites to have their own authentication (username/password) system these days.

• We the users have no patience for yet another registration process, validation email flow, and password to remember


• Security is too easy to get wrong, unless you truly have security professionals on staff


• Designing sites with a registration process, issuing credentials etc is a legacy holdover from the days when we had no choice. OpenID, OAuth (in particular) have long since changed the game.

And the shift is well underway. More sites these days are offering the ability to authenticate using twitter, facebook, google or other credentials. Janrain chief executive Brian Kissel has said that

..publishers are jumping on-board as they realize it’s valuable to know who their readers are and that it’s much easier to convince them to sign in with an existing account than to create a new one

Perhaps like many sites, you integrated with Facebook Connect to let users sign into your site with their Facebook account. Which all sounds great, until you wake up one day, and are caught you off guard by two bits of news:

• Facebook Connect brand will be deprecated as part of the launch of Open Graph


• There's a movement of disaffected Facebook users concerned with privacy and trust threatening to quit

Jason Calacanis was one of the high-profile Facebook quitters who got "caught" sneaking back in. He explained the reason on a This Week in Startups .. to (temporarily) regain control over all the third-party applications he'd forgotten were using his Facebook account for authentication.

Suddenly, you are feeling the downside of depending on a third-party authentication service:

• The amount of engineering required to "keep up" with the evolving identity management space is unpredicatable since someone else is calling the shots


• Your site and brand is totally exposed to a user backlash over something that you have have no control over and has nothing to do with you

So is there better way?

If your site is directly linked to the third-party service (e.g. a tool for twitter, or a Facebook application) then the answer is no, and the question doesn't even make sense.

But for most cases, we are basically outsourcing the identity management and authentication, and want to avoid getting caught down a blind alley.

Pure OpenID is one approach: it is not controlled by any single vendor, and there are capabilities such as delegation which allow users to pick and choose their provider. The unfortunate fact is that OpenID is far from mainstream, and will likely remain a mystery for most users (even if it is hard at work under the covers of their Google or Yahoo! sign in).

Personally, I think the best approach is to disentangle ourselves from directly dealing with identity providers. By outsourcing the identity management and authentication process to an intermediary that aggregates the services of many identity providers we get a nice compromise:

• Someone else to take on the burden of securing the system and keeping up to date with the improvements made by the various identity providers


• We get to offer the convenience to our users of signing in with a wide range of identity providers


• And I am making my site directly dependent on only one service provider, and one that specializes in identity not other business interests which may potentially bring us into conflict

The best solution I have found so far is Janrain Engage (formerly RPX). I've used this on a number of sites (e.g. CloudJetty - my directory of cloud/SaaS applications), and released a gem (authlogic_rpx) for easily using the service with Ruby on Rails.


If you are concerned about your website getting locked in to a particular authentication provider (whether it is Facebook, twitter or anything else) then I would certainly recommend you check out Janrain Engage.

Now I realise this may come across as an unabashed plug for Janrain, but the truth of the matter is that (a) it works, and (b) I haven't really been able to find any fully baked alternatives. If you do know of other similar services or ways of approaching this problem I'd be really interested to hear about them.

Blogarhythm for this post: IDentity - 玉置成実 Tamaki Nami

The light will shine on me allowing me to make progress and start on the road to my identity

Authlogic_RPX is the gem I released some time back that lets you easily support multiple authentication schemes in Rails without really having to think about it (Facebook, twitter, OpenID, Google, Yahoo! etc etc etc).

With thanks for contributions from John and Damir, Authlogic_RPX 1.1.1 is now available and includes an internal identity mapping that lets you tie multiple authentication methods to a single user. There are also some other bug fixes and improvements, so it is recommended you update Authlogic_RPX even if you don't want to enable the identity mapping.

See the Authlogic_RPX repo on github for information about installation, usage, and don't forget the sample site (and sample code).

Under the covers, it uses the RPX service from JanRain, a bit like this:


To get a better idea of why you might want to use Authlogic_RPX, and some pointers on how to do it, here's a reprise of my presentation on the subject to the singapore Ruby Brigade last year:


Soundtrack for this post? (I want) Security Jo Jo Zep & The Falcons. 1977, tight pants, mo and all;-)

authlogic is by far and away my favourite authentication framework for Rails. I've raved enough in my slides on Authlogic_RPX.

It's true beauty is making authentication so unobtrusive for application developers.

However, the same can't be said for Authlogic plugin developers. I spent quite a bit of time meandering through the authlogic source and other plugins in order to produce Authlogic_RPX (the RPX plugin for authlogic, to support JanRain's RPX service).

I recently returned to the Authlogic_RPX in order to provide an update that finally adds identity mapping (with contributions from John and Damir; thanks guys!).

Luckily my previous exploits were recent enough that much of what I learned about authlogic were still pretty fresh. But before I forget it all again, I thought it would be worthwhile to write up a few of the "insights" I had on the authlogic source.

Hence this post. I'm just going to focus on one thing for now. Since authlogic is so "unobtrusive", one of the big conceptual hurdles you need to get over if you are attempting to write an authlogic plugin is simply:

Just how the heck does it all get loaded and mixed in with my models??

(To follow this discussion, I'd recommend you have a plugin close to hand. Either my previously mentioned Authlogic_RPX, or another like Authlogic_OAuth, or Authlogic_openid)

By unobtrusive, I mean like this. Here is the minimal configuration for a user model that uses Authlogic_RPX:

 class User < ActiveRecord::Base
 acts_as_authentic
 end

Pretty simple, right? But what power lies behind that little "acts_as_authentic" statement?

What follows is my attempt at a description of what goes on behind the scenes..

First: get loaded

The main file in an authlogic plugin/gem is going to have the relevant requires to the library files. But they do squat. We start mixing in our plugin with the includes and helper registrations:

require "authlogic_rpx/version"
require "authlogic_rpx/acts_as_authentic"
require "authlogic_rpx/session"
require "authlogic_rpx/helper"
require "authlogic_rpx/rpx_identifier"

ActiveRecord::Base.send(:include, AuthlogicRpx::ActsAsAuthentic)
Authlogic::Session::Base.send(:include, AuthlogicRpx::Session)
ActionController::Base.helper AuthlogicRpx::Helper

Note that your plugin ActsAsAuthentic module get's mixed in with ActiveRecord itself (not just a specific ActiveRecord model). That's crucial to remember when considering class methods in your plugin (they are basically global across all ActiveRecord).

What including ActsAsAuthentic in ActiveRecord::Base does..

What happens when the previous lines included the plugin's ActsAsAuthentic module?
The self.included method handles the initial bootstrap..

module AuthlogicRpx
 module ActsAsAuthentic
 def self.included(klass)
 klass.class_eval do
 extend Config 
 add_acts_as_authentic_module(Methods, :prepend)
 end
 end
 ..

Here we see we do a class_eval on the class that the module is included in (i.e. ActiveRecord::Base). You'll immediately get the sense we're doing some kind of mixin with the Config and Methods modules. The Config / Methods module structure is a common pattern you will see throughout authlogic.

extend Config takes the Config module (AuthlogicRpx::ActsAsAuthentic::Config) and add it to the ActiveRecord::Base class cdefinition. i.e. methods defined in Config become class methods of ActiveRecord::Base. (If you add a def self.extended(klass) method to Config you'll be able to hook the extension).

add_acts_as_authentic_module(Methods, :prepend) adds the Methods module (AuthlogicRpx::ActsAsAuthentic::Methods) to the authlogic modules list. That's all. Take a look at add_acts_as_authentic_module:

def add_acts_as_authentic_module(mod, action = :append)
 modules = acts_as_authentic_modules
 case action
 when :append
 modules << mod
 when :prepend
 modules = [mod] + modules
 end
 modules.uniq!
 write_inheritable_attribute(:acts_as_authentic_modules, modules)
end

Ready to launch..

It is only when we add the acts_as_authentic in our model class that things start to happen. This method loads all the modules from the list built up by all the call(s) to "add_acts_as_authentic_module". Note the include in the last line of the method:

def acts_as_authentic(unsupported_options = nil, &block)
 # Stop all configuration if the DB is not set up
 return if !db_setup?
 
 raise ArgumentError.new("You are using the old v1.X.X configuration method for Authlogic. Instead of " +
 "passing a hash of configuration options to acts_as_authentic, pass a block: acts_as_authentic { |c| c.my_option = my_value }") if !unsupported_options.nil?
 
 yield self if block_given?
 acts_as_authentic_modules.each { |mod| include mod }
end

Ignition..

Once the include is invoked, our plugin will usually hook the event and do some setup activity in our module's def self.included method.

module Methods
 def self.included(klass)
 klass.class_eval do
 ..
 end
 ..
 end
 ..

Unlike the Config extension, the class you are including in (the klass parameter in the example), is the specific ActiveRecord model you have marked as "acts_as_authentic".

In other words, the methods in the Methods module get included as instance methods for the specific ActiveRecord models class (User in the example I presented earlier).

Hanging it on the line..

Let's hang it all out in a simplified and contrived example. Take this basic structure:

module AuthlogicPlugin
 module ActsAsAuthentic
 def self.included(klass)
 klass.class_eval do
 extend Config 
 add_acts_as_authentic_module(Methods, :prepend)
 end
 end
 module Config
 def config_item
 end
 end
 module Methods
 def self.included(klass)
 klass.class_eval do
 def self.special_setting
 end
 end
 end
 def instance_item
 end
 end
 end
end

If we add this to our User model, then the result we'd end up with is this:

• config_item: will be a class method on ActiveRecord::Base


• instance_item: will be an instance method on User


• special_setting: will be a class method on User

Conclusions & Implications?

I've covered the main points in bootstrapping authlogic. There's obviously a lot more that goes on, but I think once you get these basics it makes authlogic-related code so much easier to read and understand. It's a pretty neat demonstration of dynamic ruby at work.

Understanding the loading process is also makes it possible to be definitive about how your application will behave, rather than just treating it as a heuristic black box.

Take authlogic configuration settings for example. Say we have a configuration parameter in our plugin called "big_red_button" that takes values :on and :off.

Syntactically, both of these user model definitions are valid:

 class User < ActiveRecord::Base
 acts_as_authentic do |c|
 c.big_red_button :on
 end
 end

 class User < ActiveRecord::Base
 acts_as_authentic
 big_red_button :on
 end

However, the behaviour is slightly different, and the difference will be significant if you have any initialisation code in the plugin that cares about the setting of the big_red_button.

In the second case, it should be clear that setting big_red_button :on only happens after all the plugin initialisation is complete.

But in the first case, it is a little more subtle. If you go back to review the acts_as_authentic method you'll see that setting the big_red_button occurs at yield self if block_given?. Implications:

• Config extension of ActiveRecord::Base takes place before the big_red_button is set


• Method methods are included in the User model before the big_red_button is set


• Method's def self.included is called after the big_red_button is set (meaning you can safely do conditional initialisation here based on the big_red_button setting)

How's that? Pretty cool stuff, but thankfully as I mentioned before, these details only really concern plugin authors and anyone who just loves to read dynamic ruby code.

There's much more to authlogic that what I've discussed here of course (and RPX). Perhaps good fodder for a future post? Let's see..


Soundtrack for this post: Because it's There - Michael Hedges

I've been using rails with the Twitter REST API of late, using the oauth gem as the base. It works well, but keeping up with the API changes can be a challenge!

In the recent update to OAuth 1.0a, there were two critical changes required:

Web-apps should specify the oauth_callback

Through trial-and-error, I found that if you don't explicitly specify the oauth_callback when going through the authorization process, twitter will halt at the PIN page (behaving as if you are using a client application). That's easily fixed..

request_token = consumer.get_request_token( :oauth_callback => TWOAUTH_CALLBACK )
session[:request_token] = request_token.token
session[:request_token_secret] = request_token.secret
# Send to twitter.com to authorize
redirect_to request_token.authorize_url

NB: the root cause is that oauth 0.3.5 sets "oob" as the oauth_callback if you don't explicitly set it. This triggers the twitter desktop PIN flow.

Include the oauth_verifier when exchanging the request token for an access token

Next, the major change in 1.0a was to add an oauth_verifier parameter. Twitter sends this back to you after the user has authorized access, and you need to include this parameter when exchanging the request token for an access token.

request_token = OAuth::RequestToken.new(consumer, session[:request_token], session[:request_token_secret])
access_token = request_token.get_access_token( :oauth_verifier => params[:oauth_verifier] )

An example application

I've created a minimalist application that demonstrates the twitter API with OAuth 1.0a in rails. I've set this up to run at heroku.

The source is at github for all to share: http://github.com/tardate/rails-twitter-oauth-sample/tree/master

And there's a running demo site at http://rails-twitter-oauth-sample.heroku.com.

So we've all been there .. a super-secure data centre where they ban wireless access while in the server room.


I recently had an acquaintance pulled up for using wireless while in one such place. Twice. I won't name where, because this issue knows no bounds.

It is a nice and reasonable rule from the security policy astronauts' perspective, because usually those responsible for the policy are not also accountable for operations. I presume the main concern is bridging networks and (intentionally or not) providing backdoor access.

They conduct audits and spot-checks, and on the surface everything looks great. If all you are concerned about is the paperwork, your job is done.

But in practice, and from what I have observed over the years, reality is a very different thing.

Unless all you are doing is bolting a server into a rack or plugging the fibre cables in, it is hard to get the job done these days without external network access.

• Maybe that is for research: consulting vendor guides or searching the knowledge bases (because no-one provides all the doc on disk anymore - it's on the web!)


• Or often you need to test the system you are configuring or diagnosing, and that can only be done from "outside" (SSL termination at an external-facing load-balancer for instance).


• Or, in this Web 2.0 world, you need to collaborate with colleagues to get the job done. Skype or IM to get hold of the expertise needed for the task at hand.


• Worse still, you have an "escort" policy, but a simple request to get in or out of the data centre is meet with abuse, recalcitrance or outright hostility from the people who are meant to escort you (like it's not their job!)

All these factors increase the frustration of SEs the world over, in the face of data centre policies that treat IT as if it were like installing an air-conditioner.

Now what happens when the threshold of pain is pushed up and up like this? At some point, the immediate pain (can't get to metalink ) exceeds the potential future pain (maybe I'll get caught using wifi).

And, dear data center security experts, happens next?

Human nature takes over. Before you know it, you have a feral group of wifi/bluetooth/3G connected people running around your DC.

The worst part is that you have pushed the behaviour underground, where it is truly uncontrolled. In being secretive, people are breaking the most significant security prohibitions of all: bridging networks. Sorry, you don't know how much it goes on. (personal aside: yes, I admit I have, in the past, used wifi in a non-wifi DC. But being the conscientious and security aware guy that I am, I was always quite anal about disconnecting from the DC network before getting on wifi. Not that anyone knew. And if they did, my reward would have been ... a punishment!!)

So what approach would an enlightened, modern data center manage take? I would sleep much better at night if I:

• Had an open wifi usage policy to bring the practive into the light of day. Maybe tables running between your racks for wifi-connected laptops (bolt them to the desk if you like, with a CCTV overhead), while direct network/server access had to be done rack-side.


• Educate on responsible wifi use. Make sure people understand the risks of bridging nets and make it clear its OK to be on wifi, but not ok to bridge.


• And have a clear understanding with my internal staff that "escorting" is not an interruption to the work they are doing, it is a vital task that will be rewarded.

Fundamentally, this means I would need to reconsider how I defined my job as a data centre manager: I'm not a slave to a policy handed down from upon high, my job is to implement and enforce the best procedures possible that both enforce the policy goals, while providing excellent customer service. Achieving this may mean I need to think a little out of the box, even be a little creative and pragmatic.

Now I should be clear that in writing this I am not condoning anyone who breaks a clearly published policy not to use wifi in a data center. On the contrary, if you have to work in such a place, I'd say stick to the policy, and drive the escorts nuts as you go in, out, in, out and in again to get the job done. Demand a full time escort if you need it.

My real message is to anyone with authority over security policies and their application: recognise that a policy on paper is worth exactly the cost of the paper unless you have taken into consideration the human factors involved and done your best to ensure that your procedures and environment are optimally designed to encourage the very best behaviours, and not the ones you most want to avoid.

Anyone have data centre security horror stories to share? I would love to hear about them! Better yet, how you manage to get around the stupidity, yet stay "legal".

Note to self: Yes! managed to navigate the various OpenID resources for rails and managed to successfully setup OpenID with restful_authentication on Rails 2.1.

There are a few tricks to be aware of. Prompted by a question on stackoverflow.com, I thought I would post my notes here.

Installing restful_authentication

Usually, you will be plugging open_id_authentication into your app's identity management framework. One of the most popular - and the one I've been using of late - is restful_authentication.

Getting restful_authentication working seems to require a few tweaks however - at least for the latest version found up on github.

Firstly, I've had no success directly installing it using the plugin script like this:

ruby script/plugin install git://github.com/technoweenie/restful-authentication.git

Rather, I've had to manually clone the github repository and manually setup the plugin directory:

$ git clone git://github.com/technoweenie/restful-authentication.git
$ mv restful-authentication/ myapp/vendor/plugins/restful_authentication
$ rm vendor/plugins/restful_authentication/.gitignore
$ rm -fR vendor/plugins/restful_authentication/.git

Note that I'm cleaning up some of the git bits, and also changing the plugin directory name to use an underscore rather than a hyphen (Rails usually complains to me otherwise).

Setting up restful_authentication is then pretty straight-forward:

$ mkdir lib
$ ruby script/generate authenticated user sessions
$ rake db:migrate

Note: if you don't already have the 'lib' directory in your application, it must be created first, otherwise the generator will fail.

Installing open_id_authentication

Ryan Bates' Railscast on Openid is the best thing I've found to follow. Even though it was recorded with Rails 1.2.3, I've been able to successfully follow the tutorial with Rails 2.1.0. The only point to note is that for:

gem install ruby-openid

I installed 2.1.2, rather than the 1.1.4 used in railscast.

Installing open_id_authentication is then a doddle.

$ ruby script/plugin install open_id_authentication

Follow the Railscast from this point to integrate OpenID with restful_authentication.

Using restful_authentication on heroku

The plugin installation problems mentioned above also mean that you need to use a few tricks to get it working in a heroku-hosted application. I've found it best to clone your heroku app and add the restful_authentication plugin locally, and then git push it back to heroku when done.

I have been playing around with OpenID recently and considering its significance. OpenID offers a "single digital identity .. you can login to all your favourite websites", and its adoption is rapidly accelerating especially since services like Yahoo and Blogger have added OpenID support to the many millions of existing user accounts.

Maybe I'm missing something here, but I am surprised by the lack of attention OpenID is getting in the enterprise context.

And when it is considered, it is often as an either/or proposition. As Nishant Kaushik writes in his excellent identity blog:

.. simple web applications with minimal needs could get away with simply supporting OpenID. But that should not be confused with not requiring a full-fledged identity services infrastructure where appropriate.

I think this is somewhat misdirected; certainly not the whole story. OpenID-enabling existing applications for an external audience is already a trivial exercise. It's a simple API, and plugins or toolkits are available for most programming environments. I think the much bigger deal is looking at OpenID from the opposite perspective - using enterprise security infrastructure to support OpenID authentication.

In my view, OpenID is key to unlocking the true potential of "Enterprise 2.0", which is what I wanted to discuss here to try and explain my thoughts and get some feedback.

It may also lead us to think more clearly about what Enterprise 2.0 really is. This is the current definition up on wikipedia:

Enterprise social software, also known as Enterprise 2.0, is a term describing social software used in "enterprise" (business) contexts..

The "social" nature of Web 2.0 tends to get the headlines, and hence by simple transference must be to basis of Enterprise 2.0. Right?

However, I'm not convinced.

Expecting Enterprise 2.0 success by simply adopting social networking features of Web 2.0 just seems a little naive. For a start, it implies and requires phenomenal change in the social and organisational fabric of a company to get off the ground, and there is no guarantee the benefits will be worth the pain of change. In many organisations it may just be too much, too soon, and fail completely.

Much as I love them, I don't even think "mashups" will be the killer app for Enterprise 2.0.

I think the key is a much more mundane aspect of Web 2.0 that gets lost in the facebook frenzy: the simple fact that users are being exposed to just so darn many useful tools in the ever increasing range of web applications (or Rich Internet Applications aka RIA).

We see unprecedented utility in the applications on offer, approaching what we expect from desktop or dedicated applications. And there is an incredibly low barrier to participation - you can sign-up within a minute and with usually no immediate associated cost.

So my main proposition is that the quick win for Enterprise 2.0 is for companies exploit the RIA boom. Spend your time figuring out how to exploit the burgeoning Web Application offerings. Do NOT waste your time scheming how to clamp down on usage, or on replicating the tools yourself.

The real and immediate benefits include reduced IT spend, better utility and happier users .. and set the stage for moving to the world of "Advanced Enterprise 2.0" with mashups and social networking for example.

The caveat of course is that the enterprise must ensure that matters of availability, data protection, confidentiality and privacy are not compromised in making such a move.

But this presents a dilemma for the enterprise. A tough choice between undesirable outcomes:

1. ban and fore-go the benefits of adopting external Web Applications for enterprise use;


2. allow their use, but lose control of the data, identities and secondary use derived from using such applications;


3. or be faced with re-implementing all those cool features within the firewall (and risk becoming disconnected from the external audience).

This leads us to the present state-of-the-art in Enterprise 2.0, which must necessarily work around the constraints of the corporate boundary.

• Some companies are adopting External Web Applications where they address a largely external audience (a good example is the official Oracle Wiki which runs on wetpaint). But here they remain disconnected from internal systems.


• For internal adoption of Web 2.0 technology, IT departments are often re-implementing all the cool stuff inside the firewall.
  
  The CEO wants a blog? Customer support want to setup a wiki? Sure, we can install it. Where install means friggin' around for a few months to select and acquire the software, integrate it with the standard enterprise security/monitoring/hosting/blah environment, customise it to the corporate branding etc etc.
  

Toto, I've a feeling we're not in Kansas any more.. suddenly Enterprise 2.0 doesn't seem so exciting.

And I think it denies the dirty little secret that I bet exists in most organisation: your employees are already using these services for business purposes!

Using a personal credential for business purposes on an external service (whether OpenID or not) presents a whole range of challenges:

• It is a provisioning nightmare. What happens when the employee leaves? The company doesn't control the account, so it can't be disabled. Whether you can remove access from any corporate data held in the external service depends totally on the application itself and how it was setup.


• For the individual, there is a concern about keeping their professional and private lives appropriately separated. Too easy for your tweets to end up in the wrong hands in the wrong context.

So what's a girl to do? I'd suggest the answer is pretty obvious - we need corporate identities that can extend beyond the boundaries of the the organisation in a safe and controlled manner. This was the intention with SAML, but adoption has been slow - I suspect hindered by the complexity of its WS-Deathstar burden - and now OpenID is streets ahead in terms of acceptance (an interesting parallel to the adoption of SOAP v. REST for SOA Web Services).

In other words, the key to all of this IDENTITY.

Imagine for a moment the ideal world. I would have a corporate identity that works transparently within the enterprise and also for useful external services. And I could keep this quite separate from my personal identity (even though I may use some of the same external services on my own time).


The question now is whether we are far from being able to achieve this? I think not...

The call to Enterprise Identity Management Stack providers..

That means Microsoft, Oracle, IBM, Sun and so on.. the companies that produce the security software that is managing your enterprise identity every time you sign in to an enterprise application.

Many of these guys are members of the OpenID Foundation, but on the whole it is hard to find clear statements of direction at the moment, and the initial focus has been around demonstrations of how they can use credentials from other OpenID providers.

We need to see two things in particular:

• OpenID provider support in their core identity management stacks, so that enterprise credentials can be used as OpenID credentials under the control of the company (e.g. they can be disabled when the employee leaves). Call that part of a "Service Oriented Security" strategy if you like, just make the option available;-)


• Include that ability to blacklist/whitelist sites that the credentials can be used for.
  
  There will always be good reasons why certain Web Applications may be off limits for corporate use. For example, a law firm may not be able to use Google Documents because of jurisdictional concerns.

Dion Hinchcliffe presented the case well in the recent article "openid: The once and future enterprise Single Sign-On?", along with a great visualisation:

The call to Web Application providers..

Firstly, the big guys like Yahoo! need to support third party OpenID credentials. This seemed to be the main thrust of Hinchcliffe's article. I hope this is just a matter of maturity and not business model pig-headedness, but to offer OpenID sign-in only if your OpenID provider is the same company is not really in the right spirit of things!

More generally applicable however is a major consideration for any Web Application provider that wants to target the enterprise market: addressing the security issue with OpenID support only opens the door. To step through, you must be ready to meet the specific demands of an enterprise customer.

First of these must be data ownership. I didn't want to focus on it in this post because I think it is an orthogonal concern to security. But if you want enterprise customers, be prepared to to consider requirements such as:

• Access to all data owned by the company's users on the service. For backup, export, and analytics.


• Audit and compliance


• Service levels

The call to Enterprise Software vendors..

The idea of a "Web 2.0 appliance" is I think very attractive to many organisations: an easy on-ramp to the space without the need to build up a whole range of specialist skills within the company. In the appliance category I would include Oracle WebCenter and the new IBM Mashup Center. Needing OpenID authentication support in these products is of course a no-brainer in order for them to have appeal in cases where you wish to mix internal and external user audiences.

Enterprise Software vendors need to go further however. The enterprise of the future, which expects to operate seamlessly on the web, will need the ability to "export" corporate identity to the world. Right now, that means capabilities like having OpenID provider support in your Enterprise Identity Management services.

Given the state of consolidation in the industry however, OpenID may present a dilemma for vendors who are faced with the prospect of OpenID support in their Identity Management stack cannibalizing sales of their application suites, as users start to exploit external Web Applications.

But to be recalcitrant and stand against the move to OpenID will only accelerate the onset of a winner-takes-all showdown in the enterprise applications market.

Personally, I believe the showdown is inevitable: with the combined pressures of RIAs, cloud computing, oligopolistic pricing and increasingly sophisticated open source alternatives, I think it is quite likely we will see the enterprise software market go supernova within the next 5 years i.e. blow itself to pieces after a few more years of consolidation ... but that's a topic for another post perhaps;-)

The enteprise software vendors that survive will be the ones who truly embrace being open, and that includes OpenID.

Conclusions?

Well, I wonder if I've convinced anyone?

To me it seems that the ability for enterprises to add OpenID provider support to their security infrastructure will be the key to unlocking the full potential of Enterprise 2.0.

Until such a facility is available from the mainstream Identity Management vendors, we will just be messing around on the fringe.

NB: edited for clarity 9-Sep-2008

The other day I added my voice to the call to end the perfidious practice of social networking sites requesting your email password.

In the discussion I made an off-hand reference to a fictitious site called iHazYrCreds. Well, it's not fictitious any longer ;-) For better or worse, you can now visit iHazYrCreds.tardate.com to find out more about the common password traps to avoid.

I'd like to see the day when asking for an email password in order to "import contacts" is deemed totally unacceptable (and negligent professional practice).

I would also welcome any moves by the big email providers (google, yahoo etc) to explicitly outlaw such use in their terms of service. I'm no lawyer, but I believe it is debatable whether it is already a violation.

As usual, Jeff cuts to the heart of the matter on Coding Horror when calling out Yelp for the astonishingly evil and unconscionable act of asking users to hand over their email passwords.

I am not sure who started this, but it has somehow scarily become accepted practice, especially among the social networking sites. Facebook, LinkedIn, Plaxo ... they all do it, and seem to think that waving some privacy mumbo-jumbo 'but you can trust US!' makes it OK. Some are particularly heinous, like Tagged, which obscure the fact that handing over your email password is optional.


As many have pointed out (see the comments on Jeff's post), this is a lazy solution to a problem that is solvable in ways that do not need to compromise user security.

Facebook, LinkedIn - these guys should know better. And I think have an obligation to do better, especially since it is becoming more and more common for a social networking site to be an individual's first experience on the net. While the old hands may have well-ingrained security awareness thanks to the evangelizing efforts of people like Steve Gibson and Leo Laporte on the Security Now! podcast, we have a whole new generation of users being taught exactly the wrong thing thanks to the misguided and irresponsible acts of the social networking sites that are requesting email passwords to be handed over.

The proliferation of this perfidious practice must be reversed! A good first step is to heap professional scorn on anyone associated with developing such a feature. Shame!

Yes, it's time for some house cleaning!

One of my favourite little hacks is how to add reCAPTCHA to Oracle SSO, which I wrote about last year. I've now finally got around to setting it up with its own sourceforge project.

OssoRecaptcha is a demonstration of integrating the CAPTCHA service from recaptcha.org with Oracle Single-Sign-On. It can be used in production OSSO deployments, and also as an example of integrating any 3rd party authentication system with OSSO.

SourceForge.net Logo

I've refrained from reposting xkcd for a while, but this is just too good! So where did you leave your key-ring last night, huh?


Happy New Year!

Recurity Labs GmbH have a very interesting post on their investigation of the new password algorithms in Oracle Database 11g.

I did a double-take when I saw the set of hashing algorithm identifier values (used as a parameter to the ztv2ghashs hashing function)..

0xf00d means: Use MD4 
0xdead means: Use SHA1 
0xbeaf means: Use MD5 

Ah! It's an oldie but a goodie. Brings back schoolboy memories of getting your LCD calculator to spell out well-known petroleum companies.

And good to see that even in the depths of Oracle Development there's a willingness to do something a little special, for no reason other than because they can.

I've blogged previously about playing with the reCAPTCHA service in Perl. Seriously cool! Not because it's foolproof - it isn't - but the side-effect of helping to digitize old documents and books is a truely great idea.

I'm starting to see reCAPTCHA more often now. Bex Huff put it in his comment form, and blogged about it (though I can't find his posting anymore. Update: link from Bex, thanks!). But I haven't seen it used with Oracle SSO yet ... sounds like an interesting weekend project!

So I had a poke around, and like to share the solution. Although I am going to integrate the recaptcha service, you could use the same approach to add any 2nd or 3rd factor to the SSO authentication process. End result is the reCAPTCHA appearing and working in the Oracle SSO login page. The sample here is based on the Oracle Collaboration Suite 10g branding:


The sources for my example are available as OssoRecaptcha-1.0-src.zip. See readme.txt in the zip for more detailed instructions and discussion.

There are basically two things we need to take care of to integrate reCAPTCHA. First, customise the login page to render the captcha challenge. Secondly, we need to insert a custom authenticator to handle the captcha validation before the standard authentication.

I've used the ReCaptcha Java Library released by Tanesha Networks to simplify things.

Customising the Login Page

This is the simplest part, and pretty well documented in "Creating deployment-specific pages".

The following code renders the captcha challenge and just needs to be included in the login page at an appropriate point.

<%
// create recaptcha
ReCaptcha captcha = ReCaptchaFactory.newReCaptcha(RecaptchaConf.RECAPTCHA_PUBLIC_KEY, RecaptchaConf.RECAPTCHA_PRIVATE_KEY, false);
String captchaScript = captcha.createRecaptchaHtml(request.getParameter("error"), null);
out.print(captchaScript);
%>

RecaptchaConf is a class included in the sample to hold your site-specific reCAPTCHA keys that you can easily get by registering at http://recaptcha.org.

Customising SSO Authentication

We have a simple task: intercept and evaluate the catpcha response before allowing standard SSO authentiation to proceed. Simple, yet not exactly documented unfortunately. The documentation for "Integrating with Third-Party Access Management Systems" is almost what we need to do, but not quite.

The approach I have taken is to sub-class the standard authenticator (oracle.security.sso.server.auth.SSOServerAuth) rather than just implement an IPASAuthInterface plug-in.

The only method of significance is "authenticate", where if the captcha response is present, we evaluate it prior to handing off to the standard authentication.

public IPASUserInfo authenticate(HttpServletRequest request)
throws IPASAuthException, IPASInsufficientCredException
{

SSODebug.print(SSODebug.INFO, "Processing OssoRecaptchaAuthenticator.authenticate for " + request.getRemoteAddr());
if (request.getParameter("recaptcha_challenge_field") == null) {
throw new IPASInsufficientCredException("");
} else {
// create recaptcha and test response before calling auth chain
ReCaptcha captcha = ReCaptchaFactory.newReCaptcha(RecaptchaConf.RECAPTCHA_PUBLIC_KEY, RecaptchaConf.RECAPTCHA_PRIVATE_KEY, false);
ReCaptchaResponse captcharesp = captcha.checkAnswer(request.getRemoteAddr(),
request.getParameter("recaptcha_challenge_field"),
request.getParameter("recaptcha_response_field"));
SSODebug.print(SSODebug.INFO, "ReCaptcha response errors = " + captcharesp.getErrorMessage());
if (!captcharesp.isValid()) {
throw new IPASAuthException(captcharesp.getErrorMessage());
}

return super.authenticate(request);
}
}

A couple of things to note:

• This method is first called prior to the login challenge to see if you are already authenticated, hence the check for a captcha response before boldly going ahead to authenticate
• The specific exception messages raised in this class seem to get "lost" by the time the handler returns to the login page (at which point you always seem to have a generic failure message). In other words, users will basically just get told to try again. I haven't found a way around this yet.
• See the example usage of SSODebug to log messages which will appear in the SSO log (as configured in ORACLE_HOME/sso/conf/policy.properties)
• We'll deploy the custom class into the OC4J_SECURITY container, rather than to $ORACLE_HOME/sso/plugins since it seems plugins get a limited environment that does not include all of the required support classes. Deploying to OC4J_SECURITY avoids this problem.

Deployment

The most robust approach to deployment is to explode, modify and the rebuild the OC4J_SECURITY EAR file ($ORACLE_HOME/sso/lib/ossosvr.ear) once you are confident everything is working fine. I haven't covered how you do that here however.

Rather, I'm deploying the sample directly into an existing OC4J_SECURITY container. Note that with this approach, if you ever redeploy the OC4J_SECURITY application (which can happen during an upgrade or patch for example), then your changes
would be destroyed.

There's an Ant build script included in the sample that takes care of the details, but is pretty straightforward...

Firstly, two copy operations:

1. Copy the login page to $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/
2. Copy the supporting jar files to $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/WEB-INF/lib/

Second, the authenticator configuration is governed by $ORACLE_HOME/sso/conf/policy.properties.

MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth
# replaced with:
MediumSecurity_AuthPlugin = com.urion.captcha.OssoRecaptchaAuthenticator

Finally, we are ready to restart the OC4J_SECURITY container

opmnctl restartproc process-type=OC4J_SECURITY

and test out the customised login. Try...

http://you.site:port/oiddas

Give it a go! Love to hear from anyone who deploys reCAPTCHA on a production Oracle Portal or Applications site for example.

Postscript: Patrick Wolf obviously had a weekend free also, and has now posted a solution for adding reCATPCHA to APEX ;-) Cool!

Postscript 2008年06月03日: I finally got around to setting this up with its own sourceforge project.

Security Now! #101 with Steve Gibson and Leo Laporte covered the deceptively simple challenge of differentiating human from non-human automated clients (great podcast as always .. check it out). Commonly this is done with distorted text like the sample on the right.

The Official CAPTCHA Site has a wealth of information about this field, including discussion of the relay attack that has the potential to defeat any "are you a human?" test (because it enrolls unwitting human accomplices to do the work).

The coolest piece of work though is the reCAPTCHA project. This is a project of the School of Computer Science at Carnegie Mellon University, and it provides a public service for plugging-in a CAPTCHA to your site. But unlike other systems that are just wasting 10 seconds of your time, this system is actually digitizing public domain archives at the same time (getting you to fix the translation of words that have defied the best OCR software)!

Perl is one language that you can easily use reCAPTCHA with, using Andy Armstrong's Captcha::reCAPTCHA module.

After installing the module, it just takes a few minutes to register your site and setup a test page. I built a quick reCAPTCHA cgi in perl .. you can try it out here (sorry, currently may find it offline but get the script source here: myReCaptcha.pl. I think I spent 10 minutes setting this up, and then an hour playing with it;) All in the name of digitizing historical works...

But I'm afraid the humour archive has the best captcha ever ..

A failing OC4J_SECURITY process recently had me digging out an old script I had put together to test Oracle Application Server Single-Sign-On (OSSO) configuration.

How and where the OSSO server keeps its configuration is a wierd and wonderful thing. The first few times I faced OSSO server issues I remember digging through a collection of metalink notes to piece together the story. It was after forgetting the details a second time that I committed the understanding to a script (validateSso.sh).

Appreciating the indirection used in the configuration is the key to understanding how it all really hangs together, which can really help if you are trying to fix a server config issue. Things basically hang together in a chain with 3 links:

1. Firstly, the SSO server uses a privileged connection to an OID server to retrieve the OSSO (database) schema password.

2. With that password, it can retrieve the SSO OID (ldap) server connection details from the OSSO (database) schema.

3. Thus the SSO Server finally has the information needed to connect to the OID server that contains the user credentials.

The validateSso.sh script I've provided here gives you a simple and non-destructive test of all these steps. The most common problem I've seen in practice is that the OSSO schema password stored in OID gets out of sync from the actual OSSO schema password. I think various causes of these problems, but the script will identity the exact point of failure in a jiffy.