We've got an MVC website that is going to use DotNetOpenAuth for signing in users via OpenID and I've found this really helpful template and other more simple examples that will help me get started on that end. However, what I don't have fully figured out is how to provide my users with a way to create an account with us if they don't want to use OpenID.
I can see two options here, write some custom code that allows OpenID to piggy back on the standard membership provider. Or, have the end site only use OpenID via DotNetOpenAuth and build an Identity Provider for my users to sign up on. That way the site would only see OpenID users and wouldn't know a difference.
Are these my only options? I haven't been able to find anything on standing up my own Identity Provider, just the relying party templates. I think I can get by with just putting OpenID on top of the default membership provider, but that feels like I'm doing it wrong, since I should be able to just stand up an identity provider.
So, in my situation, what would be the best way to support membership via local account creation and OpenID via DotNetOpenAuth?
Setting up your own identity provider so that your site only speaks OAuth is certainly an option, but a non-trivial one. I wouldn't recommend setting up an identity provider unless you intend your customers to use it for logging into other sites.
Also keep in mind that most web sites don't use OAuth to authenticate (since it's not an authentication protocol anyway). OpenID is more popular.
The project template you linked to in your question demonstrates allowing users to log in via several OpenID Providers and includes support for linking user accounts.
As for supporting local user accounts as well, I suggest you take a look at the source code behind nerddinner.com. I would advise against using the ASP.NET Membership provider for the OpenID/OAuth accounts as the interface doesn't fit very well, but folks have made it work so you can too if you want.
Related
I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
I'm working on an MVC4 site using SimpleMembership to handle user accounts and role based authentication. We have another site and we'd like to implement a single sign on system allowing users from the existing site to log in to the one I am building. What would be the best way to achieve this and hopefully leverage to the existing roles based authorization I'm using on the MVC4 site. Is it possible to have multiple membership providers (i.e. use the built in one and if the user is not found, attempt to authenticate via a custom provider that I'll write (once I work out how!). Or would it be better to abandon the built in membership/roles and roll my own?
I also thought of letting WebSecurity check the local database and if the user is not found, query the 2nd database and if the users credentials are valid, create a local account for them. One issue with this approach is if a user called Fred registers on the MVC site, and then a user from the other site called Fred logs in, we couldn't create them a local account with the same username. We could prefix/suffix the username with some text to indicate that they are from the other site but then we lose the single sign on feature.
We will also want to integrate AD authentication for staff in the future.
So essentially I'm looking for the best way to authenticate users from multiple databases and keep using roles based authentication?
I've also done a little digging was wondering if ADFS might be useful for this.
Any help or advice would be greatly appreciated!
I recommend the use of an Identity server to handle all your login request and switching to a claim based authentication instead of a role based authentication if you can.
I personally went with Thinktecture IdentityServer
pluralsight.com have a good course on it.
Thinktecture IdentityServer is build on top of simple Membership and it supports multiple protocol such as
WS-Federation
WS-Trust
OpenID Connect
OAuth2
ADFS Integration
Simple HTTP
I recommend checking it
Good Luck
Like SO, I am gonna depend on many Open ID providers to provide user authentication and I will use my own authorization methods. but I'm still in development phase, and don't want to work with real OpenID providers currently, what approach can I use to test my users and their activities in the website (w/o TDD), to emulate real users but not really use Open ID providers.
No need to make auto-transfer of users into real OpenID servers (when moving to production mode) since the current users are just for testing purposes and Unit-test code.
I guess, I need a User Service layer which provides a higly abstracted way to deal with users, so that the move to the real Open ID providers can be smooth in the future and doesn't affect the logic of my already written code.
Using C#.Net 4, ASP.Net MVC 3, Ninject
DotNetOpenAuth provides both server and client portions of OpenID and can be used to run your own OpenID provider for local testing.
Give your site members their own OpenIDs with the provider support included in this library.
Sample relying party and provider web sites show you just how to do it.
I simply register my test id as user with various organisations. I don't see anything wrong with that. I get to see the various responses and their differences.
I found it terribly easy to code for openid consumer. Just need to understand the sequence of responses. Draw the UML sequence diagram to aid your understanding before you start coding. No need to fake openId. Otherwise, whip up an openid server yourself.
Your services shouldn't depend on OpenID. Just have OpenID plug into an authentication module to provide a local user principal. In development, you can have the auth module return a fake user principal with the permissions you desire.
In a beta environment you could turn on OpenID and use test accounts from any OpenID provider. Having to log in during the development phase will just slow down all the developers. Any authentication bug or internet outage will kill everyone's productivity.
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.
Please I would like someone to tell me if dotNetOpenAuth single-sign-on.
All I want to achieve is to be able to seamlessly logging to all domains without redirect to third party system for authorisation or Authentication within a mixture programming platforms e.g (PHP or .Net)
DotNetOpenAuth library is a simple library to implement Single Sign On for .NET based application. The only issue I faced was related to performance. It was found to be a known issue with a particular API that cause the sluggishnes.
DotNetOpenAuth can be used for SSO solutions, but each new web site a user visits does need to perform a redirect to the identity provider. In a controlled SSO environment, that provider may never appear to the user, so the login is totally transparent. There are a couple of samples of an SSO configuration that comes with the DotNetOpenAuth download.
DotNetOpenAuth will help you do what you want to do provided you can support OpenID from PHP. You need to implement a provider (the site that authenticates you against a DB or other store), and a consumer (the site you want to log into).
My recommendation would be to consider the authentication protocol you wish to use rather than a specific library at first. In the case if DotNet OpenAuth it has support for:
OpenID
OAuth
InfoCard
These are just a few of the protocols available. You should also look into the SAML family of protocols, in particular SAML 2.0.
There are implementations of SAML for PHP, .NET, and many other platforms. You might want to look at a comparison between OpenID and SAML in order to choose which is better for you.