ACS-based OUTH2 AS augmenting Google IDP (via ACS)


Let’s see how far we have got in emulating Ping Federate’s OAUTH engine (for the authorization grant).

We start out as will any vendor/client, making a request for the grant type:

image

https://localhost:44302/as/authorization.oauth2.aspx?client_id=FabrikamClient2&response_type=code&client_secret=FabrikamSecret
&redirect_uri=https://localhost:44302/as/authorization.oauth2.aspx&scope=&
state=123&idp=Google&pfidpadapterid=

At 1 we see our AS consuming  our ACS namespace’s store of “service identifiers,” checking up on the redirect URI given on the query (query string, not FORM POST for now).

Since there is no user session at the AS, the Session creation mechanism kicks in and also shows a list of “IDP Connections” – including Azure AD. Remember, Selecting Google here really means send a request to ACS…which will chain/gateway the request to Google’s WebSSO Cloud…which will chain the request Ping One, which will… Anyways, at the end of the day ACS issues us a SAML assertion that we verify, pulling the metadata on the fly.

our AS is in account linking mode for this IDP connection, and thus we get a challenge – to logon as the local IDP that governs linking.

image

image

The net result of this one time linking, for an inbound Google identity, is some UI (remember this is a prototype…!)

image

Using the Return option, we resume the OAUTH AS processing, that consumes local (rapstaff) account whose profile is driven by the SAML assertions relayed by ACS from Google. We get the consent screen – that which guards release of the authorization code and storage of the persistent grant in ACS.

image

This gets us back to our simulated vendor site, ready for the vendor to call the access token (STS) service to convert the “code” into an longer-lived access token.

image

Ok, we see lots of the pieces coming together! When we now use the postback of the token minting form to actually talk to the ACS access token minting service, we get as result:

image

I suppose the thing to do next is the refresh token, swap from symmetric-signed SWT to RSA-signed JWT and then verify the signature as a “client”, pulling the public key from ACS, somehow.

But, even now, if put this site behind the Ping Identity Oauth2Playground UI for developers of client sites, I suspect it will work reasonably well as is.

To expose our old AS available by button pressing as a protocol engine for real clients, all we really added was a handler for the authorization and token endpoints:

image

authorization endpoint

image

token endpoint

The trace on the wire tells the whole story:

image

if we swap the token for JWT and assign a signing key

image

we get now a JWT

image

Since the DateTimes are not in a friendly dotNet syntax, one converts (from Microsoft sample code for SWT notbefore and expiry times)

image

End.

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.