One key ability with the old ASP.NET pipeline is the ability to add an HTTP Module to the pipeline via configuration. The advantage was the ability to add, say, redirects or filtering to a web application's pipeline where access to the application's source was not available.
My understanding of OWIN middleware - whether katana, kestrel or later - is that adding middleware and ordering is a compile/build time action.
Or is there some mechanism to insert a component at the beginning of the OWIN pipe for a web application via web.config type configuration?
Related
I am used to .Net Core deployments on the server side calling webservices, so API calls are called server side.
I am now developing a portal using hybrid, .NET MAUI/Blazor. So razor views, services and C# inline.
The injected service is called from the inline, so the keys are not visible to the user but they are in the package making part of a call to a third party API. IP restrictions are not relevant here, it's a public portal so individual certs are no appropriate, so Azure AD examples online have keys in a settings file.
Is this safe? Is the app compiled, signed, encrypted etc by default. I have seen a Android specific secure storage API but believe this is more for keys or items they may enter locally on the phone. All API's are HTTPS so encrypted once in the packet, obviously want to avoid a bad actor getting the keys.
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
I am working on a scheduled task in Kentico and I need the task to call methods that exist in a separate web service. I'd like to know if it's possible or not and how to do that.
When connecting and interacting with web services there are no extraordinary steps that you have to take. There is a sample service present in CMSPages/WebService.asmx. that you can use as a reference to creating your own web service and you are free to add your own "asmx" handlers as you would to any other .NET application. Kentico is in the end a standard .NET application and you can create those without any problems.
Additionally I would recommend to using Web API 2.0 instead of the old asmx handlers. In order to see how you can create such web service you can check documentation which contains an example.
Looking at a standard new MVC 5 project in Visual Studio 2013 you can see that it now includes OWIN.
There's a new OWIN Startup class that configures auth however I can't see how/where MVC5 is registered with OWIN. Where does this happen?
I'm assuming here that all requests pass through OWIN before entering the MVC pipeline. Why else would they include OWIN?
Please note: I'm not asking how OWIN is setup, that's easily explained in the docs. I'm interested in how MVC5 uses OWIN.
Update: I figured out why MVC5 uses OWIN even though requests are handled by the IIS pipeline instead of OWIN.
MVC5 does not pass through OWIN, however it looks like this could change in the future. Instead MVC currently still needs to pass through the IIS Integrated Pipeline. The reason that OWIN is included in the default MVC project is so that MVC5 can use the Owin middleware components.
From the OWIN middleware in the iis integrated pipeline:
In order for an OMC to participate in this same, event-based execution
ordering, the Katana runtime code scans through the startup
configuration and subscribes each of the middleware components to an
integrated pipeline event.
This does change in ASP.NET vNext as Web.Api and MVC have been combined and abandon System.Web in favour of OWIN and project Helios.
MVC 5 is not registered with OWIN.
OWIN is registered to start before application (PreApplicationStartMethod).
And at Pre-application-startup, OwinStartup registered class is used to configure current application.
[assembly: OwinStartup(typeof(WebApplication1.Startup))]
The above line in startup.cs will load the class to configure OWIN.
Look further OWIN Startup class detection
We are experimenting with deploying an MVC app as an Azure web role. Currently the app is being hosted locally on our server. It has a few appSettings in Web.Config that can be changed by the users as part of the "Administration" module of the application.
I know this isn't a good practice for Azure because there will potentially be multiple instances of the application running with multiple Web.Configs, which makes updating them all a nightmare (if not impossible). My understanding is that the ConfigurationSettings specified in the service definition should be used instead of Web.Config so that settings are defined globally in one place that all the instances of the application can access.
My question is is it possible to programmatically update ConfigurationSettings similar to the way we update Web.Config settings, or would it be better for us to move those settings into a database or something else?
Yes, but unfortunately it is definitely not simple to do.
Follow this URL: http://msdn.microsoft.com/en-us/library/windowsazure/ee460809.aspx
It talks about a Svc Management API call that you can make to read/write the Service Configuration. It is a 64-base string which you'll need to decode, find XML flags in it that you want to change and re-encode it back and send it back to the API.
Not pleasant, but doable.