Simple Role Security
SRS for MVC3 is meant to be pretty easy to implement. All of your controllers that should be secured should inherit from the SimpleRoleSecurity.SecureController instead of the generic Controller. Your Account (Login) controller should inherit from the SimpleRoleSecurity.LoginController.
These controllers will redirect nonsecure communication to the configured HTTPS channel, and will validate the user with every method call in a low-overhead manner. Roles the user belongs to are loaded into the session at login.
To restrict a method to a role or set of roles, use the RoleRequired attribute, with a comma-delimited list of roles. These roles are case-sensitive in this context (although not in the database), so keep that in mind.
Development/ compiling prerequisites:
MS Visual Web Developer 2010 installed (Express is fine)
ASP.NET MVC3 installed
SQL Server 2005+ installed (Express is fine, but it needs to support Full Text Searching... this is usually SQL Server Express Advanced)
SQL Server Management Studio or some other way of running SQL scripts against the database. If not SSMS, the scripts may need to be altered a bit.
IIS7 or IIS Express installed, and supporting HTTPS. An untrusted certificate is fine for development. (IIS Express recommended for development/ test environment)
Dependencies Downloadable from Visual Studio:
For the SRS library:
For the Security Manager:
(I *think* the rest of the stuff will be available with those)
Installing and Configuring the Security Manager
1) Download the 2 zip files (SecurityManager.zip and SimpleRoleSecurity.zip) and unzip them into your Projects directory.
You should have corresponding folders for both files.
2) Create the SimpleRoleSecurity database and login using the scripts located at:
in your SQL Server client application.
3) Create the database objects by running the DDL script.
4) Create the default role objects by running the SecurityManagerRoles script.
5) Open the SecurityManager solution. You may be prompted to configure your web settings. Remember if your IIS
Express settings change you will need to make sure the web site supports HTTPS, and the port number needs to be
captured to place in the config file.
6) Examine the web.config file and make sure the settings are appropriate for your environment.
You should now be able to run the Security Manager using the superuser credentials in the web.config. Once you have
established an account in the Security Manager that can manage users and roles, you may want to blank out the
Run the application and create your users and roles.
Configuring SRS Settings
The following settings are used by SRS to perform its functionality.
If using the ADO implementation of the SRS (SimpleRoleSecurity.ADO), which is the default (you can implement the
interfaces using different technologies if you choose), you will need a reference to the ADOSecurity connection string
which will point at your SQL Server's SRS database. If the Security Manager installation steps were followed, the
connection string should look something like this:
<add name="ADOSecurity" connectionString="data source=.\SQLEXPRESS;Initial Catalog=SimpleRoleSecurity;User Id=SimpleRoleSecurity;Password=SRS#1234@zxy;"/>
This will be used a lot. The account need execute permissions only on the target SRS database.
An integer indicating how long, in minutes, the security token will be good for.
The name of the superuser account. The superuser automatically has access to all methods; it evaluates as having
all roles. This user is not accessible through the management console. To disable superuser access, set this to a
The password of the superuser account. If this is blank, the superuser will not be able to log in.
When using IIS Express, the HTTPS port will be somewhat dynamic, and difficult to code to. Put the port number of
the HTTPS channel in here and the HTTPS redirect should work like a champ. If you are going to the default port,
you can omit this setting or set it to -1.
(Not well tested) This will allow you to use the other features of the SRS without having a secure connection. This
is not recommended to use in production, as it allows sending your security token and credentials over the internet
in cleartext; kinda defeats the purpose of having a security system in place.