LightSwitch 2013 HTML authentication without authorization

Question

I am trying to do something that I think should be very simple, but LightSwitch 2013 HTML is making it seemingly very hard.

I want to have a LightSwitch HTML client and web service that require Windows authentication. Any user is fine. I don't want to do any authorization beyond "yes, they authenticated."

When I enable Windows authentication in my LightSwitch properties, even for "any user," like so:

it seems that LightSwitch still wants to do authorization, so it wants the _IntrinsicData connection string set and pointing at a valid ASP.NET membership database. I've tried doing the following:

1. Setting authentication to none in LightSwitch and just having IIS do it - this causes repeated prompts and eventually a 401 in the client.
2. Changing the role provider configuration to use Windows instead of SQL as you normally would in straight ASP.NET - this causes the same repeated 401 in the client.
3. Various levels of code-based permissions as described at http://msdn.microsoft.com/en-us/library/vstudio/ff851957.aspx - this causes repeated 401 or doesn't seem to do anything depending on where I set it.
4. Completely removing or disabling the role provider from web.config - this causes LightSwitch to complain at the next create/update that the Role Manager is disabled.
5. Messing with deny and allow entries in web.config and authentication set to Windows while the app properties are set to anonymous; that leads to 401.

If I leave the settings as shown and do nothing special, then when a create/update operation is submitted, LightSwitch tries to talk to the non-existent membership database and times out eventually.

How do I get authentication with blanket authorization without having to carry around a membership database?

Answer 1

LightSwitch will still want to have the membership database tables around even if you specify to allow any Windows user. This is because there is still an administrator user for the app and the tables are needed for storing the admin info. And the admin can add specific users or groups and assign them to roles that could give them access to parts of the app that the rest of the authenticated users would not have. In other words, any Windows user can use the app, but some of them may have more privileges than the rest and the membership DB is necessary for that purpose.