Is using Kerberos to authenticate to web sites and web services a good idea?

Question

Through acquisition we have a number of products that require authentication and authorisation. The products include web sites and client side applications, the client side applications use some web services. We are a .Net shop and servers will be running Server 2008, clients will be running XP SP?? and later.

Users of the products are not part of our organisation and run from single users with a standalone pc to users in organisations running Active Directory etc.

Currently there is no common authentication or identity store and we are looking to remedy that. Our goals are:

• A single user name and password (or certificate) across all products.
• Ideally a single sign on (easy if we are launching a web site from a client app, presumably less so if a user logs onto a web site first then later launches the client side app).
• Plus the usual; robust, scalable...

Like most companies we have limited resources and a tight schedule.

One suggested path for authentication is Kerberos which is probably the ideal route for a client app to authenticate to a web service but I am less happy using it on a web site where the user would submit a user name and password and the web server would be responsible for ticketing (then storing the ticket in a cookie?). I feel that we may be better off with a single identity store and our own authentication service that takes a user name and password, compares to a sorted hash, then issues a custom, time based security token. Maybe use SqlMembershipProvider?

Thanks to anyone that has read this far. Is Kerberos the best fit for this scenario or should I be looking elsewhere? If it is not a good fit, why not?

We are also looking at AD LDS for authorisation but I think this post is long enough already...

Answer 1

Have you considered OpenID?

Answer 2

OpenID for your single user accounts, and OAuth to authorize apps to access data at another web site make a good, distributed solution. Yes, Active Directory or another pure single-sign-on solution works great in a homogeneous environment but it sounds pretty divergent in your org.

Setting up a secure OpenID Provider is actually a big responsibility and shouldn't be something you just whip up by slapping a library together with a web server. You could let your users use their own OpenIDs, and then have a database where your users register their OpenIDs so they are recognized as employees/members across the system. Various parts of the system can check an OpenID for membership either directly against the database, or you can use OAuth to help verify membership too.

Very interesting possibilities in ways you can combine these two technologies.

Answer 3

There is nothing inherently wrong with it except that Kerberos isn't really designed for that kind of use case, and doesn't play nicely with firewalls, generally. For example you probably don't want to open up external access to the same Kerberos KDC you use internally.

Plus if you mean MS Kerberos, and you apparently do, then opening up Kerberos comes with a whole other rats nest of MS protocols that you have to open up sooner or later, because the higher level stuff is tangled up with AD etc along with Kerberos.

That said:

I feel that we may be better off with a [...] our own authentication service

Almost certainly not. You generally don't want to reinvent the wheel, and if you must then not that wheel. Authentication protocols are generally hard to do and even harder for web access. Stick to something that exists already - basic authentication + SSL or client certificates and SSL, plus session tracking (again over SSL if this stuff really matters), or an LDAP service that is distinct from your AD. Those approaches all have their own problems but not as many as you'll have with rolling something of your own.