Building an Azure ACS OAUTH AS–emulating the AS of Ping Federate–part #1 getting to consent


The goal is to use the OAUTH2Playground website of Ping Identity’s Ping Federate server (evaluation edition) to talk no longer to the OAUTH2 AS feature that are built in but to an AS we build ourselves — in an ASP.NET website – supported by the Azure ACS. We know then we have largely emulated Ping Federate’s own AS behaviour using its own test site – and we have done this at a good enough level for getting a first OAUTH project off the ground (by learning from the best).

Using Visual Studio 2012 create a web forms project, internet type. Register Google as an IDP, leveraging the built-in OAUTH provider that comes with ASP.NET Now add a class with our OAUTH provider; and register it alongside google. This allows us to send OAUTH2 messages to an Azure ACS namespace’s token issuing endpoint. It also allows the provider to leverage other “support”. interfaces that allow our AS to delegate to ACS much of the work of implementing an AS service.

The account linking model of the default website thus build allows to show that we have logged on to a locally-managed account (called rapstaff) having used an Google-asserted identity. IN other words, we have a user session on our AS, induced by an inbound ws-fedp SAML1.1 assertion received from ACS – since this is normally how we talk to Google’s IDP. We can now press the CIS button, which emulates an OAUTH client (called Fabrikam2) invoking the AS and its token issuing endpoint. Obviously, we will make the URLs look and respond like the equivalents in PingFederate’s implementation.

image

What we have just done with button clicks is the equivalent of use this screen from the oauth2playground:

image

image

Now typically, when we want a URL to specify which IDP to use, we invoke our particular pattern (which sends off an ws-fedp request to ACS, requesting further gatewaying with google’s openid endpoints).

https://localhost:44302/v2/wsfederation/Default.aspx/google

Now we can accomplish some but not all of what the Ping URL does from the start, by having a page class that redirects

image

If no SAML session exists, this lands on a IDP chooser page. Upon the return of the assertion from Google, say, the CIS  button is logically pressed … continuing onto the AS phase of the flow (invoked also by the CIS button). If a local SP-side session exists, the chooser and authentication process is omitted – passing straight to Go!

image

Once invoked, we see the (CIS) provider pass control to our implementation of the  authorization_code handling component of our AS (which delegates much of its implementation to Azure ACS). At the point, non of the parameters show are configurable from the ping emulating URL.

So, now to get rid of button pressing and make the flow be driven from the formal interface of an OAUTH AS endpoint. We implement a form handler

image

 

With an existing user session (for a local user “rapstaff” previously linked from google websso), a user is directed to the consent page – that will authorize creation of an “authorization_code” persistent grant.

image

If there is no user session, we get a ping federate like experience. The OAUTH AS site invokes an “IDP Connection”, as selected by the user:

image

Next, we see the storage of an authorization grant – using the (OAUTH-guarded) ACS service – which also mints the authorization code to be issues to user devices.

image

image

from the relying party NAME, the token issuing service will require that the party seeking to swap the code for a token must cite the realm of the named party – acting as a scope.

Advertisements

About home_pw@msn.com

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