Azure ACS configuration for Local and Production

Question

What would be the best way to configure Azure ACS so that when I run locally in the development fabric I can still authenticate?

I just want to configure once and be able to develop locally and publish to azure without having to make changes to the config. I'd even be open to not using Federated Auth when developing locally as long as I could somehow fake a claim.

score 4 · Accepted Answer · edited Apr 01 '13 at 09:20

4

You can have of Web.Config and Web.Release.Config (transformation file per build configuration). Web.Config is for your local development where you have realm, audience URLs pointing to your local address i.e. 127.0.0.1. You then can write transformation file for Web.Config, e.g. Web.Release.Config where you would write transformation to replace above value with actual deployment URLs. I am assuming that you would use release build for deploying to azure.

This is how your web.config.release would look...

<microsoft.identityModel>
    <service>
      <audienceUris>
        <add value="https://abc.cloudapp.net/" xdt:Transform="Replace" />
      </audienceUris>
      <serviceCertificate xdt:Transform="Insert">
        <certificateReference x509FindType="FindByThumbprint" findValue="AAAAAAAAAAAAAAAAAAAAAAAAAAA" storeLocation="LocalMachine" storeName="My" />
      </serviceCertificate>
      <federatedAuthentication>
        <wsFederation passiveRedirectEnabled="true" issuer="https://myacs.accesscontrol.windows.net/v2/wsfederation" realm="https://abc.cloudapp.net/" requireHttps="true" xdt:Transform="Replace" />
        <cookieHandler requireSsl="true" xdt:Transform="Replace" />
      </federatedAuthentication>
    </service>   </microsoft.identityModel>

edited Apr 01 '13 at 09:20

astaykov

30,768
3
70
86

answered Apr 01 '13 at 04:12

bhavesh lad

1,242
1
13
23

Thanks for the answer. I have tried that solution but I was wondering if there were any other ways that others have worked around this. I should have mentioned this in the post. – Zoltan Apr 01 '13 at 05:44
This is the way. And it is not a "work-around". This is the way you solve the local-production dilemma. – astaykov Apr 01 '13 at 09:18
@astaykov What about using the local STS? I tried searching around but haven't found much info about it. – Zoltan Apr 01 '13 at 16:50
I wouldn't use local STS. Too much hassle to configure and manage ... while you can (currently) have as many ACS namespaces as you wish and everything is free within the ACS. Plus, even with local STS you still need to have these web.config transformations. You don't gain anything using local STS, unless you usually develop offline. This would be only reason I would go for local STS. – astaykov Apr 02 '13 at 06:55

score 2 · Answer 2 · answered Apr 01 '13 at 18:59

The easiest way is to use config transformations as bhavesh said, though the web.config he posted is outdated since NET 4.5.

You can have your local development configuration in web.config, your cloud development configuration in web.Debug.config and your production configruation in web.Release.config.

Here's an example web.Debug.config (only relevant parts):

<system.identityModel>
  <identityConfiguration>
    <audienceUris>
      <add xdt:Transform="RemoveAll" />
      <add value="http://myinstance.cloudapp.net/" xdt:Transform="Insert" />
    </audienceUris>
  </identityConfiguration>
</system.identityModel>

<system.identityModel.services>
  <federationConfiguration >
    <cookieHandler requireSsl="false" />
    <wsFederation passiveRedirectEnabled="true" issuer="https://mynamespace.accesscontrol.windows.net/v2/wsfederation" realm="http://myinstance.cloudapp.net/" reply="http://myinstance.cloudapp.net/" requireHttps="false" xdt:Transform="Replace"/>
  </federationConfiguration>
</system.identityModel.services>

Now all that's left to do is to configure a Relying Party for each configuration in your ACS portal.

You can actually configure a single RP for all 3 configurations, but the only way to achieve this is programmatically using the Service Management API since the portal only allows you to configure one Realm / Return URL value per Relying Party.

Note that if you decide to do this, you'll have to set the return url in your web.config (replyattribute) otherwise ACS would always overwrite it with the first configured return url (the one you see in the portal).

Azure ACS configuration for Local and Production

2 Answers2