Answered by:
Login Application in Visual Studio lightswitch in a SaaS application

Question
-
I have the following scenario:
I will create an application where several organizations will use the software in the clouds in the azure windows.
Every organization has multiple users.
Each organization will have a SQL database AZURE individual 5 GB.
At the time of login the user should inform:
LOGIN:
PASSWORD:
ORGANIZATION:
When you log into the software system will have to define the connection from the database according to the organization and also to filter all data according to the organization so that the user who logged in to access only data of the organization he belongs.
NOW YOU CAN DO THIS IN VISUAL STUDIO lightswitch?
HOW TO CREATE CUSTOM LOGIN SCREEN IS, HOW CAN I SET THE CONNECTION OF THE BANK IN ACCORDANCE WITH THE ORGANIZATION AND HOW CAN FILTER ALL DATA ALL INQUIRIES UNDER THE ID OF THE ORGANIZATION.
Att,
JardimBrasil
Thursday, October 14, 2010 3:51 PM
Answers
-
That is the key step. If the user is authenticated, the login prompt will not appear.
Ok I think I now see what you're saying "if you have Forms Authentication, yet the user is not authenticated ,the LightSwitch login box will popup. That is by design".In my case, the user has been authenticated by DotNetNuke, using 'forms autentication', by the time they get to the page displaying the LightSwitch .xap.
This is what will be fixed in Beta 2.
- Marked as answer by Beth Massi - MicrosoftMicrosoft employee Thursday, November 11, 2010 5:09 PM
Monday, October 18, 2010 3:27 PM
All replies
-
i think you are asking a few questions here, so i will try and repeat what i think the questions are, and then answer them
Question 1) is there a way to customize the login screen
Answer: not in beta 1, and not officially in V1. However, an unsupported for V1 (meaning it's not an officially supported scenario, and that we might break it completely in V2) scenario is using a custom login.aspx page when LS apps are configured for Forms auth.
Question 2) is there a way to change the database connection string based on who is logged in?
Answer: No.
If your business requirements are that some people go to database A, and some people go to database B, those would need to be seperate deployments of the same LS application. users who should go to A should be given permission to applicaiton A, and users who should go to B should be given permission to application B.
Infact, you could combine logic in the custom login page to decide which LS application to direct people to, and make it _seem_ like one big application.
Question 3) can LS filter data so only the right people can see it
Answer: Yes. LS has a users, roles, and permissions system. Users are placed into roles, and permissions are granted to roles. In an LS application, you define the names of the permissions at development time, and anywhere you can write code, you can do permissions checks, such as
if (User.HasPermission(Permissions.CreateInvoice)) {
// create the invoice
}
You create LS users and Roles after the application is deployed. You then use the built-in administration screens to give the permissions you created earlier to the various ROles, and to put users in the appropriate roles.
One final thing i am concerned about: i am confused about the architecture of your app. Are different customers connecting to different databases, with different connection strings? Or are all the customers in in the same database, and should only be able to see some of the data in that database?
- Proposed as answer by ADefwebserver Saturday, October 16, 2010 5:48 PM
Saturday, October 16, 2010 9:51 AM -
Here's an example of the architecture of my software below:
• I have several clients who will use the software that will develop school-based management in the SaaS model:
SCHOOL 1
SCHOOL 2
SCHOOL 3
SCHOOL 4
SCHOOL 5
And so on.
• Each school will have an SQL database AZURE 5 GB.
• Each school will have several users who use the software in the clouds.
The Directors
o Teachers
Answering the
the Students
• All schools use the same instance of the software on Windows Azure, but each school will have its individual database to 5 GB in SQL AZURE.
• At the time that a user is logging into the software, it will report:
SCHOOL ID
USER
the PASSWORD
• Once you enter these information the system will search my database of business management in the register of my clients SCHOOL ID and return the database connection string correct school who are logging.
• After finding the database connection that is logging the school, the school management system should establish a database connection that is logging in from school and validate the username and password and so enter into the software database connected to the school that logged .
So my question is whether the lightswitch VISUAL STUDIO allows me to do all this configuration incicial that is totally related to the LOGIN application?
Using VISUAL STUDIO PROFESSIONAL together with VISUAL STUDIO lightswitch could create the features described above?
Saturday, October 16, 2010 5:11 PM -
Question 1) is there a way to customize the login screen
Answer: not in beta 1, and not officially in V1. However, an unsupported for V1 (meaning it's not an officially supported scenario, and that we might break it completely in V2) scenario is using a custom login.aspx page when LS apps are configured for Forms auth.
Matt, If I may jump in here with my suggestion because I think think Jardim may be facing the same situation that I am in trying to get LightSwitch to work with DotNetNuke. Keeping in mind that Silverlight applications work great in DotNetNuke (see: http://dnnsilverlight.adefwebserver.com/Silverlight40/ExpenseReport/tabid/88/Default.aspx).
All I need LightSwitch to do is to simply only display the login box if I specify authentication. Period. If LightSwitch does this one thing, then a programmer can get it to work in 100% of the situations that Jardim and I are asking about. The reason is that:
1) We authenticate the user using our own method (in my case I would allow DotNetNuke to log the person in), and then in code we can use this line:
HttpContext.Current.User.Identity.Name
To get the current user. We can then provide access to the resources the user should get to.
The problem is that in Beta 1 the LightSwitch box will always pop up if it detects the site is running under Forms Authentication. I think the reasoning on the LightSwitch team is that "our code that looks at the membership tables needs the login box to work".
The use case that I don't think is being made clear is that in many cases we want to completely bypass the built-in LightSwitch security and programmatically control access to the LightSwitch application. This WILL allow me to (actually quite easily) implement what Jardim is asking.
There would be no need for a "unsupported hack". LightSwitch security simply needs to only display a login box when it is specified in the configuration. This one small thing will open a world of implementations that will allow us to deploy LightSwitch in a ton of scenarios.
Saturday, October 16, 2010 6:02 PM -
Michael,
I mentioned in this thread (http://social.msdn.microsoft.com/Forums/en-US/lsextensibility/thread/66df9bef-fcdd-480f-b231-44eb6c36e9db) that in the next LightSwitch release, there is a fix that will prevent the login page from appearing if the user is already authenticated through any other means. Does this solve the issue as you see it?
Monday, October 18, 2010 1:19 PM -
Michael,
I mentioned in this thread (http://social.msdn.microsoft.com/Forums/en-US/lsextensibility/thread/66df9bef-fcdd-480f-b231-44eb6c36e9db) that in the next LightSwitch release, there is a fix that will prevent the login page from appearing if the user is already authenticated through any other means. Does this solve the issue as you see it?
Yes it does, however, recently I got this feedback:and then I read this thread about "unsupported for V1 (meaning it's not an officially supported scenario".
So as you can imagine I was a bit worried :)
I feel I do understand why the carefully constructed LightSwitch "primary use case" needs certain things to happen for things to work. I just wanted to make sure we have the option to say "I want to do the security myself" yet still use 90% of the benefits of LightSwitch.
As soon as I am able to create a full application, about 10 minutes of custom code, and then upload it into DotNetNuke and administrators of the portal are able to edit records and everyone else is only able to see them... well game over :)
Only thing left will be the printing situation... :)
Monday, October 18, 2010 2:00 PM -
I would agree with the resolution of that bug as "by design" according to the original description of the bug. That is the default behavior if you've manually set the web.config to use Forms auth because authenticating the user outside of LightSwitch wasn't mentioned in the original description. That is the key step. If the user is authenticated, the login prompt will not appear.Monday, October 18, 2010 2:23 PM
-
That is the key step. If the user is authenticated, the login prompt will not appear.
Ok I think I now see what you're saying "if you have Forms Authentication, yet the user is not authenticated ,the LightSwitch login box will popup. That is by design".In my case, the user has been authenticated by DotNetNuke, using 'forms autentication', by the time they get to the page displaying the LightSwitch .xap.
This is what will be fixed in Beta 2.
- Marked as answer by Beth Massi - MicrosoftMicrosoft employee Thursday, November 11, 2010 5:09 PM
Monday, October 18, 2010 3:27 PM -
Yep, exactly right, Michael.
Monday, October 18, 2010 3:34 PM -
This is great. It was the only thing standing in the way of a major "use case".
Moving forward this will be my concentration, easy deployment and integration of LightSwitch with other systems.
The extensibility points are brilliant. It is so easy to hook into what screens display, and what Entities (tables) a person can see, and what records they can see (by adding a linq statement that filters the records).
The "hooks" are right there, easy to get to, easy to understand. most of the custom code you create ends up in just a few easy to locate files. Don't even get me started on how easy it is to do custom validation...
There are some really exciting things coming...
Monday, October 18, 2010 3:52 PM -
There is an IsInRole method. This is an implementation of the System.Security.Principal.IPrincipal interface's IsInRole method.
The point of roles is a grouping mechanism of permission assignments. Since roles can be added and removed in a deployed app by an administrator, it would be better to write code against permissions instead of roles.
Tuesday, June 21, 2011 2:21 PM -
@Matt. Why is there no User.HasRole()? What is the point of roles if we check back to permission level. Maybe I missed it. tia
Roles were not something we wanted to expose in the security programming model. Roles are the indirection object between users and permissions; they're a convenient way for administrators to manage which permissions a given set of users should have.
So putting users in roles is how the permissions of that user get populated today. But you could imagine in the future that permissions might be populated and defined in some other way. If you were writing code that looked for specific roles, that might break in the future. If, instead, you looked for the presence of a certain permission on the user, your code is abstracted from how the principle in question was granted that permission.
And, as Matt Thalman said, Roles are an administrator defined thing; coding against them would be equivalent to hardcoding your app to need specific data.
Permissions, on the other hand, are modelled and thus more strongly typed in your programming experience.Tuesday, June 21, 2011 2:24 PM