We are trying to run OIOSAML as an SAML SP in an Azure Website, but we encounter problems regarding the signing certificates. Azure websites will not allow us to install custom certificates, hence our SigningCertificate under the Federation node in the web.config file cannot be found. Do we have to move over to a Virtual Machine?
The Azure Web Sites team is currently working to add this feature. Specifically adding the ability for web sites to optionally load profiles which will support more certificate loading scenarios. The ETA for this work to be in production is within 2 weeks.
To help ensure we will be supporting your scenario, if you can provide a representative code snippet which is failing, we will validate that it works with the fix, before we go to production.
Thanks for your patience.
The Kentor.AuthServices SAML2 SP package can load certificates from files in App_Data and works on Azure. The Kentor implementation is not as complete as OIOSAML (yet, we're working on it) but if the functionality it offers is enough for you it can be an option.
Related
We're developing a managed app (using ARM templates) that will be deployed to multiple tenants. The solution will, among other things, work with SharePoint sites on the end users' tenant.
We have looked into using a single multi-tenant app registration with the appropriate rights. Because of security restrictions on the SharePoint API when using Azure app-only, a certificate must be added to the app registration and the PFX must be provided in all API calls.
We wish to have as little data at our end as possible, so the we hoped to include the application that connects to SharePoint as part of the deployment. However, this would lead to multiple apps having access to the same PFX, which doesn't seem safe.
I'm hoping there is a better way to go about this. Must the connecting web app instead be hosted on our end? Is there a safe way of storing the PFX in multiple locations, or make it accessible to multiple tenants? It is important to us that we can automate the process as well, preferrably using ARM or an automation job as part of the deployment ... At the very least, I would be thankful for suggestions on making any configurations relatively pain-free for the end user.
PS: We would like to avoid the use of service user accounts.
I want to setup SSL Certificates generator/manager for Custom Domains - using Let's Encrypt but I'm not able to find the right tutorial. I've done some research work and I'm able to setup Let's Encrypt Certbot on one domain/machine with nginx.
I have a web app on Azure which will serve multiple domains, so multiple custo domains from single IP. I want to generate SSL Certificates for custom domains on the fly.
I learnt that Openresty can help but I couldn't find any step-by-step article. How do I setup the SSL Management with Let's Encrypt. At this point I'm not sure if I need a stand-alone VM or if it possible to run as a set of REST API Endpoint on a Web Server? Any pointers? I appreciate any help!
Azure App Service does not currently include native support for Let's Encrypt, but there is a community-supported extension that gets the job done.
https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install
This extension uses a webjob to facilitate automatic certificate renewal, so the app must be Always On for automatic renewal to work. If you are using deployment slots, be aware that you need to install the extension in each slot, and then add a WEBJOBS_STOPPED = 1 slot setting to each non-production slot (assuming you're not using other webjobs on non-production slots that need to run in their non-production environments). This ensures that the webjob is always present on the production slot, and only runs on the production slot.
Also be aware that if you Web Deploy code to the app service from Visual Studio with the "Remove additional files at destination" file publish option checked, that doing so will remove the webjob from the slot to which you publish. You have a few choices if this applies to you:
Manually refresh the certificates every three months.
Reinstall the extension any time you publish (you do not have to reconfigure it).
Clone the webjob into your solution and publish it along with your project.
There may be other options, but those are the ones I've explored.
Microsoft has asserted that this extension constitutes support for Let's Encrypt, but Microsoft does not support this extension. Here's a place to vote for native support for Let's Encrypt on Azure if you think it's important:
https://feedback.azure.com/forums/170024-additional-services/suggestions/16957756-add-integration-with-let-s-encrypt
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.
I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...
I need some help with creating a simple WebRole that uses federated authorzation/authentication with LiveId and the Access Control Service. I'm able to get it working with a local test ASP.NET application, but can't seem to find any information on the steps necessary to do this with a Web Role that can be deployed to Azure. The only information that I've found is to handle this scenario using a custom STS and the ACS or just LiveID, but nothing that demonstrates using both together.
Is there currently a limitation with Azure that prevents this? I've read some articles that seem to indicate it isn't currently possible due to the Geneva Framework not being fully implemented on Azure - can anyone confirm?
Thank you very much for any help!
You may find this resource useful - http://code.msdn.microsoft.com/wifwazpassive. It shows how to use ACS in an Azure Webrole. It does use a custom STS, not LiveID, but given that it's using Geneva framework components it should be possible to make it work with LiveID.