The easiest way to create modern business applications for the Cloud and Office 365
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:
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
best post. thank you
Nice article. I've one question, our AD Security groups contain spaces. LS doesn't like that. What can I do to use them?
LightSwitch does support security groups with spaces. "Domain Users", for example, is a common one we use in our own testing. Do you have any security groups that do work? Are you certain you're using Visual Studio 11 Beta, and not an earlier version of LightSwitch? If you would like, you can contact me offline via my blog at blogs.msdn.com/.../mthalman.
I found the problem :( We don't have Visual Studio. We only use the 'stand alone' lightswitch 2011.
Matt: Good stuff. Am having an issue validating permissions in my 2013 LightSwitch HTML application. The user/role management screens find my active directory user and the permissions from Access Control so problem setting up users and roles. But eve when I am in a role, and I debug this.Application.User, it has the correct user but no roles. If I enable "Granted For Debug" I see the Roles. Any Ideas
At debug (F5) time, the users/groups/permissions stuff works entirely differently. We did this to make debugging your permission logic easy -- so you could see what the effects of permissions would be without needing to change things in Active Directory or using the Users/Roles screen.
At F5 time, the only thing that matters for permissions is checking things on/off in the "Granted For Debug" dialog that you've found.
After the application is published, the permissions will be loaded properly based on the Role mappings defined using the Security Administration screens.
Thanks Matt, Thought it might be something like that
I'm developing a LS app for an enterprise customer. I'm trying to use their existing AD groups to allow inheritance of the role "Administrator". In the UI, the role is inherited to the individual user, but when I debug, it doesn't show up as one of the assigned roles of the user. In this article it is mentioned that group inheritance will be added in a future LS version. We're using VS2013 professional edition with (I assume) the latest build of LS. Does anyone know what might be causing this?
We trying to create AD groups and authentication based on that. But we are unable to create users in application. We are using VS2013. I Believe that some basic mistake we are doing it. Could you please help us in this.