Programming to an interface - Use them for a security class?

Question

Ok, I've read the Stack Overflow question 'What does it mean to "program to an interface"' and understand it. I understand the benefit of using interfaces (at least I think I do). However, I'm having a little bit of a problem applying it to what I'm currently working on which would be my first interface implementation.

I'm creating an class to authenticate users to my site . I've written it using static methods so I can do User.Authenticate(username, password). To me, that's nice and easy. Looking forward, there will be 3 other types of members that can authenticate. Their authentication methods will be pointing to different tables, etc. However, they will still need to authenticate, change their password, when changing passwords to verify their security question, etc. It seems like a perfect use for an interface but I'm having issues wrapping my head around how exactly to do it.

The types of users are users, doctors, brokers, employers. To me, each class should implement a security interface that defines the methods mentioned above.

Can anybody shed some light on how to do this AND if my thinking is right?

Answer 1

"Programming to an interface" means designing a set of methods and properties which are the public "signature" of the functionality or service the class will provide.

You declare it as an interface and then implement it in a class which implements the interface.

Then to replace the class, any other class that implements the interface can be used.

The interface becomes a contract.

However, this is not for static methods.

I'm not sure what purpose your User.Authenticate(username, password) serves - does it return a value to indicate the user is authenticated? What is an unauthenticated user object?

You might have some kind of central authentication controller which authenticates the users and then returned a different class of object depending on the user. Each class would implement (or probably inherit from a user class, instead) the user interface for the common functionality and then extend with their specific functionality.

I'm not really sure this example is a good case for either inheritance or interface implementation, it would really depend on more design details we don't have.

Answer 2

You might want to take a look at ASP.NET/Microsoft Membership. From your description it sounds like you have users with different Roles (doctor, broker, etc).

Answer 3

It seems to me that the user classes should not encapsulate security functionality. The security framework or subsystem should authenticate various types of users. That being said, you would perhaps want the subsystem to accept objects of users who will be authenticated. If that is the case, then having each user class implement an ILogon or some similar interface, at the very least as a "marker" interface, will allow your framework to limit the participant classes at design time.

Generally speaking though, unless it's just a marker interface, I would not implement an interface whose implementation itself violates the very nature of an architecture that supports inheritance and polymorphism.

Answer 4

Security is a cross-cutting concern to me, which means aspect-oriented programming.

Answer 5

If you have three different user objects which are used to authenticate the users with the same methods and properties, that would be an excellent place to add and interface to each of them and code the rest of the interaction through them to that.

Cade is correct about not being able to apply an interface to static methonds. The main reason for this is that an interface is applied to an instantiated object, which a static method isn't a part of.

//Defined Classes
class UserType1 : SecurityInterface
class UserType2 : SecurityInterface
class UserType3 : SecurityInterface

//Use classes
SecurityInterface authentication = GetCorrectUserTypeObject(); //the methds gets the correct UserType object base on who is supposed to authenticate.

authentication.DoAuthenticate();

Answer 6

I'd rethink your design from a database perspective. It seems to me that all of these types of individuals are pretty much the same from an authentication standpoint, with the exception that they may have different roles in the system. I'd suggest that a better way to handle this might be to have users and roles rather than different tables for each kind of user. You then split the authentication and authorization functions into different classes, but you will only need one class for authentication. The only time you would need a second authentication class is if your users were authenticated against different authentication stores (say SQL or AD, rather than just SQL).

I know that this answer doesn't address your interface question, so I'll add that I'd suggest that you define an authentication interfaces (or use MembershipProvider) then construct a class that implements that interface. It will be more easily testable/mockable this way and provide the necessary groundwork for extending to other authentication stores in the future should you choose to do so.

Answer 7

All of the types of users you mentioned are users. I have worked on alot of websites that had a short sited approach in which they treated the first kind of user that the site was written for as "user" and then any additional types of users added later were just plopped on awkwardly.

My suggestion: Don't call one of your types of user "user". They are all users that are of different types or roles.