Geek Answers Handbook

How to redirect Azure ACS if the data center drops

We are looking for a way to provide fault tolerance for ACS instances, so if one data center is disconnected, authentication through ACS will automatically end in another data center.

Background:

We use ACS to convert SAML tokens that are provided by the specially developed STS under the WS-Trust protocol. ACS is used for brokerage trust between our STS and a number of relying parties that are developed by third parties. Relying parties are currently configured to connect to a specific ACS instance using its DNS URL.

We reviewed the following:

  • Using the DNS CName record to mask the ACS URL does not work because the new DNS will not match the SSL certificate in the instance and we cannot control the SSL certificate.
  • Using a proxy before ACS to route requests to it does not work, because the To and Realm addresses in the messages do not correspond to the acs namespace.
  • The traffic manager does not work because of both 1 and 2, and because it currently does not allow you to directly download an address that does not end with .cloudapp.net.
+4
source share
3 answers

I do not think there is a realistic and reliable solution here. As already noted, you can create additional namespaces in other data centers and back up your configurations and RP conversion rules. For recovery, your customers will need to reconfigure their applications to use the new namespace after restoring the backup to the new namespace. This may work in some scenarios (e.g. integration of Google and Yahoo!). It may even work (I think) for Active Directory integration. This is very problematic if you do not control the RP.

Another, but blocking problem with this approach (at least for us) is that it will not work with Windows Live name identifier names. For our users, we use a different namespace. Thus, even if we restore all our settings in another data center (and we also control the RP!), Our Windows Live users will not be able to log in correctly because their name identifiers will no longer correspond to the new namespace. Google and Yahoo! there will not be this problem, as they can use a persistent requirement (e.g. email).

Basically, it seems that you are mainly in the grip of the operational group of data centers to quickly switch to a backup resource in the event of a complete loss of the data center.

0
source

Not sure if this will help, but you can implement some kind of custom local solution in case of DC failure for ACS. Using Windows Azure Cmdlets together with RSS polls on the service bus panel may work.

See the MSFT Guide on this topic for SB 2.0 namespaces below ...

ACS 2.0 Namespaces

ACS 2.0 backs up all namespaces once a day and stores them in a secure, remote location. When ACS personnel determine that it has not been able to recover data loss at one of the ACS regional data centers, ACS may attempt to restore client subscriptions to restore the latest backup. Due to the frequency of backups, data loss of up to 24 hours may occur.

ACS 2.0 customers who are interested in data loss are encouraged to consider the set of Windows Azure PowerShell cmdlets available through the Microsoft Sourceplex Open Source Repository. These scripts allow administrators to manage their namespaces and import and extract all relevant data. Using these scenarios, ACS clients have the ability to create their own backup and recovery solutions for a higher level of data consistency than ACS currently offers.

In case of distress notification, information will be published on the Windows Azure Service dashboard describing the current status of all Windows Azure services around the world. The dashboard will regularly update disaster information. If you want to receive notifications for breaks in any services, you can subscribe to RSS feeds of the service in the Dashboard service. Alternatively, you can contact support by visiting the support options for Windows Azure and follow the instructions to get technical support for your services.

NTN

+1
source

First of all, Azure does not have an ACS backup solution, so developers and users are open to creating what works best. Based on my understanding, if you want to create a Fail-over script for your application to transfer a role from one ACS to another ACS, this can be done in your relying third-party application (website), as shown below:

  • You have configured ACS1 and ACS2, where ACS2 is the backup. Both ACS use Relying Party configured to use the same application with identical Realm and Return URLs.

  • In the Relying Party application, when ACS fails to log in when entering the system, ACS provides the error details of the JSON-encoded HTTP code URLs to the application using the application

    2.1 It is possible that the error is related to ACS 2.2 Perhaps the endpoint of the ACS was not even found

  • In both cases, you can handle the error in your code and create a retry policy to try ACS2. You can add code to try when to go ACS2, and when to continue trying ACS1 depends on how you want.

If in the end you have 2 ACS endpoints, just try to keep them the same to get the same result, regardless of which one is really authenticated in the request of the RP application.

If you want to back up ACS at the management level, see "Windows Azure AppFabric Access Control Service" (ACS) - backup and recovery resources , you may need to be available if ACS fails, otherwise you can automate it in your application RP (great job).

+1
source

More articles:


All Articles