looking at chained openid connect, given oauth2.0 authorization code grant

I now understand enough about OAUTH2.0 in its modern incarnations to have a look at openid connect. What does the latter do?

The answer is… I don’t know (but I have every reason to not trust the folks involved, if only because of how the phone companies lied and spied on folks – setting the precedent for how its likely OpenID connect will work, socially, too.)

When we look at http://openid.net/specs/openid-connect-basic-1_0.html, let imagine we are now working with the 25+ year-old architecture of the secure x.500 directory. Assume the old concept of the universal directory and openid connect are one and the same – and the core features are common. What MIGHT they be? Assume that technology changes (as bits, bytes and blobs shift between binary, XML, text and back to binary…); and that such changes are essentially irrelevant.

Well! We know from the write-up that an SP might receive a web visit from some consumer with a purported name claim (e.g. peter@rapmlsqa.info) – perhaps in the Google namespace rather than my namespace, that of the Windows Identity land or Yahoo land. The visit is to the likes of one’s Office365 share point site – rather than a simple website.

Of course, let’s say we are registered with the Windows world (being marginally less evil than Google). Assume the politics evolves (quite quickly) such that one MUST use a TTP to mediate ones web presence with consumers (rather than use the web concept from TBL) Thus we can perform the OAUTH2.0 authorization_code handshake – either for consumer consent, or for tenant admins to consent to the presence and value-add of data-consuming APPs (from third party vendors).

Through our Azure ACS instance, we have access to Google Microsoft and Yahoo IDPs of course – who we assume (under USG “prompting”) are decided to allow reciprocal access to each others’ directory access points, for any tenants of each _other’s_ cloud. To authorize the other cloud’s SP to access the IDP’s directory graph API endpoints of course requires an OAUTH-2.0 dance – in which the authorization server serving the SP (this being a Windows world AS, when helping out ACS supporting a Windows SP website and web services) issues a signed JWT – that is “viable” in a cross-vendor world because the certificate/signature on the JWT can be evaluated at the directory graph endpoint(s) of the two other IDPs. After all, its just, a signed blob, supported by a cert – giving it mobility.

So is this what OpenID Connect REALLY is – that mere OAUTH 2.0 is not?

Ill guess it’s the fact that certain OAUTH AS/STS issuing the JWTs as “identity tokens” (subtly distinct from the authorization token within the same access token response) carry political-privileges such that the SP web app “governed by ” one cloud vendor can make web service calls with it to any of the “national infrastructure” directory endpoints.

If I think like X.500, folk in the Windows SP world will likely STILL not make direct access to a Yahoo directory endpoint. Rather its more likely that a chained directory operation will be performed, with the chaining being orchestrated by the “cooperating clouds”. (And you can be assured that NSA/DHS/CIA/FBI are interested in JUST such a collection/collation point, since its now EASY to get the “consumer-centric” trap/trace records for the “cybersecurity” mission).

If this is what’s going on, this is JUST AS WAS IN secure X.500 concept of operations (as practiced in the Allied military Directory, for one). One issued (as a “governed” DUA/SP/App) a signed request to a local DSA (e.g. Windows SP/SharePointApp  to Windows DSA/ACS) and Windows Cloud will presumably now go chain off the (signed by JWT bearer) request to Yahoo’s graph  API say (and proxy the response from Yahoo back). It would also natrually resign the response – as required for the local security domain but only with symmetric keys that authorize and LIMIT the use of the (yahoo-managed) directory result at the particular SP’s _governed_ webservices (the APPs on particular registered webservice-endpoints, supporting such as Sharepoint Online at participating tenants)..

Now, this is 100%  conjecture. But, its what I would do (with 25 year old directory technology, rebuilt with webby blobs). AS with the Directory of 30 years ago, its the POLITICAL power that drives it – and of course it’s the politics that MAY WELL UDNERMINE it (once folks see it). What I can say, given its authorizing apps as well as access to the directory naming context is that its MORE than X.500 – which may induce greater social acceptance .. since “there is more” value.

If this concept were to be classified (so noone has much say, with this being the true point of the classification…), it would have merely a NATO Confidential label. In the US, it would be (stupidly) classified at top-secret (to give it an allure of importance within the million government and contractor employees entitled to see it…).


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in oauth, OpenID. Bookmark the permalink.