Showing posts with label Identity Management. Show all posts
Showing posts with label Identity Management. Show all posts
Tuesday, June 22, 2010
The third-party authentication dilemma: does Facebook pwn my site?
I've argued for some time that it is crazy for most websites to have their own authentication (username/password) system these days.
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
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:
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:
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:
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
- 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
(追記) (追記ここまで)
Thursday, October 08, 2009
Rails authentication with Authlogic and RPX
The Singapore Ruby Brigade had it's monthly meetup last night. Great discussions as always, and how can you complain when you get to carry on over maggi mee goreng supper until the wee hours;-)
Here are the slides from my talk about Rails authentication options in general, and specifically why and how to use RPX with Authlogic (using the Authlogic_RPX gem I released last week).
(追記) (追記ここまで)
Sunday, September 27, 2009
Released: Authlogic_RPX gem, the easiest way to support multiple authentication schemes in Rails
I've just made Authlogic_RPX public for the first time and invite any rails developers to take a look. It's a ruby gem that adds suppport for RPX authentication in the Authlogic framework for Ruby on Rails. With RPX, you get to support all the common authentication schemes in one shot (Facebook, twitter, OpenID etc).
Authlogic_RPX is available under the MIT license, and a number of resources are available:
The best place to find out more is the README, it contains the full background and details on how to start using it. Feedback and comments are welcome and invited (either directly to me, or you can enter them in the github issues list for the project).
Authlogic_RPX plugs into the fantastic Authlogic framework by Ben Johnson/binarylogic. Authlogic is elegant and unobtrusive, making it currently one of the more popular approaches to authentication in Rails.
RPX is the website single-sign-on service provided by JanRain (the OpenID folks). It complements their OPX offerings I wrote about recently. RPX abstracts the authentication process for developers and provides a single, simple API to deal with. This approach is great for developers because you only need to build a single authentication integration, and leave to JanRain the messy details of implementing and maintaining support for the range of authentication providers: OpenID, OAuth, Facebook Connect, AOL, Yahoo, Google, and so on..
If you want to learn more, there was recently a great podcast interview with Brian Ellin from JanRain on the IT Conversations Network: RPX and Identity Systems
Authlogic_RPX is available under the MIT license, and a number of resources are available:
- Authlogic_RPX source repository: github.com/tardate/authlogic_rpx
- Live Demonstration Site: rails-authlogic-rpx-sample.heroku.com
- Demonstration site source repository: github.com/tardate/rails-authlogic-rpx-sample
The best place to find out more is the README, it contains the full background and details on how to start using it. Feedback and comments are welcome and invited (either directly to me, or you can enter them in the github issues list for the project).
Authlogic_RPX plugs into the fantastic Authlogic framework by Ben Johnson/binarylogic. Authlogic is elegant and unobtrusive, making it currently one of the more popular approaches to authentication in Rails.
RPX is the website single-sign-on service provided by JanRain (the OpenID folks). It complements their OPX offerings I wrote about recently. RPX abstracts the authentication process for developers and provides a single, simple API to deal with. This approach is great for developers because you only need to build a single authentication integration, and leave to JanRain the messy details of implementing and maintaining support for the range of authentication providers: OpenID, OAuth, Facebook Connect, AOL, Yahoo, Google, and so on..
If you want to learn more, there was recently a great podcast interview with Brian Ellin from JanRain on the IT Conversations Network: RPX and Identity Systems
(追記) (追記ここまで)
Monday, September 07, 2009
OPX: Almost, but not quite, what we need to get the Enterprise on the cloud?
A post today by Dana Gardner - Cloud adoption needs a support spectrum of technology, services, best practices - got me thinking again about the importance of a universal "business" identity to make cloud computing a reality for the enterprise sector.
I wrote some time ago about OpenID - the missing spice in Enterprise 2.0? The basic premise being that for Enterprises to truely exploit the exploding cloud offerings, they first need a way of exporting business identities to the web.
While most businesses at the moment have not officially adopted cloud services, the reality is that cloud services are already penetrating all organisations - whether it is sales people keeping touch with contacts on twitter, pre-sales engineers collaborating via google docs, or consultants using drop.io to get around email size restrictions when sending documents to partners and customers.
The issue I wrote about in my previous post is that we need to wake up and recognise that the flood gates are already open: we are mixing personal and business identities in a tangled mess that is becoming harder to unravel each day.
The risk for business? While free cloud services are giving a tactical boost, when employees move on, they will take all of their cloud-attached contributions with them. At best, a relationship management issue to recover, at worst you find all kinds of SOX and compliance issues lurking to bite back.
Now pretty much all IT-enabled organisations have a form of internal directory and authentication service (be it AD or an LDAP variant). My premise is that organisation do want to be able to exploit google apps, Zoho or Salesforce, but when doing so, we should care deeply that employees apply their business (not personal) identity to any transaction.
From a technologist's point of view, this essentially means that we want to take our internal authentication processes and expose them in a very controlled way on the web. SAML was the deathstar standards approach, but I think in reality OpenID has won the hearts and minds at this point.
One of my projects-on-the-drawingboard is an OpenID provider designed for the Enterprise - a drop in module that allows you to export internal identities from AD or LDAP in a very controlled and auditable way. It is still on the drawing board and has been for ages - if others are interested in making it reality, drop me a line.
However, I think the options may already be available. I am talking about janrain's OPX, although I'm not sure that any of their offerings are really designed for this specific scenario. Even the OPX:Groups offering, which seems to be the closest seems to require establishing a new directory of identities rather than leverging your existing assets. I may be wrong... still investigating and certainly appreciate a steer in the right direction.
I wrote some time ago about OpenID - the missing spice in Enterprise 2.0? The basic premise being that for Enterprises to truely exploit the exploding cloud offerings, they first need a way of exporting business identities to the web.
While most businesses at the moment have not officially adopted cloud services, the reality is that cloud services are already penetrating all organisations - whether it is sales people keeping touch with contacts on twitter, pre-sales engineers collaborating via google docs, or consultants using drop.io to get around email size restrictions when sending documents to partners and customers.
The issue I wrote about in my previous post is that we need to wake up and recognise that the flood gates are already open: we are mixing personal and business identities in a tangled mess that is becoming harder to unravel each day.
The risk for business? While free cloud services are giving a tactical boost, when employees move on, they will take all of their cloud-attached contributions with them. At best, a relationship management issue to recover, at worst you find all kinds of SOX and compliance issues lurking to bite back.
Now pretty much all IT-enabled organisations have a form of internal directory and authentication service (be it AD or an LDAP variant). My premise is that organisation do want to be able to exploit google apps, Zoho or Salesforce, but when doing so, we should care deeply that employees apply their business (not personal) identity to any transaction.
From a technologist's point of view, this essentially means that we want to take our internal authentication processes and expose them in a very controlled way on the web. SAML was the deathstar standards approach, but I think in reality OpenID has won the hearts and minds at this point.
One of my projects-on-the-drawingboard is an OpenID provider designed for the Enterprise - a drop in module that allows you to export internal identities from AD or LDAP in a very controlled and auditable way. It is still on the drawing board and has been for ages - if others are interested in making it reality, drop me a line.
However, I think the options may already be available. I am talking about janrain's OPX, although I'm not sure that any of their offerings are really designed for this specific scenario. Even the OPX:Groups offering, which seems to be the closest seems to require establishing a new directory of identities rather than leverging your existing assets. I may be wrong... still investigating and certainly appreciate a steer in the right direction.
Subscribe to:
Comments (Atom)