|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 7
Messages: 7
Messages: 7
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
OpenID: Great idea, bewildering consumer experience
"OpenID: Great idea, bewildering consumer experience" is a thorough document saying that OpenID ... might have some problems. Some of the issues are: the site for OpenID is geared to developers, not users; finding an OpenID provider is troublesome; users won't understand that an OpenID is a location, not an actual identification.
OpenID basically centralizes login processes by requiring that users provide a URL to a site that provides their identity. When the user needs to "log in" to a site that participates in OpenID, the site redirects to the URL the user provided, where the user logs in; the OpenID provider then redirects back to the original site, providing the user's identity.
The advantage here is that users can log in on one server - the OpenID provider - for all sites participating, instead of potentially having passwords for each site on which the user has a login ID.
There are OpenID providers available; one is http://openid.org/, for example. There are also programmatic providers, as specified on OpenID.net.
What do you think of the idea of OpenID? TSS is considering OpenID for its login authentication; good idea or bad?
Resources:
|
|
|
Message #238361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Good idea for sites like this
The problem sites like this have is that most visitors are not signed in and therefore have limited functionality, reduced incentive to come back, and less overall time on this site. You are competing with dozens of other sites and inevitably there's going to be users who don't bother to sign in. Yet some functionality like e.g. posting or storing preferences requires being signed in.
OpenID solves this problem by making it really easy for users to sign in. Upcoming browsers such as Firefox 3 are going to make it even easier. You can implement openid on top of existing user system so it doesn't replace or conflict with your existing security solution. Sounds like a good idea for any site with this problem. A no-brainer really.
The problem right now is decent support in popular CMS software. For example, openid enabling your blog currently requires quite a bit of hacking with half or non supported extensions/plugins to stuff like drupal or wordpress. I gave up on it for my own blog. If you have your own CMS like this site probably has, that is much less of an issue of course.
|
|
|
Message #238399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Single point of failure
I like the concept of OpenID, but from a technical point of view I think it's a single point of failure. When your OpenID Provider is having trouble and the services you want to access don't provide any alternative login, you are in trouble too. So for me it's only a solution if the provider is really reliable or services have a backup/alternative login service.
|
|
|
Message #238402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Key to OpenID...
The key to OpenID success will be whether many large sites start to use it. The reason the OpenID site is for developers is that they want web site developers to incorporate OpenID hooks. At Hyperic, we're considering this, because it's a win for users if they can just use their openid name. Dev tools have progressed to the point where implementation is easier now. I wonder how many other sites are considering it? I've heard whispers of many evaluations, but I've yet to see major sites move to it.
-John Mark
Community Manager
Hyperic, Inc.
http://www.hyperic.com/
|
|
|
Message #238432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
nonsense
As a consumer you can pick your openid provider like your email provider. On top of that (unlike email) there is notion of openid delegation which allows you to actually switch provider and keep the same openid. So basically you have quite a bit of flexibility in case your preferred provider proves to be so incompetent that you run into this hypothetical non-issue. Of course the issue is not unique to openid and you have exactly the same problem with any identity solution: if the IDP goes down you can't authenticate. Of course the delegation feature is rather unique to openid so you actually gain flexibility here.
Compare this with e.g. facebook where the whole ecosystem depends on facebook's php based system not failing. Skype which had a nice authentication issue the other day might have been better off with a decentralized authentication system like openid.
Trust and security are of course important. Whitelisting of providers solves this and is perfectly legal under the openid spec. This is what for example AOL is planning to do when they openid all their services in the next few months (they are already a provider for 60 million users). If you want to access their service, you will have to use or delegate to an openid they trust.
|
|
|
Message #238468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: nonsense
As a consumer you can pick your openid provider like your email provider. On top of that (unlike email) there is notion of openid delegation which allows you to actually switch provider and keep the same openid.
But to be fair, your OpenID name is simply a URL, and the delegation is based upon data provided within the document FROM that URL.
So, even though you might be using something ultra reliable (like, hypothetically, openid.google.com) as your provider, if your OpenID URL, say jiles.vangurps.com, is hosted at "$2/year! Free Bandwidth! CheapassHosting.com!", then that's your point of failure. It suffers from the weakest link syndrome.
Mind, I believe the system can be reliable. I think it would be nice if some large provider (google, amazon, yahoo) would let folks host OpenID subdomain URLs across their farm of servers (round robin DNS load balanced etc.). You own the domain, they host it. And then you can pick whatever combination of OpenID certificate host and OpenID credential provider you like.
That's my minor nit about the system. That it's a URL. That means unless I own my own domain, my global ID is at the mercy of some other company. Yet, maintaining a domain, paying for it, renewing it, bla bla bla, maybe something that we do ok, but not something Ma and Pa Kettle may well be wont to do.
But the AOL initiative is a good one -- all of their subscribers get an OpenID.
|
|
|
Message #238577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: nonsense
Maybe, or more likely you'll get 'sign in with Google/Yahoo' services built on openid from places like amazon, ebay, etc. This will be used to facilitate simple, more reliable transactions. People are already using those online email providers and have no intention of moving away from them.
Business can easily exchange user data in a reliable, widely adopted commercial format. When integrating openid servers with ldap, you can shutdown the account once and all external partner authentications will be dead too.
Justen Stepka
|
|
|
Message #238590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: nonsense
Maybe, or more likely you'll get 'sign in with Google/Yahoo' services built on openid from places like amazon, ebay, etc.
Well, if we can get any of these guys to port their account bases over to something like OpenID, I think that would be a great shift and that would "fix" the problem.
The clever part of OpenID is that the ID is simply a URL. And the URL provides the start of the credential chain.
I also like how is does delegation, in two ways. One, it delegates the actual ID server, but it also delegates the actual ID.
So, in theory, I make my own ID at (say) theserverside.com/users/will. I can then (assuming access) change that document to validate against the openid.google.com servers using my google.com/mail/will.hartung ID.
That means I can now identify myself to any OpenID site as theserverside.com/users/will, but using my google password. Now, it's not a "secret" by any means. Anyone can follow that chain, but it does give you the ability to consolidate and alias as time goes on.
So, that means that as long as an OpenID provider gives you the ability to change the servers and the delegates, and is willing to serve up the the minimal URL document, you don't have to make a commitment to any actual provider. Not quite cell phone number portability, but it's close.
We should also have the ability to somehow migrate IDs on destination sites. For example, whatever my account is here at TSS, I should be able to assign one (or several) OpenID accounts to the "Entity That Be Me Here".
This kind of flexibility will speed adoption. It means I can run over to OpenID.org and sign up there without worrying that it'll be some kind of horrible mistake in the future. Migrate to Google or Yahoo later, or even TSS. I mean, why shouldn't TSS be an OpenID server rather than just a consumer?
Once the meme explodes, and everyone is serving and consuming the OpenID, then things can settle down. But for now, since we can have some sense of portability, yet still maintain federated ID, I think implementation should be wide and liberal.
So, in summary, IMHO, TSS should:
a) implement OpenID for authentication
b) offer OpenID services to its users for authentication for other sites
c) make available the proxy and delegate abilities within OpenID so that we can more easily transfer and move our identity around the bustling intraweb as OpenID settles out.
d) enable us to change or assign other OpenID URLs to our accounts here.
e) "default" our current logins to an OpenID login. For example, we currently use our email addresses. TSS can easily port all of the emails to an OpenID URL: theserverside.com/useremailid/willh@example.com. Then when "normal" TSS readers log in, the system says "That looks like an email, I'll silently convert it to an OpenID URL and toss them in to the TSS OpenID system". This gives TSS a single authentication system, but works for legacy users. And TSS basically shadows the "email" style, with a newer system that allows users to pick their ID (so their OpenID in the large isn't their email). And, ta da, OpenID enabled TSS working both as a consumer and as a server.
Someone (that ever present Someone -- you know who you are!) should build a Java WAR (and a PHP module, etc) combining OpenID services with the user management facilities and a sample schema that any site can easily incorporate, and set the baseline for patterns and Best Practice. Accepting OpenID, providing OpenID, exposing delegate information, user preferences for exposure of personal information (on a site by site basis), accepting and registering multiple OpenIDs for a single account for login. The whole kit.
Make a standard, easily integrated piece that's TESTED AND SECURE so that legacy, standalone sites can migrate in a day of integration and a week of testing.
Anyone who is maintaining users today may as well consume and provide OpenID services. Then this thing spreads like wildfire and Amazon, Ebay, Yahoo, Google et al basically have no choice but to follow suit.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
