How to auth REST API for my company's DB at multiple clients: ACS? VPN? Something else? RRS feed

  • Question

  • Apologies for yet another architecture question; hopefully this is at least an interesting one.  My company currently has a DB onsite at each of our clients; the frontend for this DB is mostly Sharepoint webparts.  We also run two Windows services: one is a WCF interface to that DB, which is used to integrate with other applications, and one service that uses the WCF service to check a queue table in the DB and perform various actions (like sending email notifications, triggering updates, etc).  Permissions are managed on a Sharepoint site level; if a user has access to, say, an "HR" sharepoint site, then they can also receive email notifications for "HR" topics.

    Now we'd like to allow our clients' users to access this DB from mobile.  I've been building a new WCF REST service for this, and during dev I've been using the service bus to test this service: that way, the service itself can run on our own server, but be accessible outside of the office. But because we want this service to perform well, and because our service will soon include image/video uploads, we believe we should put the REST service, the database, and the image storage in the cloud (using Azure).

    So here are the problems:

    - Authentication: The process of installing ADFS and linking it to ACS seems awfully time consuming and confusing.  Maybe Azure Active Directory will address this, but we don't know yet.  Furthermore, we'll still need to check a user's permission to access various Sharepoint sites, and we can't count on each client's Sharepoint install being accessible outside of their private network.

    - Integration with onsite services: Some of our integration with other onsite databases is at the DB level (e.g. a stored procedure takes data from one database, compares it to data in our own database, and then inserts new records). This isn't possible with the current limits of SQL Azure.  We've discussed keeping some of our database onsite, importing data from other onsite sources into that database, and then using SQL Azure syncing to replicate that data to the cloud instance of our DB.  Unfortunately, SQL Azure replication is really more like a periodic backup: it isn't "live", you just set how often you want it to run.

    - Provisioning: My current plan is to setup a separate instance (in its own web role) of the REST API for each client.  I'll also setup a central service that the mobile app will connect to on first run in order to find the API endpoint for a given user's company (based on their domain).

    To solve a variety of these issues, here are what I see as my options:

    - I could setup each client's REST API endpoint to be in a virtual network connected to that client's private network — then (I assume!) I could authenticate against that client's Active Directory, and access their Sharepoint install even if it's not publicly accessible.  Are there downsides to this?

    - I could also setup ACS authentication against AD — hopefully new Azure AD functionality will make this less of a headache than it currently is with ADFS 2.0.  Then I'd also setup an onsite service that'd be used to talk to Sharepoint and other onsite integration points whenever necessary.  This would need to be accessible by the public REST service, so maybe it would have to use the service bus?

    Thursday, June 28, 2012 6:18 PM


  • Hi,

    You can try to use the new virtual network feature. It allows you to setup private network that combines Windows Azure machines and your local network. Using virtual network, you no longer need Service Bus or ACS. You can connect to on-premises network directly, and authenticate using your local AD.

    Hope this 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

    • Marked as answer by Arwind - MSFT Wednesday, July 4, 2012 9:46 AM
    Monday, July 2, 2012 3:33 AM