I must be stupid, because all the articles I've seen on OpenID in ASP.NET have simply confused me on the issue. I'm pretty sure I understand the concepts involved here, I'm just a little fuzzy on how things look on the back end side of things.
So a new user comes to my website and wants to create an account. Here comes the flood of questions:
Is the first step here to have him pick which openID provider he will use to sign in?
Do I prompt him for a user name on my system?
Do I need to tie him to the same openID provider each time he returns, or can he select a new provider each time?
What does the database look like here? Do I have his username in a table and that is linked to an openID provider?
What if the user doesn't have an OpenID account? Should I allow him to create a traditional account on my end, then expose myself as an OpenID provider?
What am I missing here? I'm usually pretty bright, but this area has been like kryptonite to Superman for my developer smarts. Thanks in advance!
Adam
This page is a step-by-step tutorial on implementing OpenId on a web site. I believe it will answer all your questions about the mechanics of adding it.
A Recipe for OpenID-Enabling Your Site
If the user doesn't have an OpenId I would just allow them to register 'normally', storing their credentials for local use. There is no need to add the extra complexity of becoming an OpenID provider unless you have a business case for that.
Dude, you're not alone. OpenID confuses everyone except the people who designed it, and even then, I'm not so sure it doesn't confuse them either since there are multiple OpenID providers and slight incompatibilities between them, depending on whose libraries you use.
Imagine the user is a sql "table" himself (that table contains his "credentials"), and you have a table of profile data specific to your website that you own. The OpenID url is a "foreign key" that you use to "join" these two tables. You must prove to yourself that he really owns that OpenID url before accepting it (or associating it with your private profile data). You're essentially "offshoring" the authentication portion of your site.
So ultimately, you use an openid client library that does the work for you on your website. They register as normal filling in "full name, "age," etc (whatever you want) but they provide an openid url instead of username/password. The library looks after verifying they really own it. You have to trust this library to do that. You then store all of your profile data with that openid. Done.
While you could offer your own openid provider, it's not worth it at this point. There are plenty out there already. What you could do though, is offer a traditional username/password INSTEAD of openid. The idea of openid is that your register ONCE with a provider, and then just prove you own that URL to any site that wants to use it to identify you (instead of username/password).
Make sense?
-Oisin
Related
My client has a request that he wants to login to ASP.net web application via Google account. As I have never done something like that I have some concerns.
What bothers me is that he wants to add roles (administrator, user) to specific accounts and this puzzles me because I'm not sure how to connect Google account data with my database. I assume that I won't be able to get the password or username that I could store to my own database.
Where to start?
Use OpenID. This is implemented in ASP.NET in the DotNetOpenAuth library. It includes samples for Google logins, and it's very easy.
The roles should work to. As you build up your user table, just add users to the appropriate roles.
Have a look at this:
http://www.asp.net/vnext/overview/aspnet/oauth-in-the-default-aspnet-45-templates
Scott Hanselman giving a quick overview of the OpenID features in .NET4.5. This might be a good starting point for you.
On MSDN:
http://blogs.msdn.com/b/webdev/archive/2012/08/15/oauth-openid-support-for-webforms-mvc-and-webpages.aspx
I suggest you to take a look at this codeplex miniproject : http://loginwithgoogle.codeplex.com/.
You might find it helpful.
Regards
I often have a need to secure a single page (i.e. Reports) on a public facing app so that only authorized users may access the page. In the past, this mean setting up a custom login form or using the ASP.NET membership provider or something else far too complex to serve the purpose. Is there an easier (safe) way to secure a single page in this fashion?
Some things I've considered:
Client certificates (initial setup is a pain)
A single master password (works in a pinch, but feels dirty)
Restrict access by host address (cumbersome when the need arises to allow external users access to the page). Also, need to support access via proxy (X-Forwarded-For) which can be faked by technical users)
Are there other options? Recommendations?
You can do it in your web.config file something like what is suggested here. As far as authentication is concerned the easiest way is to use windows authentication.
A login system is your best option. If you don't want to go through the trouble of setting up and managing a login system yourself, consider using OpenAuth.
You can achieve functionality pretty easily using DotNetOpenAuth. Users can then log in with their Google, Yahoo, StackOverflow, etc. accounts, and you get a token that you can store to limit access with.
when to use
windows authentication, form authentication, passport authentication, none?
I don't find on internet any relevant matter on it, although all say how to use these authentication.
But no one says which one is superior and when to use one.
Please elaborate a little on it.
Also i want to know benefit of one over another, and what is that authentication i did by now by creating table with user id and password and match the user id and password with the data table. If that can be done easily what is the need of these authentication.
It depends on the project and what you want to achieve. If you were developing an Intranet for a company obviously only to be accessed from internal computers then windows authentication would be the choice.
If you want people to register and wish to access as much information as possible then use forms authentication to get the data you require and store it alongside membership.
If you want people to come and go from your site with ease with as little steps as possible for registration, then use Passport.
Hope this helps :)
Windows authentication is generally for companies where people do something locally and server checks if the computer that is trying to do something is valid.Example: Company that accepts some requests and people working there do something with them.
Forms authentication is for whole web where you want people to access the content regardless from PC/other device? they are using.Example: Website like this.
Windows Authentication is generally used for Active Directory-enabled networks, such as Intranet sites etc. where the user's Windows credentials double as a login to the web app.
Forms Authentication allows you to use the .NET Membership/Role/Login features and control a more in-depth user database.
I've never come across a good reason to use Passport Authentication, but it's a proprietry MS single-signon style authentication method.
We are creating three different websites using asp.net but for the user part we want to implement an approach so that each user only need to create an account in any of these three sites but use the same account in other websites too.
here is what I've suggested :
create a
useracount.website.com server
then put the sql server there and implement core user account library there such as (creating/editing/etc...)
whenever a visitor needs to have an account or needs to login into out sites then we will redirect him to the useracount.website.com address and he/she should login from that point.
and for the maintaining the user's states I've suggested to using cookies.
and all of these scenarios should be implemented by asp.net and sql.
please let me know with best approach cause I feel mine is not that good specially the cookie part.
cheers.
Search for Single Sign-on in Web Farms
Here is an Introduction
Does anyone know of an ASP.NET guide to implementing OpenID and what information can be returned by the OpenID provider? I understand you can get the email address but if someone logs in with their Google OpenID can you get access to their addresses?
Yes, OpenID Providers can and often do offer 'claims' or 'attributes' about the people logging in if the OpenID relying party requests them and the user consents to these data being shared.
If you use DotNetOpenAuth for your ASP.NET OpenID library, it has built-in support for several ways of getting these attributes but keeps it simple on your side to get at them regardless of which way the Provider offers them. If you download the library it comes with a sample of how to do this.
As far as work address, and some other attributes specific to certain domains (domains of data--not Internet domains) very few Providers offer them. The best you can do is get "full address" and ask the user if that's the one they want to use.
This should help: http://www.eggheadcafe.com/tutorials/aspnet/4b3c7c9b-fe80-4e6e-a34e-0e9efed5c575/integrate-openid-authenti.aspx
Or a "simpler" one: http://madskristensen.net/post/OpenID-implementation-in-Csharp-and-ASPNET.aspx
Document describes how to implement Google login into your web application
and Third-party web sites and let you aware how OpenID authentication works.
Here is the step-by-step process to implement OpenID on your ASP.NET application using DotNetOpenOAuth libraray.
Tutorial demonstrates how to add OpenID support to an existing site that already has traditional membership without breaking anything in AspDotNetMVC.
I just blogged about this here. this shows how you can get extra information from these providers
http://blogs.msdn.com/b/webdev/archive/2012/08/22/extra-information-from-oauth-openid-provider.aspx