Back here we reported on how we used Microsoft Azure’s ACS OAUTH2 feature set. We were able to write a web client and web service that generated and consumed OAUTH tokens. I support of these entities, an Azure ACS tenant did “middleware work” …implementing the so called “authorization_code grant.”
The authorization code grant assumes a world of devices supporting an internet browser and “apps” – downloaded to augment the platform. The grant type is specifically involved in the task of “provisioning” apps – ensuring that the downloaded app also has the necessary security and personalization configuration from information supplied by the user via a browser-experience– that induces the initial download of the (well-provisioned) app. Downloading may give the user a new app on the platform and the code, to be entered when the app first starts. With that code, the app is able to complete its provisioning and access user information on remote web sites.
The user visits some vendor’s website with a browser – to which the user with an account with the vendor wants “to connect-up” said account with their IDP-managed membership record. This simply avoids account proliferation, and eases lifecycle management of accounts (and first-time provisioning of those non-browser apps discussed above).
The (app) vendor’s website enrolling and thereafter “supporting” website should also become entitled post connect-up to make web service calls to the IDP .. to pull or to update the remote membership record. To authorize this ongoing server-server connection hookup, OAUTH2 gets involved – delivering a consent-UI flow using web pages and browser and asking: do you want your IDP membership record to flow to vendor X and should the IDP assign some of your read/write powers on that remote record to the vendor? So, both inter-site connections and authorization_codes are delivered so that sites can support each other when delivering data to apps – that provision themselves given the code.
If we recall, we created in our Azure ACS tenant a so-called “service principal” record for the vendor – known more generally as “client management”. That is… we configured a per-vendor clientid/password pair. We also created an SP in our ACS tenant – arming and deploying an STS that will mint “access” tokens – in some or other blob format. Of course, it will be the authorized vendor working to add some kind of value to the IDP’s membership record who uses this STS to convert the “authorization_codeword” minted by the consent process into the first signed token which, upon its return by the STS, the vendor will thereafter attach to its server-initiated web calls to read/write the membership record.
We also recall adding a consent.aspx page to the membership management component of our IDP. This delivered the one-time “do you want to connect-up…” GUI experience to the user…as he/she goes about connecting-up the vendor site with the IDP membership site’s oauth-guarded data service. And we recall seeing how upon gauging user consent the consent.aspx page would itself make a web call to ACS – to create a “delegation record” (recording the user’s connecting-up assent). The result from ACS was the one-time “authorization_code”, minted specifically for this newly mint delegation record. Passed back pass back to the vendor site via various browser-based redirects. the vendor’ site flow in charge of the user’s “connect-up experience” can swap it for for a real token by calling the SP/STS token-minting endpoint.
Let’s try and make Ping Federate server do the same thing. Then we can compare our integration experiences.
First install the Ping Federate server and its OAUTH playground, per the instructions. Once you have installed the license, you can change the console uid/password. Now launch the OAUTH playground website also hosted on the same jboss host as that hosting Ping Federate itself and use the settings button on the page (1) to auto-configure your shiny new Ping Federate Oauth configuration “for a vendor” :
We see the result of the site invoking web services for remote OAUTH client configuration/management, using the admin/2Federate credentials required for said calls. This populates 6 records, as shown. We are interested in just the “ac-client” vendor – since it showcases the equivalent of the authorization_code grant work from our Azure ACS work.
Back at the Ping Federate console, we see what that playground site just did, having got to this screen from the (new to Ping Federate) console
ok. So we have accomplished the equivalent of creating a service principal in an Azure ACS tenant for a new vendor, known as “ac_Client”. Whereas in the Azure ACS world we used the ACS management API to register the uid/password/redirect, here the site’s configuration pages used the Ping Identity API to Ping Federate instead. (As with ACS, one can alternatively the management console to manually fill out a form communicating the same information fields).
Note that configuring access controls on the API port (for remote client management) requires one to set up a validator (a particular repository of vendorid/password pairs):
noting the difference of the above multi-screen from the older concept of “application authentication” to other web service ports offered by Ping Federate!
This leads us to understand the core configuration screen for the new OAUTH2 authorization service component of Ping Federate:
At 1, we see the management concept of “scopes” being configured – defining a description for the unnamed/default scope and defining additional “named scopes” relevant to the IDP-managed resources. Remember, these are like the custom-rights to be defined in ADRM– saying perhaps that you can or cannot print of forward… this kind of marked paragraph.
At 2, we see how to configure a couple of behavior parameters of the Ping Federate authorization-code element of service: how long a code will be good for (i.e. before when the vendor needs to cite it, to get back the first token from the associated STS), and how the code itself is to be generated (to address code spoofing/guessing).
At 3 we seem some advanced features we can come back to… MUCH later!
Let’s head back to the playground website noting that we need to configure just a little more per-flow setup in order to prepare to see something happen. We are interested in invoking the authorization code demo! To make the simulation of the vendor work, go back to the main screen, and choose the authorization code link (and read the tutorials too, if you wish).
At 1, above, we see what we recall from our our own OAuthClient provider class work (that we plugged into the ASP.NET OAUTH framework for vendor websites). We cealy see the vendorid and the indication of “code” – inducing the Ping Federate-hosted OAUTH2 authorization service to invoke the “authorization_code” flow (vs alternatives).
At 2, we note first that these 2 parameters are optional in Ping Federate world (whereas they were not in the Azure ACS world). ACS required the caller to cite the URI address to the authorization server’s consent page, requiring that it align with the recorded address (in the service principal record).
At 3, we see the ability to request that a particular list of (pre-registered) custom named-scopes be associate with the authorization code “grant” (as finally visible in any token minted by the STS)
And at 4 we see the anti-CSRF support (that caused us so much pain, when writing the OAUTH2CLient class, initially). Fortunately, what we did back then to make an OAUTH2 client provider will server us here, too!
at 5, we see some PingFederate “value-add” – in which should no user session exist at the Authorization server during consent page flow, a websso request can be sent off to the desired IDP to induce an authentication session at the authorization server itself (acting as a pseudo-SP). And as is typical in PF land, one gets to indicate particular querystring parameters on the URI that will induce Ping Federate to initiated a websso flow with at IDP: identity the IDP connection (of this pseudo-SP) and the IDP adaptor that the IDP should use.
Note how PingFederate’s nice, modern capability to use authenticationContext switching feature of the SAML2 protocol – as a means of choosing IDP adaptors – is missing. Hmm.
Anyways, since no such values are supplied by this particular playground page, the Default IDP connection is applied – as we see when we hit the go button! A fiddler trace show the request being sent and a login challenge page being rendered. Note there is no sign of the usual ping URL initiating websso on the IDP.
Once the user authenticates to the IDP via websso, we see the expected post-autentication challenge consent screen being rendered. Once the user consents to the continuance), the authorization process return the “code”:
Follow up token minting can then be completed by the vendor site. In this case, the STS correctly refuses to give one, since we supplied the code too late, making it an “expired” code):
With this we can play some more tomorrow, perhaps seeing if we can replace the playground site. Our goal should be to to apply own OAUTH2Client provider for ASP.NET instead, from here.