The 1.5 day event was well attended, though a little stage managed. A lot of folk seemed to have nothing to say while old timers performed for the camera. Now under “professional management” this seemed – at least for THIS stage of the relaunch of the initiative – to be the intent. It was there to sell the future.
On one topic there is thunder afoot – that aligns with the adjustments being made in organized realty to accommodate the app revolution. In order that apps can receive official realty data, the standard is migrating to the odata platform – and away from the RETS platform. The former is assumed to be the kind of design that suits apps – and the API economy that goes with Apps. I cannot say I disagree.
For our part, we spent most of the time getting used to the latest webapi 2.2 odata platform, and the ancillary infrastructure for handling security in the OWIN pipeline. The scenario, whose “public domain” code is here, goes like this:
A Command line client, using the client credentials grant (a kind of usernametoken) talks to an OAuth2-complying authorization server implemented in the OWIN pipeline, using common Microsoft software components. The net result is the minting of an access token – that is a machine-key protected, serialized ClaimsIdentity value. Note that is is NOT a JWT! The tool then does the classical thing of making an http call to an API endpoint, putting the access token into the request’s header. The cliebnt thus talks to a resource server, itself implemented as a WebAPI 2.2 (beta) odata project whose sample source code showed us how to inject an interceptor into the pipeline that looks for the header; and later performs validation of the token; before setting the identity context for the rest of the pipeline that might return data. The validation procedure was programmed, using sample source code, to consume decrypt and unserialize what was infact a claimsidentity value.
A second client program uses WPF – from the “shipping client” theme. We modified it to consume two APIs: the shipping service (delivering shipping data, upon validating an ACS-issued JWT access/bearer token); and a new players/teams odata service. The former is a restful API; and the latter is both a result and odata API. In both APIs, the WPF application uses the ADAL 1.0 era library to pop a browser window, challenge the user, and obtain via ACS a (JWT) token, with name claims sourced back to 1 of three IDPs – including an office365 IDP connected to our realty rapmlsqa.com IDP. The JWT is posted back to the WPF window, where it is validated (before being used to talk to APIs).
Validation consists of obtaining ACS metadata (the signing/verifying keys) and then checking signatures and certificates. Thereafter, both APIs are consumed – by sending requests bearing the token. Firstly, the shipping API is used with the client this time presenting a JSON token – rather than a serialized claimsidentity value. The API token validation on the server was then enhanced – mostly by borrowing code from the client side validation (as just described). It was enhanced to verify now two token types issued either in response to the client-credentials-grant-seeking client (see earlier discdussion ) or else that sent by the WPF client, as obtained from ACS.
Next, an odata proxy client class was created and added to the WPF project, per a blog post’s instructions. This allows the app to consume the odata API, easily. TO this process an event handler was set on the use of the new proxy class – that will auto populate the resulting http request build by the proxy with a header bearing the authorization token, noted above and obtained already (using ADAL). Then, the odata API, based on an OWIN pipeline setup with oauth bearer interceptors, verifies the inbound JWT, much as did the WPF client do itself, earlier.
The conference itself wrapped up having shown the validity of using odata and show how trivially easy it is to program a basic server, service, and (as I indicated above using my meager and some what out of date programming skills) a client and security interceptor layer for both custom and JWT tokens – for use at restful and odata-restful APIs.
Because this all creates a national-scale data marketplace that is FAR more flexible that that formed by the older regionally-focused RETS standard, this all clearly creates some political challenges. As the technical infrastructure changes to allow the scale up, this may induce significant ECONOMIC changes – that may affect a LOT of livelihoods.