Create a Silverlight OpenID control
A Silverlight 2.0 control for accepting OpenID logins would be really cool.
http://code.google.com/p/dotnetopenid/issues/detail?id=217
Adminblog.nerdbank.net
(Admin, DotNetOpenAuth)
shared this idea
Until a proposal can be made (or I can think of one) that describes how a Silverlight control can be written securely and in a useful way, no plans will be made to implement this.
1 comment
-
When it comes to security, you MUST start by assuming the client has been completely hijacked or substituted. For instance, when that request comes in from your Silverlight app/control to the server saying "Ok, this user is X and he wants to do Y", how can you possibly trust it? Even if you "signed" it on the client side to prevent forgery, since the signing code is already on the client, it can be studied, the secrets stolen, and the signature forged.
The way sessions work w/o Silverlight is that the server does the OpenID authentication verification, and then the server issues an HTTP cookie to the client that the client uses to say "I'm X, and I want to do Y". But the key that makes it work it that the server issued that cookie in the first place, signing it or whatever, and therefore can trust it.
Now, you COULD do SOME OpenID work on the client. For example, you could perform identifier discovery from within Silverlight in an effort to make login a bit faster, but then you're left with only a couple of options. Either a redirect or a popup window must follow in order to allow authentication to take place. A redirect would take out your Silverlight control because the page is gone. A popup seems to be the way things are going though, so let's assume you're using a popup so that your Silverlight control stays alive during authentication. When the positive assertion (successful auth) comes back from the Provider, what can the Silverlight control do with that? Well, it could validate the signature on the assertion itself, but since there's a nonce in there that would invalidate it so your server couldn't double-check. So the way I do it with my AJAX control is that the AJAX control blissfully assumes the positive assertion isn't forged until it needs to access a resource from the web server. Then it sends the positive assertion along with the request to the server so the web server can then validate the positive assertion, and send the protected resource and an HTTP authentication ticket cookie down to the client.
Now you have a couple of options if you go this route: you can go with what's called stateless (or 'dumb') mode, meaning your web server will always have to send an extra message to the Provider to verify the signature, or you can use stateful mode so the web server can verify the signature immediately. But stateful mode would require that even if your Silverlight control did the discovery on its own, it would have to communicate with your server to find out which association handle to use in the checkid_setup (auth request) message.
So the long and short of it is... you haven't gained any speed increase, and you haven't avoided the need for a popup window or redirect. Perhaps the user experience looks more slick because of whatever Silverlight rendering you might be doing, and that's definitely worth something. But if you go that route, since making it complicated and doing OpenID auth on the Silverlight side doesn't really buy you anything in my opinion, just keep your control simple UI level, and let the server do all the work using tried, proven, and tested OpenID libraries that run on the server.
Getting OpenID *right* is a huge task, where "right" includes interoperability tested, security tested and reviewed, and feature rich. A Silverlight control UI would be a neat extra feature that DotNetOpenAuth may someday incorporate, but for the reasons I've listed above it's not likely to happen at least in the near future.
