Active Directory and LDAP (low-overhead directory access protocol) are “single sign-on” facilities available from Microsoft and other vendors that provide a single sign-on and user authentication facility. A user signs in once, and that sign in is transferred to all applications used by the user, saving them the time to sign in to each individual application. Moreover, these facilities provide centralized user access control for IT departments, making it easier to manage user accounts.
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
For a detailed explanation of Active Directory: http://en.wikipedia.org/wiki/Active_directory
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.
When an application user starts your application, and the ‘Automatically Sign-In’ option is set to ‘Yes’, your application will try to sign in using the application user’s identity information provided by Microsoft Windows. This is frequently referred to as ‘single sign-on’. If sign-in is successful, the application will retrieve the application user’s roles from the Active Directory. ‘Roles’ refers to the Active Directory’s User Groups for which the application user is member. If any of these roles matches any of the specified roles for the page, the page will be displayed. If the roles do not match, the application user is redirected to the Forbidden page. If the user can’t be authenticated by the Active Directory, he is redirected to the Sign In page. (Note: The application user will not be signed in if the requested page’s security role is set to ‘Everyone’, ‘Anonymous’ or no roles are configured for the page. Application sign in occurs only when requesting a page that requires secure access.)
Your application retrieves roles (groups) from the Active directory for the user name provided at sign in. Valid name formats are:
username. In this case the application assumes that the user belongs to the default domain. The user is validated and all roles are retrieved from the default domain controller.
domainname/username; domainname\username; username@domainname.com;
The application user will be authenticated and the roles will be retrieved
for all domain controllers which have domainname.
When your application decides whether a user has access to a particular page or control, it compares its list of user roles and the list of roles applicable to the page. If there is a match and the application does not have domain\no-one role, the application user is granted access to the page or control.
Example:
DC1: LDAP://DC=dom,DC=com (default)
DC2: LDAP://upperdomain.dom.com/DC=dom,DC=com
roles for page1: dom\no-one; upperdomain\signed-in users
Example 1: The user signs in as: username // password
He will be authenticated against the DC1 and if username / password combination is valid, than all his roles will have the format of dom\role1;dom\role2, etc. So when he attempts to open page1, he will be forwarded to the Forbidden page because for dom this page has the ‘no-one’ role set.
Example 2: The user logs as upperdomain\username // password.
In this case, the user is authenticated against DC2 and if username/password combination is valid with this domain controller, his roles will be upperdomain\role1;upperdomain\role2,... dom\role11;dom\role12... (because DC2 has both domains in its definition: upperdomain and dom). So when access to page1 is requested, the application will deny access for domain dom, but allow this user to access the page1, because the user also belongs (has roles) to domain upperdomain and page1 has the upperdomain\signed-in users role set.
This structure allows you to fine tune access rights for different domains. Note: that if domain controller has several domains in its connection strings all of them will be included in the list.
If the page has All Domains\No one role, then no one will be able to see this page. However, if the page has domain\No one and otherdomain\otherrole roles, users that have otherrole and belong to otherdomain will be able to see the page.
Controls with roles specified either shown or not depending on user’s roles and they do not cause redirection.
The Active Directory Groups role management implementation recognizes only direct members of any group (role). It does not recognize nested groups (roles). For example, assume user ‘BradPitt’ is a member of the ‘HollywoodActors’ group and this group itself is a member of the ‘Actors’ group. If you restrict access for a page to the ‘Actors’ role, your page will not be accessible to ‘BradPitt’ unless you include ‘BradPitt’ as a member of the ‘Actors’ group.
The following special symbols are not allowed in the Active Directory group names:
/, \, ”, ;
These symbols are used as dividers between groups, domains and strings in Iron Speed Designer-generated applications. If an Active Directory group containing any of these symbols is used to secure a page it will not be recognized and may lead to a compilation error.
Some built-in groups such as Domain Users, Domain Admins and some others also cannot be used as roles.
Configuring Your System for Application Security
Configuring Microsoft IIS for Application Security
Active Directory Role Management
Microsoft Authorization Manager (AzMan) Role Management
Configuring Microsoft Authorization Manager (AzMan)
Handling SQL Injection Attacks