Building an ACS-based OAUTH2 Authorization Server instead of using Ping Federate OAUTH AS

This is a difficult post to write – if only because sales folks can be so ham-fisted at their negotiation art at times – not realizing  THAT – perhaps because of poor support from their marketing department – competition changes with time. In particular, for Ping Identity, the Azure ACS – at its ZERO DOLLAR price point – makes it cost effective to program against that service to create an OAUTH2 authorization server yourself. Furthermore, with the general availability of Azure AD and its complementing nature with ACS namespaces (plural), yet another feature of Ping Federate has been commoditized: that of exposing conforming SAML2 IDP endpoint (supported by simpler WIF/ws-fedp endpoints in your own software set). The focus of Azure AD on creating one own app-communities (those authorized to plugin to one’s own APIs) and enforcing these “communities of interest” should give even Ping Identities 7.0 series features of Ping Federate a run for their money (Im guessing)!

Now, I can see Ping sales engineers arguing that the Azure AD/ACS commodity support is incomplete. But, having used Ping software for years as a customer with a perpetual license, I can also attest (and I known the firm concurs with me, in semi-private) that no one in the world uses the high-end features of SAML2. We are in the COMMODITY phase of the market (where lots of folks use the bottom 80% of a standard’s features, as designed 10 years ago…and when interworking is largely error and hassle-free). This is clearly the case for SAML2 asserting parties supported by now by a directory graph endpoints – with which to get additional claims about the user, including claims from the VAR chain that go beyond the scope of what information Azure AD itself manages.

Now we have all been actually using OAUTH2 in production for a while now – simply when using the management service API of ACS itself to provision IDP and RP records. We have libraries for the client that exchange a resource-owners credential set using the resource-owner grant authorization mode of the standard. That is, a username/password is exchanged for an SWT formatted access token – that is used in API call request header thereafter to drive the ODATA data interface exposed by ACS with which to manage the rest of the management entities (including IDPs, RPs, claim transformation rules and even client credential set).


This is how, for example, normally one populates clientids/passwords. It is also how one creates “delegation records” – a management entity which enables one to store the persistent grants – such as the “authorization_code” grant type. Apparently Windows Azure Marketplace and Sharepoint Online are based on these capabilities – so Im in good company by relying on it!

Now I feel sorry for pPing Identity in losing a sale – in that their education of ME in the last month was just superb; with their OAUTH2Playground site doing a really good job of laying out the case for what OAUTH does, generally. It becomes really quite simple. Furthermore, on a sales eval license the firm exposed me to all the features of their engine (PingFederate). Learning to configure at “certification grade” all the advanced modes was itself educational – forcing one to realize how an complete authorization server really works – when supporting delivering the “decision” service BEHIND the protocol endpoints. What the server would allow and not allow (by design) in configuration terms was educational in and of itself – since the limits imposed reinforced certain architectural patterns. It would not let me “abuse” OAUTH  – thus ensuring Ill be reasonably compliant with others when interworking.

But, its not to be. We are back to using the authorizationserver support library from ACS, which allows us in ASP.NET to build our own authorization server logic. It has taken be about 8 hours to remember what I did last time (in pure prototyping mode), adding a consent handler to an ASP.NET web forms project already armed with the ability to do ws-fedp and OAUTH2 interactions with IDPs doing user authentication. The authorizationserver support library from Microsoft provides the guts for buildings ones own AS – enabling one to handoff to ACS, via the OAUTH2-powered API the service offered to your/my “3rd party Authorization servers”, to do the hard work an security critical elements of doing “persistent grant management” – and enforcing the so-called authorization_code rules. While I already miss the “polished” services of PingFederate that added SO MUCH VALUE over and above this raw capability, I got something working fast with Microsoft services and software. So well done Microsoft.

And, for OUR project, that’s all I need. And its all I can afford.

Now that Microsoft have distributed the official JWT securitytoken handler, an access_token endpoint handler be able to mint signed JWTs, too.

Finally, we see that the WSDL for the ACS ws-trust version 1.3 (but no 1.5) interface enables us to issue and renew tokens, given a usernametoken – and we have seen how this can issue us JWTs. Now that we understand how a thick client using WCF should be managing its own client-side token cache so a JWT so minted by one ws-trust interaction can be used across multiple client channel endpoints  and contracts/interfaces (while still allowing the underlying WCF token provider to invoke the issue/renew token trust delivered by ACS as required), we even understand well what Ping was offering in the ws-trust area – when trying to support a WCF installation. BOth Microsoft and Ping are lacking documentation here, note.

We also got to play with the Ping Federate endpoint that implemented the “SAML authorization grant” service – swapping  a SAML token for an access token. Unlike the integration of SAML via websso with the user-centric grant mechanism, with the full SAML authorization grant mechanism we could map ANY claim from SAML blob into the access token. I suppose this might help us in the ACS-mediated websso case, where we want to swap the SAML blog with claims mapped from Azure AD into a JWT that the directory API will accept, even if signed by third parties.

So thanks Ping Identity for a superb evaluation and a first class and superb training experience. I’m sorry I cannot even repay that – except by recommending others (customers in cash-richer markets) and contrasting what a “value-adding” authorization server really does over the barebones infrastructure of Microsoft Azure ACS AND NOW AZURE AD offers – to the likes of us living with government defense-subsidies …on cash-poor main street.



Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in oauth. Bookmark the permalink.