We have to develop a larger application with an Angular App on top and a lot of ASP.NET Core based Microservices under the hood.
Also we have to support external applications.
The external applications can be services without UI and also user GUI client applications.
Now the requirement is, that all internal Microservices are auto-trusted automatically and only for external Application the user should get the trust workflow in IdentityServer.
We're not sure how the workflow here should be configured or is be named in this scenario.
I think we need two different workflow configurations for internal and external application trusts.
Can anybody push me into the right direction which workflow and configuration fits most to our requirement?
Following providers we have to support:
- Simple Forms Authentication for our platform
- External Azure Active Directory
Related
I've seen that Azure App Service mobile apps can implement authentication for multiple identity providers via a single client SDK. If an app hosted on Azure App Service is using ASP.NET Core in the cloud, though, can its UWP or Windows Store client app also benefit from multiple identity providers via a single client SDK?
If yes, then how does that work? Does it use the same mobile client SDK?
If no, then how would I authenticate such a mobile client? Will I have to use individual provider SDKs?
I know ASP.NET Core is still prerelease, but I'm wondering:
What multi-provider authentication functionality is available from a mobile client now?
What such functionality is planned to be available when ASP.NET Core 1.0 is finally released?
What such functionality will likely be on the roadmap for the future?
Azure App Service provides authentication as a service. In other words, the client authenticates to the service, and the service passes on the authentication to you.
Underneath, the app service passes a number of authentication related app settings within environment variables that you can read via the normal method. The original JWT is also passed in via the X-ZUMO-AUTH header.
For your clients, probably the best way is to use the Azure Mobile Apps client SDKs - there are clients for .NET (Xamarin, UWP), JavaScript, iOS and Android. You don't need the data access functionality - just the client creation and login / loginAsync method calls.
For your server, take a look at the Authentication Overview for more information. You may also want to read some of the info in Chris Gillums blog for more technically details.
Context:
Building new multi-tenant application using Azure SQL, Azure Table Storage, EF, Web API, MVC, Azure Cache, Possibly Worker Roles -- all the usual suspects:
Please see prior question asked/answered a while back (Jun '12): What is the difference between an Azure Web Site and an Azure Web Role
Side Note:
I'm leaning towards Web Role/Worker Role for Web API and Web Site for MVC/CMS frameworks (i.e., DotNetNuke)
I understand Web Sites are out of beta and have closed the gap with the Web Role in some respects.
Question:
I'm looking for an updated answer to the following:
What are the material differences between the new Azure Web Sites and the traditional Azure Web Roles for an ASP.NET MVC and an ASP.NET Web API application? What reason would I choose a "web site" over a "web role" or vice versa?
Nowadays you have the following execution models:
-Web Sites
-Cloud Services (Worker Role / Web Role)
-Mobile Services
-Virtual Machines
What are the differences between Cloud Services and Web Sites.
-Cloud Services:
You could integrate with Team Foundation Services and allow it to publish to Azure. (Continuous Delivery). With Cloud Services (Web Role), you have two environments in Azure, staging and production. You can use Staging to validate, and with one click (swap option), apply the new deployment package to production environment.
-Web Sites:
Web Sites is the right option when you want to create a simple web site. It is also a good choice for creating a low-administration web application, even one that must be quite scalable, or moving an existing IIS web app to the public cloud.
Cloud Services, which was the initial execution model provided by
Windows Azure, is an explicitly PaaS approach. While the line between
PaaS and web hosting is blurry, Cloud Services differs in some
important ways from Web Sites, including the following:
Unlike Web Sites, Cloud Services gives you administrative access to
your application’s VMs. This lets you install arbitrary software that
your application needs, something that’s not possible with Web Sites.
Because Cloud Services offers both web roles and worker roles, it’s a
better choice than Web Sites for multi-tier applications that need
separate VMs for their business logic. Cloud Services provides
separate staging and production environments, making application
updates somewhat smoother than Web Sites. Unlike Web Sites, you can
use networking technologies such as Windows Azure Virtual Network and
Windows Azure Connect to hook on-premises computers to Cloud Services
applications. Cloud Services lets you use Remote Desktop to connect
directly to an application’s VMs, something that’s not possible with
Web Sites.
http://www.windowsazure.com/en-us/manage/windows/fundamentals/compute/
More info:
http://www.windowsazure.com/en-us/manage/services/cloud-services/how-to-create-and-deploy-a-cloud-service/
I am new to Windows Azure and I have a question.
I have:
Web site which deployed to Windows Azure - The web site manage a table (add, edit, delete). I used this guide: Deploying an ASP.NET Web Application to a Windows Azure Web Site and SQL Database
Andorid application & iOS Application (Native Code).
Now, I want the mobile applications to get data (in JSON format) from the web site (and from the DB).
What is the best practice to do that?
I tried to create a Azure (WCF) Service (the project refrenced to the web site project) but I didn't succeded. If this is the way - Is anyone knows a good tutorial to do that?
Is there another option? Maybe from the web site itself?
Thank you very much,
Yuval
If you want to integrate with non-Microsoft technologies I suggest you take a look at the ASP.NET Web API which allows you to build REST services using content negotiation. Content negotiation allows your consumer to specify the format it requires (json, xml, ...).
To host the ASP.NET Web API in a Windows Azure Web Site you should take a look at Carlos' blog, he describes in detail what you need to do to make this work: Creating ASP.NET Web APIs on Azure Web Sites
Have you given ASP.NET Web API a look-see?
http://www.asp.net/web-api
I'm having a hard time wrapping my head around some architectural elements to securing a core WCF service that is consumed by many different applications.
Internally, we have an application that allows HR folks to update a peron's details. This is contained in a WPF app. Externally, we have a website that would allow individual people to authenticate (throuh an AD Membership provider) and update their details.
We don't want users to be able to see other user's information (for obvious reasons). But we don't want to host this service inside the same web application that the users would log into. Here is how the architecture would look from a visual studio perspective:
ServiceApplication
WpfApplication
MVCWebApplication
They don't exist inside the same domains, for example, the service application would be hosted at http://www.service1.com/Service.svc and the mvc application would be hosted at http://www.updateyourprofile.com . So a user logs into http://www.updateyourprofile.com and we'd like to hit a Wcf service via JSON. Both the service application, wpf application, and mvc web application would use AD credentials to authenticate. But how do we secure the service so that users who log into the mvc web application can only see their information?
Most of the examples I see say to use the HttpContext.Current.User check inside the service. But since the user authenticated at a different site, how does the cookie transfer? Do you end up having to publish your service inside the same web application that you want to consume so that the cookies travel transparently?
Or is it just not possible to have a centrally located service with disparate applications that use the same authentication store to determine who has access to what on the service?
What you are looking for is some kind of federated authentication system which is used by all the entry points. That is what Windows Identity Foundation can help you to build.
Inside each application, access control would be claims-based, according to the claims embedded in each user's security token issued by the authentication system.
There's an entire book on the subject on MSDN.
I have a WCF service that uses Membership for security. If I create a Silverlight Business Application It automatically links in with it and authenticates. How do I do the same with Windows Forms, and possibly XNA?
You can use Microsoft's Client Application Services http://msdn.microsoft.com/en-us/library/bb384297.aspx. I think that is what you are looking for.
Client application services make it easy for you to create Windows-based applications that use the Microsoft Ajax login, roles, and profile application services included in the Microsoft ASP.NET 2.0 AJAX Extensions. These services enable multiple Web and Windows-based applications to share user information and user-management functionality from a single server. For example, you can use these services to perform the following tasks: