The following forum(s) are migrating to a new home on Microsoft Q&A (Preview): Azure Active Directory!

Ask new questions on Microsoft Q&A (Preview).
Interact with existing posts until December 13, 2019, after which content will be closed to all new and existing posts.

Learn More

 none
Is Azure ACS actually a fit for multi-tenant cloud based applications? RRS feed

  • Question

  • I have been digging all day and have only come up with scraps and hints on how to do this with ACS. I have seen others post similar questions as this in the past, but the answers are out of date, incomplete or non-existent.

    Here is the scenario (for all your MSFT ACS PMs out there):

    1. Cloud-based service provider ('the service') wants to enable 2 key scenarios for its customers
    2. Each customer is a "tenant"
    3. Tenants should be able to access the service via
    4. - companyname.service.com  (Host name)
    5. - service.companyname.com  (CNAME / Alias)
    6. Sign in / up with
    7. Facebook
    8. Google
    9. LiveId / etc.
    10. Custom "service" credentials
    11. Other -  the service should be able to use external / other identity providers per tenant as needed.  Ex: a customers AD, etc.

    From what I can tell, ACS has some serious limitations for the scenario above:

    1. The reply-parties are "fixed" and limited to 100.  So this obviously will not scale for a self-provisioning multi-tenant application.  As 1.) our goal is to have way more than 100 customers and 2.) we don't want to have to manage this manually via the ACS UI (although I guess we could automate it)
    2. ACS provides no identity services it's self, which is by design... so to do #10 above, we have to write our own STS
    3. ACS reply-parties do not support wild cards.  So #4 above requires me to write code that stuffs some info in the wctx (context) parameter and set/parse it as needed.

    4. Requirement #5 above seems impossible and the only way to do this is to basically add another layer entirely? And I am fuzzy on this but   My Service Web -> Custom RP layer (via ACS) -> -> My STS -> ACS again -> External provider.     So people will actually always log into app.service.com via ACS, but then I will have to build my own claim / authentication hand off (perhaps using ACS again) to then auth with the corresponding company URL.

    5. As far as Req. #11 above, I have no idea how to make this work in an ACS 2.0 world and would appreciate any hints.

    Thank you very much for your time and help with this.

    Tuesday, April 17, 2012 3:53 AM

All replies

  • Hi,

    Thank you for questions.

    About point 1 and 4, i suggest you post your idea to Windows Azure feature request site:

    http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting

    About point 2, i think ACS has service identities in ACS Management Portal, try to visit ACS site and click "Service Settings - Service identities", you can create simple password, symmetric key or certificates as the identities in ACS portal.

    About point 3, as far as i know, ACS doesn't support wild cards because safety issue, suppose your ACS Relying-Party application has the Realm and it can be edit by other application, your ACS token may sent to incorrect client and cause security issue.

    About point 5, you can create your custom identity providers in ACS, such Federation Authentication, ADFS, WIF, etc.

    Please refer to following links:

    http://msdn.microsoft.com/en-us/library/windowsazure/hh127796.aspx

    http://technet.microsoft.com/en-us/edge/Video/ff972550

    http://code.msdn.microsoft.com/windowsazure/ASPNET-Security-SWT-With-a0183e7a

    Hope these helps.


    Please mark the replies as answers if they help or unmark if not. If you have any feedback about my replies, please contact msdnmg@microsoft.com Microsoft One Code Framework

    Tuesday, April 17, 2012 10:01 AM
  • Hi,

    You might want to look at the Fabrikam Shipping application. This is an application designed for multi tenancy with ACS (allowing the customer to configure his own identity provider, to provide the claim mappings, ...). I think it will serve as a great example for what you're trying to do.

    http://www.fabrikamshipping.com

    Sandrino


    Sandrino Di Mattia | Twitter: http://twitter.com/sandrinodm | Azure Blog: http://fabriccontroller.net/blog | Blog: http://sandrinodimattia.net/blog

    Tuesday, April 17, 2012 10:17 AM
  • Fabrikam Shipping is indeed an interesting sample (FWIW, the demo provisioning seems to be down at the moment).

    However, while it provides the ability to federate with a customers STS it seems like two of my requirements still aren't met: 1.) Let the customer have their own URL  (service.companyname.com)  (where service is a CNAME to my product) and 2.) it requires the use of the management API to update my ACS system and as such I will be hitting the 100 limit.

    Tuesday, April 17, 2012 5:36 PM
  • This stuff continues to seem very confusing.  Even after reading Vittorio's book.

    What's unclear to is what does the Azure team recommend to do what I want to do?  Should I be using ACS?

    Clear guidance would be helpful.  The Fabrikam solution doesn't seem to meet the custom domain requirements.

    Let's say my app's name is "Amazing".  They will want to be able to have their users access MY app via:

    amazing.companyname.com

    Alternatively, I should also be able to offer:

    companyname.amazing.com

    It would seem to me that CNAMEs can be used to map requests to amazing.companyname.com to something like app.amazing.com (some known login URL).  Do I then just need to figure out how to issue a cookie for amazing.companyname.com and then redirect the user?  Is there a safe and secure way to do this?  Is these even the right path?   So the pattern would be:

    1. User goes to amazing.companyname.com
    2. CNAME points them to app.amazing.com
    3. Users is not authenticated
    4. User is redirected to amazing.accesscontrol.windows.net
    5. User selects a provider (let's say Windows LiveId)
    6. User is redirected to login.liveid.com and authenticates
    7. User is redirected back to app.amazing.com/login
    8. I access the trusted identity and issue my own cookie / claims
    9. I redirect user back to amazing.companyname.com

    Is this even the right direction to be looking at?

    #7 seems to be a big problem because the REALM and the RETURNURL have to be in the same domain

    #8 seems to be a problem because of cross-domain cookie limitations

    Should I instead be looking to dynamically change the RETURNURL and somehow override/hack WIF to allow this?

    I think once I figure out this high-level design using WIF and ACS, I will be able to figure out most of what I need to do.

    Update: After thinking this even more, is my real problem ACS?  Right now as I understand this, I "trusts" ACS and ACS "trusts" providers like Live and FB.  Am I better off just using WIF directly?  That way amazing.com directly trusts FB/Live/Etc.  Is this the path I should be going?

    Thanks again.

    • Edited by ProVega Tuesday, April 17, 2012 8:46 PM Should I even be using ACS?
    Tuesday, April 17, 2012 7:55 PM
  • Where did you get the data that ACS limits you to 100 relying parties?
    Thursday, April 19, 2012 6:23 PM
  • As of this release, ACS does not impose limits on the number of identity providers, relying party applications, rule groups, rules, service identities, claim types, delegation records, issuers, keys, and addresses that can be created for a given ACS namespace. So even if you will have large number of sub domains, you can just add them in the namespace configuration . This is not elegant but shall just work.

    -Emma


    • Edited by Emma Em Tuesday, May 29, 2012 2:59 AM
    Tuesday, May 29, 2012 2:59 AM