Configuring Your System for Application Security

Authentication and Authorization Process Overview

At application run-time, the type of Authentication (sign in) and Authorization (role-based access control) is defined by the AuthenticationType and RoleManagement keys in your application’s Web.config file.  Depending on the key values, different methods for authentication and authorization are used.  Other keys in Web.config control the sign-in process:

All role information is processed by the Authorize methods in your application.  If the user is not logged in and the page requires any role except ‘Everyone’ or ‘Anonymous’, the user will be redirected to the Sign In page.  If the user is logged in and his roles do not match the roles configured for the page, the user is redirected to the Forbidden page.  If the user is not logged in or his roles do not match the roles configured for a record control, the control is hidden from the user.

Where are role assignments stored?

The roles permitted for a particular page are stored in the page’s XML property file.  When your application is built, the Authorize method is created with the appropriate role assignments in the page’s code-behind file for page-level authorization (Page.cs / .vb) or the page’s controls file for control level authorization (.Control.cs / .vb).

Multi-level menu role information is stored in the Menu.sitemap file located in your application’s Menu Panels folder. Role-based security information should be explicitly entered in this file.  Only roles applicable for the currently chosen role management type should be entered.

Standard roles

Iron Speed Designer has several ‘standard’ roles which can be used to configure your application in the absence of more definitive roles defined in your database, in Active Directory or in Microsoft Authorization Manager (AzMan), depending on your chosen security option.

Note that when adding roles manually to your application’s Menu.sitemap file you should spell them exactly as shown above, i.e. you should enter “NOT_ANONYMOUS” if you want this menu shown only to signed-in users.

Similar standard roles are used in Database security with one difference: when the ‘Everyone’ role is assigned to any page or control, nothing is actually added to the page or control.  ‘Everyone’ is an empty role when using Database security.  However, in Active Directory security, setting the ‘Everyone’ role adds a ‘<SelectedDomain>\Everyone’ role to the XML property file because this role might be domain specific.  Also, the ‘Everyone’ role might apply to all domains if ‘AnyDomain\Everyone’ is selected.

Another important aspect of standard roles is that you can add several standard roles at once, although this does not make sense in certain cases.  If multiple standard roles are assigned, they apply in this order:

It is possible your Active Directory has a group or your AzMan policy store has a role with exactly the same spelling as one of standard roles.  These roles are recognized as standard roles and treated according to the rules described above.  To avoid this, you can add a new role or group with a unique spelling and copy all members of your ambiguous group or role to the new unique role.  For example, if your Active Directory has a group named ‘Everyone’ containing members, you may create new Active Directory group named ‘ADEveryone’ and add all members of your ‘Everyone’ group.

See Also

Configuring Your System for Application Security

Configuring Microsoft IIS and IIS Express for Application Security

Configuring IIS Express

Active Directory Role Management

Configuring Microsoft Active Directory

Microsoft Authorization Manager (AzMan) Role Management

Configuring Microsoft Authorization Manager (AzMan)

Microsoft SharePoint Authentication and Authorization

Data Transmission Encryption

Configuring Firewall Security

Handling SQL Injection Attacks