Specifying Security Roles for Multi-Level Menus

Security roles can be list of comma separated role IDs or role names, depending on the type of security configured for the application. The application user must belong to one of the listed roles in order for the menu item to be displayed, and only roles applicable for the currently chosen role management type should be entered.

If security is not configured for the application or if a menu item should be displayed regardless of the security configuration, then the value of this attribute should be an empty string. The default value is the empty string.

Database security

If you are using Database security, the roles list is a list of role ID values, e.g.:

roles=”1,2,3”

The role ID values are those found in the ‘Role ID’ field you designate in the Application Security Wizard. Do not enter role names; the role ID is different from the role name. You will need to query the Roles table in your database to ascertain the proper role ID values.

Active Directory group security

If you are using Active Directory security, the roles list is a list of role names also referred to as ‘Active Directory group names’, e.g.:

roles="Ironspeed\admin,Ironspeed\engineering,All Domains\administrator"

Microsoft Authorization Manager (AzMan) role management

If you are using AzMan security, the roles list is a list of role names.

Microsoft SharePoint Groups

When application is deployed to a Microsoft SharePoint server, security is NOT applied to multi-level menus.

Standard (built-in) security roles

Iron Speed Designer has several ‘standard’ built-in security roles which may be used to configure your application in addition to the more definitive roles defined in your database, in Active Directory groups 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 sign-in’ access.
NO_ACCESS: No access is granted to anyone, regardless of their sign-in status. This is also called ‘No one’ access.

When adding roles to a menu item in a sitemap file, spell them exactly as shown above, i.e. enter “NOT_ANONYMOUS” if you want this menu to be shown only for signed in users.

Standard roles are used in database security have 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.