I’ve been reading about Role Based Access Control and I am trying to figure out how I should go about implementing the security control. In my MEF project, I have a security controller that is ultimately responsible for user validation, verifying roles, etc. etc.
Naturally, the security controller needs to be able to access a database to run validation on a user and retrieve the user’s role(s). I intend to implement classes from the System.Security.Principal namespace.
Should the security controller module have its own database where user info is maintained separate from the business data?
And, would a binary serialized file be adequate for this so long as user passwords (only the hash) are not stored in said file? I would assume, however, that for this to work, the serialized file must be accessible by multiple instances of the application…
Update
Since this is an MEF project, I have been wondering about how security should work. Here are my thoughts:
Security Controller is an Identity object itself, therefore should probably implement IIdentity and have a GenericIdentity property. SecControl should also be the GenericPrincipal…???
SecControl would also be responsible for modifying AppDomain permission sets. I don’t want any modules to have access to any resources (database, files, network shares, etc) not specifically granted by SecControl.
Not only are users authenticated, but the Modules are, too. Modules (plug-ins) will probably implement IIdentity and have GenericIdentity properties as well.
Should the security controller module have its own database where user info is maintained separate from the business data?
Depends on the context of your system:
There’s also the consideration of what you are protecting. If you are mostly trying to keep access to a dull roar and are not working with financial info, health care info, or defense info – you may be OK with a certain amount of risk in where the user information is stored. If you have a high security application, then you may even want to go so far as thinking about commecerial software products for access control (like an LDAP directory that has it’s own audit logs, server, administrative processes, etc).
When you think about the data store, don’t limit yourself to thinking just about how the data is stored and protected. Also consider how you access the data (over an encrypted connection or in the clear?), how accesses are logged (in a high security system, verification of user credentials is an event that should be logged), how logs are protected (are they tamperproof?), and how the data is protected – not just from from scrutiny, but also from modification.
And, would a binary serialized file be adequate for this so long as user passwords (only the hash) are not stored in said file? I would assume, however, that for this to work, the serialized file must be accessible by multiple instances of the application…
My biggest question for that is – how is this file protected from change? Since a binary searlized file is relatively easy to parse from an application, how do you control the ability for other processes to write toe the file? The easiest attack would be to add your own high-privilege account and username/password hash and then use the fake account to crack the rest of the system. How easy would it be to do that and how easy would it be to take a set of low-privilege credentials and transform them into high-privilege?
That’s more than just the file storage mechanism – it also means you need to have a sense of access control on your operating system and how that is managed.
Things that may help:
– digitally sign the file with an asymmetric key stored elsewhere, then check for tampering before using the file.
– store the file in an account that can only be modified if you are an admin.