In Visual Studio 11 Beta, LightSwitch has introduced the ability to use Active Directory security groups to control access to the application. In the first release of LightSwitch, it was only possible to control access by registering each individual Windows user in the application. Application administrators can now register security groups as well. By adding a security group, all authentication and authorization rights associated with that group apply to the members of that group. Note that only security groups are supported – not distribution groups.
The following screenshot shows adding a security group with an account name of "CONTOSO\BuildingA" to the list of registered accounts, giving all members of that group access to this application.
LightSwitch also supports nested groups. For example, let’s say the Contoso company has the following groups and users in their Active Directory:
- Kim Abercrombie
- Account name: CONTOSO\kim
- Member of: CONTOSO\BuildingA_2ndFlr
- Building A – 2nd Floor (security group)
- Account name: CONTOSO\BuildingA_2ndFlr
- Member of: CONTOSO\BuildingA
- Building A (security group)
- Account name: CONTOSO\BuildingA
When an administrator adds "CONTOSO\BuildingA" as a registered account in the application, this grants all member of that group to have access to the application, even if that membership occurs as a result of nested groups. Thus, Kim would have access to the application because she belongs to the “CONTOSO\BuildingA_2ndFlr” group, which is a member of the “CONTOSO\BuildingA” group.
Role inheritance applies the roles assigned to a registered security group to all members of that group—the members of the group inherit any roles assigned to the group. Using the Contoso example, let’s say that "Building A" and "Kim Abercrombie" are both listed as registered accounts in the application. If the "Sales Person" role is assigned to the "Building A" security group, then when Kim is selected in the Users screen, the "Sales Person" role appears in her list of assigned roles. The role assignment also indicates that the "Sales Person" role is inherited from the "Building A" security group, as illustrated in the following screenshot.
If a user belongs to multiple groups, the user inherits all of the roles assigned to those groups, in addition to any roles explicitly assigned to that user. Inherited roles are treated as read-only so it is not possible to remove a role that is inherited. For example, you wouldn’t be able to remove the SalesPerson role just for Kim.
One thing that is not yet implemented in the Beta release is support for checking role membership or whether a user has a permission in server-side code. That is, if you write code that executes on the server and calls User.IsInRole or User.HasPermission, those methods will not take into account group membership. This will be supported in the final release.
When publishing a LightSwitch app configured to use authentication you are prompted to define an administrator account, which can now be a security group.
Active Directory group support greatly simplifies the administration of user access to your LightSwitch applications. No longer will you need to add each user individually. Just add a group and you’re done.
For more information see: How to Create a Role-based Application
-Matt Thalman, Visual Studio LightSwitch Team