Imagine you're writing a web app that will have 1 million users (they all grow that big, right!)
How would you handle user accounts? I can imagine a few scenarios:
Roll your own (database tables, salted/hashed passwords stored in a user profile table)
If written with ASP.NET, use the login/role provider (which falls back to the database)
Use Active Directory if in a Windows environment
Use some other LDAP server
A 3rd party provider like OpenID or .NET Passport
Stability and scalability are of course important.
I guess this is really a question of whether Active Directory and other LDAP servers scale well and easily. What do Facebook, Twitter and Gmail use as their backend account provider?
What got me thinking about this is the Google App Engine. Really cool looking. But users would need to get a Google Account if I used the built-in authentication stuff. Or with #5 above, users would need to go get an OpenID. I'm trying to make it so they can just do a simple sign up with my site without needing to visit other sites -- for the non-geeks of the world :)
I would ask someone who had actually worked on a system which caters for that many users.
I'd find out about other systems like this, and look at case studies that have been written about them. (Ask Microsoft, Oracle, IBM etc.).
But, for usability you either need to implement a single sign on solution, so users don't need to know their login details. (Perfect for the corporate world.)
or
You have to go with what users know, which is an email address/username, and password.
OpenID or similiar systems are horrible for non technical users.
(Note, anyone looking at this is a technical user.).
OpenID.
If you must give the users a choice to create an account on your site, become an OP.
Related
I've been thinking about this quite a while and it's bugging my head off, lets say we have a website a mobile app and a database.
Usually when we develop our websites we pretend to store our database credentials in a configuration file and connect the website directly to the database without using a multi-tier architecture, but when it comes to a mobile application such Android or iOS this applications can be engineer reversed meaning that there's a risk of exposing your database credentials.
So I started thinking about this multi-tier architecture and kind of thinking about how Facebook and other social network do their job, they usually make an API and use a lot of HTTP Requests.
Usually social networks APIs have a app_id and a secret_key, this secret key would be used to increase the safety of the application but I'm thinking about how could I store these keys inside my application since I would go back to the begining of my discussion, if I was to use Java I could use the Java Preference Class but that isn't safe either has I saw in this question, plus I would need to make sure my HTTP Requests are CSRF safe.
So, how could I store these keys inside my app? What's the best way to do it, since hard-codding it's out of the question.
You should always require users to log in - never store credentials or private keys in an app you'll be distributing. At the very least, don't store them unless they're specific to the user who has chosen to store them after being validated.
The basic idea is that the user should have to be authenticated in some manner, and how you do that is really too broad to cover in a SO answer. The basic structure should be:
User asks to authenticate at your service and is presented with a challenge
User responds to that challenge (by giving a password or an authentication token from a trusted identity provider).
Service has credentials to access the database, and only allows authenticated users to do so.
There are entire services out there built around providing this kind of thing, particularly for mobile apps.
You might store the users own credentials on the device, and if so it should be encrypted (but you're right, a malicious app could potentially pick them up).
Bottom line: never distribute hard coded access to a database directly.
I have multiple asp.net mvc websites hosted in sub folders of a main domain. Each website has its own sql server database. Currently users need to sign up to each individual website if they want access but I am looking for a sso solution. I guess a little bit like how ebay works where you can sign up in one country's domain but can log into ebay from any other of the domains ebay has sites for.
I am looking for the best architectural design to achieve this. After a lot of googling this seems to be the only solution that fits the bill but wanted to check first (http://arunendapally.com/post/implementation-of-single-sign-on-(sso)-in-asp.net-mvc). If this is the right approach how does that effect the database design, would the users now only get stored in their own database all of the other websites have access to?
I think that maybe moving the authentication part of your application somewhere else would be a better option.
You could try the approach suggested in your link.
Another option would be to look at external providers.
I'm thinking here about azure active directory (https://azure.microsoft.com/en-us/documentation/articles/active-directory-whatis/ with this example http://www.asp.net/identity/overview/getting-started/developing-aspnet-apps-with-windows-azure-active-directory) or auth0 (https://auth0.com/) for example.
That way you have a separate place for your user accounts which are in a database on the cloud which you don't have to manage. Somthing like azure active directory allows you to also set which users are allowed to access which app, which is also something you need to take into account.
I am in process of designing a SaaS application over PaaS (Google App Engine).
My SaaS will have two user interfaces:
Web Based
Mobile App based
Web based would be feature-rich whereas Mobile app would have essential and/or frequently used features.
Mobile app would invoke RESTful services to perform business logic.
This SaaS would target mainly individuals using Mobile Apps; however, there could a use-case wherein these individuals could form a group and operate as a company.
So with that in mind, I am considering two entities: Account (Tenant) and User.
I am considering having many-to-many relationship between these two entities as one user could be part of multiple Accounts (unlikely but can’t be ruled out) and of course, one account can have multiple users.
I would like to know the best practices for authentication under such scenario:
Should I use Google's provided Authentication or should I implement my own authentication? (I am still exploring OAuth and Google's authentication offering.)
I think, for web-based interface, username/password over SSL would suffice. But, not sure, can this be applied to mobile app?
Can I avoid a situation wherein I have to store credentials in mobile app?
Thanks in advance for any help you can provide on this.
A
Having just completed my first project using Google App Engine, I can say that I ran into alot of the questions that you have. I'll try to explain my approach to each point and also approach it from your perspective as well.
Authentication - Generally using Google's auth would be the easiest route, but you would still have to implement a custom adaptation in order to work with the "company"/"group" concept. Implement in the datastore/whatever database you prefer to use an entity called "Groups" which have a list of google users... this way users can belong to many groups.. then you just search by property (user) to get all groups they belong to. I implemented my own authentication system for unrelated reasons.
Google App Engine comes with SSL/HTTPS support for its own domains. You can add in your own custom domain with SSL support as well. You can use SSL through native apps or mobile web apps additionally. I simply used the native support that came with it.
Yes and no. You will always have to store the credentials somewhere. Maybe it wont be in your apps code/directly connected to your app (Google auth would be an example). But somewhere, on your phone, the credentials WILL reside. They may be encrypted/obfuscated, but they will be there. So either have your user enter them in everytime, or save them/use the ones provided by the phone. For myself, .NET provided a nice way of storing credentials in a secure fashion (non-plain-text) for each user's machine.
I'm using Google's user api on Google App Engine for authentification. As nearly everyone have a Google Account and api is easy to implement, that solution is convenient.
The problem is, though, with user who do not have a Google Account (or have no idea what a Google Account is). Where the api provides a nice interface to log in/log out and redirect immediately and easily to the app, nothing is said to developers about potential new users.
So here are a couple of things worth noticing:
Google' new Google Account page (https://www.google.com/accounts/NewAccount) is pretty straightforward, but not convenient at all for new users of a GAE app: no mention of anything not Google (users who don't really know what authentification is won't have any clue of why they need to open an account with Google), dead end (won't lead anywhere in the end), ugly.
GAE Log In screen includes a link to the New Google Account page. This link is of the form:
https://www.google.com/accounts/NewAccount?continue=http%3A%2F%2Fexample.com%2F_ah%2Flogin%3Fcontinue%3Dhttp%3A%2F%2Fexample.com%2Fprofile%2F&service=ah<mpl=gm&sig=0aa0a000aa000a00000aa0000a000aa
(Where example.com is the return url provided to the API). Great! But the situation is in no way different than it was: still a dead end, still no mention of any non-Google app, still ugly).
So, I'm asking, is there any imaginative way to provide a nicer interface for new users? Have anyone have ideas of how to present the process to the new users (a video for how to create a new account? some kind of tutorial page? etc.)? Just trying to think outside of the technical box here...
Regarding the various authentication options you can check out the Java or Python docs on OpenID (http://openid.net/)
Basically this allows supporting authentication by different agents, which includes Google accounts or even your own GAE application's custom implementation.
Furthermore you can check out User Experience summary for Federated Login for more information regarding UX considerations and best practices - with user authentication.
I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...