At application run-time, the type of Authentication (sign in) and Authorization (role-based security management) 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:
ShowAutoSignInCheckBox
ShowRememberPasswordCheckBox
ShowRememberUserCheckBox
CookieEncryptionKey – the string used as a key in encryption algorithm, set to the application name by default.
All role information is processed by Authorize methods. 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.
The roles permitted for the particular page are stored in page’s HTML layout page file in the LoginRequired section. Each role management type has its own tag designating the assigned roles.
Record Control roles are stored in the page’s component binding file (XML file) for each control as a value of the <RequiredRoles> node. When your application is generated, this value (string with tags) is copied to an argument of the Authorize method in the page’s .Control.cs (vb) file.
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.
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). These standard roles are:
Everyone: There is no restriction for page access.
NOT_ANONYMOUS: Access is granted for signed in users only. This is also called ‘Sign-in’ access.
ANONYMOUS: Access is granted only to users who are not signed in. This also called ‘Not signed-in users’ access.
NO_ACCESS: No access is granted to anyone, regardless of their sign-in status. This is also called ‘No one’ access.
Note, that when adding roles manually to the 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 Eveyone role adds a ‘<SelectedDomain>\Everyone’ role to the HTML web page or XML file because this role might be domain specific. Also, the ‘Everyone’ role might apply to all domains if ‘AnyDomain\Everyone’.
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:
The ‘No one’ (NO_ACCESS) role is the highest priority. If this role is present in the roles list, no one will be allowed to see page or control regardless of other roles assigned.
‘Signed-in users’ (NOT_ANONYMOUS) and ‘Not signed-in users’ (ANONYMOUS) have the second highest priority. Including both these roles is effectively the same as including ‘Everyone’.
‘Everyone’ is the lowest priority role.
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.
The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying directory services running over TCP/IP. Due to this basic design (among other factors) LDAP is often used by other services for authentication. Active Directory uses the LDAP protocol for communication with the Active Directory server.
Active Directory is a directory service used to store information about the network resources across a domain and it is an implementation of LDAP directory services by Microsoft for use primarily in Windows environments. The client then sends operation requests to the server, and the server sends responses in turn and these requests and responses are LDAP protocol compliant. The main purpose of Active Directory is to provide central authentication and authorization services for Windows-based computers. Active Directory also allows administrators to assign policies, deploy software, and apply critical updates to an organization. Active Directory stores information and settings in a central database.
For a detailed explanation of LDAP protocol: http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
Novell eDirectory is not supported at this time, and Iron Speed Designer’s Application Security Wizard will not generate authentication and access control security for Novell eDirectory. However, you can add this functionality via a code customization to your generated application.
Active Directory and Microsoft Authorization Manager Configuration
For a detailed explanation of Active Directory: http://en.wikipedia.org/wiki/Active_directory