Which authentication and authorization schemes are you using - and why?

Question

We're beginning to design a whole bunch of new services to create (WCF, ADO.NET Data Services, possibly in the cloud at some point) and one question that pops up is what authentication and authorization scheme to use - there are quite a few!

We basically need to be able to identify users (actual people, and "virtual" application/service users) on a wide variety of protocols - HTTP, HTTPS, TCP - and we need to assign them at least a bunch of roles / permission to see certain data and/or do certain operations.

We definitely can't use Windows group membership alone - we have plenty of external consumers of our services and we don't want to have to set up a domain account in our internal domain for everyone of them.

So there's mainly three options, I think:

1. Using the ASP.NET membership system - create users and assign roles there
2. Use AzMan (Authorization manager) which seems to be a more granular, more mature, more elaborate system (with users, tasks, groups - three levels, not just user + roles)
3. Roll our own

First of all - which of these three would you recommend? Any why?

Secondly - are there more options that I'm missing?

Thanks for any hints, pointers, opinions!

Marc

PS: seeing the answers so far, I'm amazed at the amount of folks voting for option #3. I would have thought that MS would be able to design something reusable that could handle all of these requirements....

Burgess

Answer 1

Actually, the answer is probably a combination of 1 and 3.

You can take advantage of a lot of the tools and features that the framework provides for you by writing a membership, role or profile provider if the default options don't quite go as far as you'd like.

We've done just that on a number of client sites - for example one of our clients has most of their users stored as Commerce Server users, and use the Commerce Server profile system, so we wrote a membership and profile provider to talk to those datastores - a fairly simple excercise.

---

Most people are probably going for 3 because of the need to authenticate over raw TCP - this introduces a layer beyond that of the standard ASP.NET membership providers.

Most of what MS produce is "ok" or "good enough", but there will always be edge cases where you want to do something "not quite standard" that mean you end up rolling your own. I guess to have something beyond "Basic Auth" or "Windows Auth" that was simple for your average developer to understand, they took the sensible option of "lets just build this for the web".

If you take a look at the numerous ways you can authenticate against a WCF service, you'll see what I mean - these are designed to handle different transport mechanisms, and are therefore much more complex.

That said, the default roles and profile providers are fairly limited (roles: no hierarchy, so you need to check for each possible role, or explicitly assign each role to the user; profiles: all stored in one field as comma seperated values - not easy to find all users who've got a value set).

Aldric

Answer 2

We use (3). Actually that helped us in an integration scenery to have accounts in sync with

1. business processes
2. Other systems (not all on the same technology stack (ASP.NET))

Sundried

Answer 3

On a recent project we extended the ASP.NET membership provider (wrote a custom provider) with the intent of using some of the role based controls for managing permissions. Now that the project has matured sufficiently, we're finding that the controls are not flexible enough for our requirements, and to some extent we're regretting going down the MS membership path. Rolling your own authentication if you have the time to architect it correctly is going to be the best option.

It sounds like your app is a bit of a hybrid in that you're serving internal and external customers, but perhaps also give some consideration to integrating OpenID for your external customers. There are some great ASP.NET OpenID controls that really makes handling new accounts for external customers a no brainer. This of course depends on how 'public' your application is.

Cupule

+1 for OpenID - that's a really interesting thought - thanks! – Burgess

Answer 4

Ldap anyone? It's free, cross-plaftorm, easy to use and administer remotely, has bridges to other auth schemes, and bindings in more languages that you knew existed...

Feldspar

Aren't we basically at the same place as Active Directory then? We'd have to create user accounts in LDAP for any user (real or virtual) in LDAP, right? What's the benefit in your opinion, compared to the other options? – Burgess

Also, as far as I understand it (but please correct me if I'm wrong), LDAP really only handles the authentication part - WHO ARE YOU? Or is there an easy way to include authorization into it, too? (what can you do as a user?) – Burgess

Doesn't the ASP.NET membership gives an option for AD integration too? Ldap allows the datasource to be on a Novell or Linux system for example, while simulation an AD on those system will be hard work - if even possible with a 100% match. – Sundried

LDAP adds another moving part to the web app, and if you're using the AD LDAP store, you're exposing your corporate data to needless risk, by allowing web-apps to add auth credentials that might be valid on the Windows network. – Virgate

Answer 5

Isn't AZMan from 2003?

I would recommend 1 or 3. Personally I've always gone for 3. There's a lot of functionality that 1 has that I don't use or care to use.

Elisha

Answer 6

I would stay away from AzMan. We went down that road once and didn't like the section of town we broke down in. We've always done AD-based logins that use the SID of the current user to link to a user in the database, then taken the permissions from there. Given your setup this may not be possible (or practical), but I'd stay away from AzMan in any event.

Embryotomy

We use AzMan all the time. Had a few problems along the way but nothing unsolvable... – Moltke

Answer 7

I'm not an ASP or .NET developer, but my gut says (3). You really don't want a public-use web-app to have any sort of access to your corporate network, much less be able to put auth credentials anywhere near AD.

Virgate

Answer 8

You seem to provide too much and too extensible to stick to one technological solution

Solution 3.

I would base the whole application around a User class You would just simply have to model it so that it will provide you with the needed flexibility and extensibility

Something like:

    [ClassAttribute ( "Yordan Georgiev", "1.0.2", "20090302", "20090415" , false )]
public class User
{
    #region DomainName
    private string _DomainName;
    public string DomainName
    {
        get { return _DomainName; }
        set { _DomainName = value; }
    } //eof property DomainName 


    #endregion DomainName

    #region Status
    private int _Status;
    public int Status
    {
        get { return _Status; }
        set { _Status = value; }
    } //eof property Status 


    #endregion Status

#region Password
    private string _Password = Resources.GV.Pass; 
    public string Password
    {
        get { return _Password; }
        set {
            _Password = GenApp.Utils.Security.Encryptor.Encrypt ( value,
                GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm );
            //debug_Password = value; //unencrypted 
        }
    } //eof property Password 


    #endregion Password 

#region ListUserRoles
        private List<UserRole> _ListUserRoles;
        public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set     { _ListUserRoles = value; } }
        #endregion ListUserRoles


    #region UserSettings
    private GenApp.Conf.UserSettings _UserSettings;
    public GenApp.Conf.UserSettings UserSettings
    {
        get {
            if (_UserSettings == null)
                _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance;

            return _UserSettings; 
        }
        set { _UserSettings = value; }
    } //eof property UserSettings 

}

Spillway

Really? Is asking for a comprehensive, complete and hopefully simple-to-use solution for knowing who you are and what you can be really too much? I would think this is the cornerstone of pretty much ANY app these days, no? – Burgess

the code was just example of the basic properties an user object should have ... you might add as many as you want on the go ... + create some plug-in model. My point was that you must have your own User class ( or even derieved it from some Microsoft's user class depending on the service you are providing for those user .. – Spillway

here is an example how to derived from the MembershipUser class - msdn.microsoft.com/en-us/library/ms366730.aspx – Spillway