The Azure Access Control service is unavailable.

Lovely error right?  You can spend a lifetime trying to figure out why you can't get rid of this error.  But that's what community is for!  After writing my own OAuth apps to hit the SharePoint AppsSTS (appssts.svc), I finally know why this error occurs!

Turns out that O365 SharePoint Farms have a special Service Application installed.  This service application is not available to us mere mortals with Beta version of SP2013 running on-premise.  The service application is called "Azure Access Control Service Application".  It has a corresponding Proxy that goes with it.  When your SharePoint App code executes, it makes a call to this ACS proxy.  If it doesn't find the existance of one of them in your Farm, it fails with a null reference, and then you get the "The Azure Access Control service is unavailable." error. 

What does the proxy do?  It actually will grab the Azure EndPoint for OAuth2 and do the delegation calls.  You can see this xml document here:

https://accounts.accesscontrol.windows.net/metadata/json/1

Now you may be thinking…can I trick it?  Well, even if you could (which you can't), notice the "Location" fields in the SharePoint endpoint below.  Doing the same endpoint call in SharePoint, you will see that those "location" fields are not populated so you couldn't do it anyway!

http://intranet.contoso.com/_layouts/15/metadata/json/1

Nothing you can do about it with an onpremise installation of SharePoint 2013.  Whatever app you built, something in it is wanting to be deployed to O365.  This tells you that Microsoft is driving you to it by leaving out real OAuth endpoints in SP2013 in Beta.  You can find several differnt ways to get an access token in the beta but none of them really support the notion of a clientid and secret when working with on-premise.  Just FYI, one way (that is as close to OAuth as you can get) is particuarlly bad as it doesn't have any auth on it and I can get auth tokens all day long!!!

All that being said,  there are hints of the ablity to do this in RTM.  You can find several layouts pages (AppRegNew.aspx) dedicated to creating applications that live on-premise and use real OAuth calls (clientid and secret).  However, sad to say, nothing really works at the moment in the beta (believe me…I have tried). The fact that the code is even exposed about the ACS Service Application is because there is a generic interface that can be replaced in later code to make calls to other services, however, it looks like they just didn't get around to putting all the plumbing in yet.

So, don't fret about the above error, you can't do anything about it with on-premise apps. 
Chris

Working with SharePoint 2013 Distributed Cache Service (DCS)

As part of the latest course, i wanted to show how to get in and see what was in the cache of SharePoint.  I also wanted to add my own items via web parts.  Since the DCS is really AppFabric, and I have worked with it before, I didn't see it being a tough set of labs to put together.  However, I found that all the SPDistributedCache classes are marked as "internal".   This leave the regular .NET API to make calls into the service layers.   I found a great little set of code written by Stephane Eyskens (@stephaneeyskens) here:

http://www.silver-it.com/node/111

That is one of the better pieces of sleuthing I have seen in a while!

Chris

OAuth 2.0 – How long will it survive?

Yeah, lots of people are using OAuth.  Its evolution from WRAP->OAuth 1.0 has in my opinion been mostly good.  However, there are always the details of how something is built that makes you realize, not everything is what it seems to be:

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

After reading the article…go to the last part…I tweeted that all not too long ago.  I did the same for REST in SharePoint 2010.

You have to wonder.  Who is the "Enterprise" in this case?  Hint…My guess is the name starts with an "M" and ends in "T"

Chris