Adding Multiple Scope support to an Azure ACS based OAUTH authorization server




The pictures above show an ACS namespace and its relying parties for a particular “rule group”, the claim issuer attached to the rule group (and thus all the relying parties associated with it), and the list of associated identity providers similarly (who are also issuers). One notes that the issuer for the rule group is not an IDP (though it is an “issuer”). This distinction is critical.

The first relying party, whose name is in the rule group name, can be considered to be the default scope. The relationship with the issuer is established by our code, at application startup. When one adds other relying parties who associate with this same rule group (and the issuer, therefore), one can consider these to be additional scopes – to be cited possible in messages to/from our AS’s OAUTH endpoint –  and to which scope (more vitally) authorization codes can be minted.

So lets see if now we can make ACS issue a JWT bearing this limited scope. We can! But note that first we have to extend the PingFederate token issuing UI to allow us to specify the scope (since it treated as the audience, in the Azure ACS model):




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.