RESO/NAR’s client proxy for odata & oauth–application (vs user) access


In the world of real estate, the big dog is called NAR – the National Association of Realtors. At the national level, it has lots of money to spend on its favorite vendors, leads standards, and does politics. It’s a big-money trade association! …with folks doing what they are supposed to be doing!

On one topic, there is technical strangeness afoot. It concerns the leveraging of cloud-scale security infrastructure to indirectly govern the connectivity of thousands of clients and servers in the states and localities where actual real estate transactions are generated; AND the activities of newer “value-adding opportunity” of “beyond client/server” vendor intermediaries. One wants, as a governance body, to decide (without seeming to violate anti-trust) WHO gets to “add value” (and under what governance rules).

One well known intermediary, not seen to be dis-intermediating NAR’s Realtor brand, is Trulia – which has essentially comes up with a new model (of doing old things). Good! there is a lot of money in advertising to folk visiting realtor listings (not that the realtor or the broker will see much of the cash!).

On technical security topics, NAR is not strong and seems to pick lower skill security vendors for advice. For example, one might want to build a modernized webapp for searching listing that now talks to an odata API (where the webapp presents the required security tokens to the api provider, using the oauth scheme).

If one understood openid connect scheme properly one would KNOW how properly and professionally to use audiences, scopes and permissions to allow only certain app deployments (and only those-authorized web apps, at those certain sites) to allow public access. And one would not need to hide a username/password in the code of the webapp, or other amateurish low-assurance practices. Note, one might store applicationid/secrets (in what is a trusted app); but not a USER-credential set. Note the subtle difference (one allows to app to behave legally AS-IF the user; the other to behave merely “with authority”).

If one does NOT really understand the way the full security model works when enacting governance regimes for hugely distributed systems (even though the requirements are actually well understood in web app land for such as the public’s searching of listings), one does such things – like invent special “high security” web agents proxies with “special powers” (that store a special “username/password”, so as to get some default “USER” credential necessary to access then the guarded webapi).

This is amateurish way of doing things (in the security world).

How would a professional security cloud vendor approach the problem?

take a look at this sample code (NAR/RESO):

https://github.com/AzureADSamples/WebApp-WebAPI-OAuth2-AppIdentity-DotNet

Note how user identities and app identities are handled, when architected properly in multi-tier oauth environments. Compare it with other projects in the sample set – which showcase different uses of the security protocols, for different systemic objectives, where user controls and application controls have different objectives.

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 RETS. Bookmark the permalink.