Geeks With Blogs

News


Dylan Smith ALM / Architecture / TFS

For Authorization we had the requirements that we had to be able to easily assign a specific user to a certain "role" and they would have all the priveledges associated with that role.  We had to be able to make users members of multiple roles.  We also had to be able to configure what specific priveledges belonged to each role.  In addition, we had to be able to assign a specific user to a specific role, but then also give them access to one or more specific priviledges in addition to those granted by his role(s).

So it was pretty clear that we needed 2 layers of security privledges, fine grained priviledges that mapped to specific tasks/actions within our application, and higher level roles that grouped these priviledges together for easier administration.

Some of our users have Active Directory accounts and are authenticated using them, some of our users (the shop floor operators) do not have an AD account and use the fingerprint scanners to authenticate themselves at the application layer as described in Authentication Solution  (these users are logged into the machine/network under a generic account called something like ShopFloorUser).

There are two questions that need to be addressed.  How should we associate the priveledges with the code, and how do we associate the priveledges and/or roles with the users.  The former question is fairly straightforward, we are planning on associating a priviledge with every WebMethod exposed by our web services.

For the security priveledges and roles I would like to utilize groups in Active Directory.  We can have a group for each fine-grained priveledge, and then more groups for the high-level roles.  Since you can have groups as members of other groups this works out nicely.

For all the users that have Active Directory accounts the security administration is very straight forward.  Everything can be managed inside of the MMC for Active Directory.  We can assign privledges to roles, and users to roles, and specific priveledges to users.  All is good.

However, how do we handle the shop floor operators who don't posess domain accounts?  They identify themselves by passing in a fingerprint to the middle-tier, which then associates that with an employee from our employees table.  One way would be to create domain accounts for all of these users and associate the AD groups with their domain accounts.  Then when it comes time to authorize them to perform a certain action we could retrieve the AD account name from the Employees table, and use LDAP API's to check if they are a member of the group in question.  The advantage to this approach is that we could use the AD MMC to manage all security on both shop floor users, and the office staff who have their own AD accounts.  However, I don't like this for a number of reasons, 1) I don't like the idea of creating domain accounts for all our operators that will never actually be used (ie. nobody will be told the passwords and ever sign into a computer using them). 2) We tried writing some code using the LDAP API's to check if a specific account name was a member of a specific group name, and it turned out to be fairly slow.


An alternative solution is to track the permissions in a database table.  We could create a table of "groups" that allowed hierarchical relationships just like AD.  And then we could have another table that assigned employees as members of the groups.  This would work great, as it isn't bound by the requirement that all the employees have AD accounts, as long as they have a record in the Employees table it will work great.  It would also be flexible enough to support additional user accounts that are self-created if we ever do something with the internet where users could create their own accounts to access our applications (this is not currently a requirement).  The problem with this approach is that we then have to create our own tools to manage the administration of permissions and roles.  We wouldn't be able to use the AD MMC application which would work great in the previously suggested solution.

For the time being we're going with something similar to the first option, only slightly different.  We are going to associate all the security permissions with domain accounts.  However, rather than create a domain account for every operator, we realized that 90% of the operators will end up having the exact same permission set.  So what we have decided to do is associate these common permissions to the ShopFloorUser generic domain account that the operators will be signed in under.  When a shop floor operator attempts to perform a task we will first check their employee record and see if they have an AD account name associated with them, if they don't we will do the authorization check against the account they are signed in under (ShopFloorUser); if they do have an AD account name associated with them then we will do the stuff with the LDAP API's to authorize them using the account name stored in the Employee table.

This solution should work well since we will only have to create domain accounts for the 10% of operators who require more than the standard set of permissions.  We will be able to use the AD MMC to administer our security system.  The downside is that for the 10% of operators with an AD account associated with them, the system will suffer a performance hit due to the LDAP API code.  We believe that this is a reasonable tradeoff at this point in time.

If you can see any flaws with this, or suggest an improvment, let me know in the comments.

Posted on Monday, July 3, 2006 6:32 PM | Back to top


Comments on this post: Authorization Solution

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Dylan Smith | Powered by: GeeksWithBlogs.net