Menu
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:
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...
563
Kerberos is far from obsolete and has proven itself an adequate security-access control protocol, despite attackers' ability to crack it. The primary advantage of Kerberos is the ability to use strong encryption algorithms to protect passwords and authentication tickets.
The Kerberos protocol is considered secure. It has been widely implemented for decades, and it is considered a mature and safe mechanism for authenticating users. Kerberos uses strong cryptography, including secret-key encryption, to protect sensitive data.
Kerberos ensures that only authorized users can access the network resources. Additionally, it provides AAA security: Authentication, Authorization, and Accounting. MIT developers developed Kerberos to authenticate themselves to their required systems securely. But Kerberos also authorized the users.
In our world, Kerberos is the computer network authentication protocol initially developed in the 1980s by Massachusetts Institute of Technology (MIT) computer scientists. The idea behind Kerberos is to authenticate users while preventing passwords from being sent over the internet.
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.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
