Base solution for your next web application
Starts in:
01 DAYS
01 HRS
01 MIN
01 SEC

Activities of "dev1_premierpoint"

Thanks.

I don't think AspNetZero does #3 above as that would be a manual process that needs to be done in Azure AD by the customer. Otherwise, I agree with you that #1, #2, and #4 are things AspNetZero already does.

Once, I test this out in our environment, I will post back here with the results. I am hoping it works without any code changes at all.

Thank you.

Also, for the record, there was nothing wrong with my appsettings.production.json configuration. It is correct as it is shown above. This all had to do with the Sql Connection problem.

Also, one thing I did that may or may not have been required is to add ASPNETCORE_ENVIRONMENT = Production as a envrionment variable to my Azure App Service using the Azure Portal.

Once I learned a little bit about AspNetZero's approach to logging and found the log file, it turned out that the problem was that the Azure Service App could not connect to the Azure Sql Database.

The reason for that was that your documentation page about publishing to Azure App Service (https://docs.aspnetzero.com/en/aspnet-core-mvc/latest/Deployment-Mvc-Core-Azure) does not really address how the Azure App Service and the Azure Sql Database need to be configured to communicate.

It turns out that there are lots of different options for getting an Azure App Service to talk to an Azure Sql Database and the level of security goes from poor to good depending on which option you choose to set up.

I chose one of the "good" security options, but its more complicated to configure and I didn't quite get it right. So, that turned out be be my problem.

FYI, the "easy", but "poor security" option is to enable this setting in your Azure Sql Server:

The reason this option offer poor security is that when you turn it on, all of Azure (ie. every Azure customer in the Region) can access the SQL Server through its firewall.  Of course, they need a good user name and password to login, but still its a bad practice to leave your SQL Server open to this.

The more difficult to set up, but good approach to security is to set up a Vnet for the Azure App Service and Azure SQL Server to use for private communication.  I've got that working now in my deployment.

Thanks for pointing out that I did not specify my version.

Here it is:

AspNetZero 7.2.0 - Asp.Net Core MVC & jQuery AspNetCore 2.2.0 Targeting .Net Framework 4.6.1

I have been thinking about this topic and studying the sample you referred me to and have come to the conclusion that what I really want to do in my AspNetZero app is different than what I originally thought I wanted to do.

I think that what I really need to do is use the Azure AD "Password SSO" integration pattern described here:

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-password-single-sign-on-non-gallery-applications

With this approach, I am thinking that my SaaS customers will set up my application as an "Enterprise Application" in Azure AD and configure it to do Password SSO with my AspNetZero app.

It appears that this approach will allow Azure AD to store the user name and password from my AspNetZero app in order to facilitate SSO.

The only requirement for the AspNetZero SaaS app is that it supports forms authentication - which it does.

Using this approach, my thinking as far as "onboarding" of a new tenant and that tenant's users is currently something like this:

  1. We manually add the new tenant in AspNetZero (or provide a new tenant registration page\process for self-service)
  2. We manually add the initial Admin user for the tenant (or provide an Admin user self-service registration process)
  3. The new Tenant Admin user would need to be an Azure AD admin as well and would then configure our AspNetZero app in their Azure AD tenant as an "Enterprise Application" and configure it for Password SSO.
  4. Then, the AspNetZero Tenant Admin can manually create AspNetZero Tenant Users in our AspNetZero application and those Tenant User's user names and passwords will be synchronized back to Azure AD for purposes of SSO with our AspNetZero app.

Do you think I am on the right track here? If so, it doesn't sound to me like there is any work for me to do in AspNetZero to make it ready for this approach to SSO. Correct?

Yeah, i got it to work by adding this code to AccountController.cs:

The View for the Login page already had a check for the DisableTenantChange property of the ViewBag.  So, no change in Login.cshtml was necessary.

As far as your documentation goes, later that day it occurred to me that I was probably being too hard on you.  I was just frustrated that I was having to keep digging on my own.  Then I realized that is one of the reasons that there is a job description named "Developer". :)

Continuing to grind on this and it is now looking like I made the change to the wrong Module class.

I changed PhoneBookDemoWebCoreModule.cs.

It looks like I should have changed PhoneBookDemoWebMvcModule.cs, instead.

(Whew, this N-layer architecture of ASP.Net Zero\Abp, can sure get confusing at times.)

In the WebMvcModule I ended up commenting out this existing line:

and replacing it with this line:

Its working now in staging and production.  The "Tenant Switcher" is still showing on the Sign In page, but surely I can figure out how to remove it.

You guys have extensive documentation, true, but your architecture is so complex that it seems that there are still a lot of under-documented areas.   I would say this is one.

I figured out how to get past this error, but the addition of the MultiTenancy.DomainFormat property does not seem to make any difference in getting the application to resolve tenant based on subdomain. So, I still need help with figuring that out.

For anyone that runs across this ticket later on, here is what my problem was when getting the ComponentNotFoundException:

I need to to a type to the Depends On attribute at the top of the module. I needed to add this:

which the required this:

using Abp.Web

Now the application will load again from the staging server.  But, still no success in getting tenant resolution via subdomain.

I'm going to open another ticket on the subdomain resolution problem since that wasn't the primary subject of this ticket.

Ok, thanks for pointing me in the right direction.

Showing 31 to 40 of 41 entries