Using a Finite State Machine for access management?

Question

My intranet site uses LDAP and Active Directory to authenticate users. There are 2 kinds of Users: Managers and Employees. They are differentiated by having membership in a particular AD group.

In an effort to improve my code I'm trying to use (hopefully appropriately) formal design patterns. I think perhaps a Finite State Machine might work here. But I'm not sure which of the following models (or some other entirely) would be best:

1. 2 transitions with simple conditions

   Unlogged --- auth==TRUE---> Employee ---group==TRUE---> Manager

2. 1 transition with a compound condition

   Unlogged --- auth==TRUE && group==FALSE---> Employee

   Unlogged --- auth==TRUE && group==TRUE---> Manager

The first feels cleaner. The second is closer to what should actually be happening. Am I on the right track? Would a different design pattern entirely be better?

• Dan Pichelman: I'd guess that there will eventually be more than 2 groups. If so, how would that affect your design?
• Jean-François Côté: I think the first step would be to modify the group to be a number or a string instead of a bool. Then, I think I'll go with a simple Profile object. Finite State Machine is more for gaming or application where you have a lot of state that affect the logic of the application.
• dnagirl: @DanPichelman: I suppose more groups are always possible. But in all cases, the Controller will always need to know a)is the user logged in? and b) if he is, does the user have access?
• Blrfl: If you have employees who are also managers, put them in both groups, grant permissions for whatever actions you want to each group and base your access on that. You're trying to shoehorn something that should be very simple into a construct designed for responding to a stream of inputs. That isn't going to end well.
• Thomas Owens: This question is asking about a design pattern for data access rights.