Authentication Features in Visual Studio LightSwitch

LightSwitch lets you configure your applications to use authentication.  This allows you to control who is able to access the application and lets your business logic know who the current user is.

Configuring the type of authentication to use

LightSwitch developers can choose what type of authentication to use for their application.  The options are no authentication (the default), Windows, or Forms.  For Windows authentication, the application user’s Windows credentials are used to authenticate their identity.  For Forms authentication, the application user must login with a user name/password combo to be authenticated.

 
Access Control tab (Beta 1)

Side note:

One interesting feature for a LightSwitch developer allows for the application to be debugged without needing to sign in. So if the application is configured with Forms authentication, the developer can hit F5 to run the app and not have to worry about signing in. Otherwise, the sign-in screen would be a major nuisance during iterative development. Not until an application is deployed will the user be prompted to sign in. If you have code which checks for the current user, it’ll still work when you are debugging even though you haven’t explicitly registered a user. A transient test user is used as the currently running user. Post-beta 1, LightSwitch will actually use your current Windows credential as the currently running user when using Windows authentication.  

Current user API

A LightSwitch developer always has access to determine who the current user is.  When writing code within a Table or a Screen, for example, you have access to the current user through the following code:

Microsoft.LightSwitch.Security.IUser currentUser = this.Application.User;

This provides access to the user’s username, full name, and other important bits of information like permissions and roles.

Managing your users

Users are managed within the running application.  Only users with the built-in SecurityAdministration permission have the ability to manage users.  By default, the administrator account that was specified when the application was published has the SecurityAdministration permission assigned to it.  Those users with this permission will see the Administration navigation group with a Users and Roles screen when they open a LightSwitch application.  (This is the default behavior for a new LightSwitch application.  The developer is free to rename or remove the Administration group, create a new navigation group for the administration screens, or even add custom screens to the Administration group.  This can be done through the Screen Navigation tab of the application properties of the LightSwitch project.)

Administration Screens (Beta 1)

You can manage your users in the Users screen:

Users Screen (Beta 1)

Side note:

When using Windows authentication, the registered users are stored independently of Active Directory. This means there is no need to administer the domain by adding certain users to a group in order to give them access to a LightSwitch application. The users are directly managed through the LightSwitch application. This was an intentional design decision since many LightSwitch apps are going to be departmental apps where the person administrating the app doesn’t have permission to make changes to the company’s Active Directory.

Authentication during application start-up

When a LightSwitch application is configured with Forms authentication, the user is automatically prompted for their user name and password:

Log-in prompt (Beta 1)

When using Windows authentication, the user is automatically authenticated through their Windows credentials when the application is opened so no prompt is shown.