2pm – 4pm : CA technologies–layer 7

API security for Cloud and Mobile – workshop




Being a six-sigma style company, CA Technologies produce good technology aimed at keeping otherwise incompetent multi-nationals from total security catastophes. The software concept typically aims at doing little other than meeting the minimum criteria, using full power software assurance engineering process to deliver really quite minimal value at an inflated price. But, as I indicated above, just REMEMBER who they are selling to – what kind of firm is their market. They are keeping billions of multi-national firms’ dollars safe (from their almost security-incompetent middle management staff and entirely technically-incompetent senior management). Against someone *other than* their own staff (and the mediocrity that bedevils multi-nationals), the firm’s solutions are useless. But protecting against corporate bloat and its reduction to almost-security-incompetence is big business (and I cannot say its not a valuable national service). The empire hobbles along, for a bit longer, still waiting for the final bubble to burst and take it out.

CA Technologies served a nice lunch, and I’m looking forward to some technical material – this being a “workshop”. In the last year, having evaluated closely the cloud fabric servers offered  by Ping Identity and, having rejected that vendor for pricing reasons, having then built our own OAUTH gateway leveraging our own existing, equivalent of SiteMinder’s websso features and the backend “OAUTH2 enabling” services of Microsoft Azure, it will be fun to see just how CA Technologies have packaged up similar material.



The seminar was a mix between a sales presentation, a pre-sales technical orientation on a client side SDK, and a CIO-oriented market and technology convergence talk.

In short, CA have a server not dissimilar to that of Ping Identities OAUTH module. As with the Ping offering, the focus is on those enterprises wishing to expose one or more of their own APIs to apps hosted on various devices. In the CA case, the oauth authorization service in their “mobile gateway” leverages the sideminder websso product. On the app side, apps on the device IF MANAGED BY the same gateway can “share state”, once a principal app (call it a logon app) has enrolled with the gateway’s built in CA to get an SSL client cert. One app, leveraging that cert from a shared container on the platform’s keyring for mutual SSL auth, can then complete user challenge, websso, token generation, consent for authorization grant issuance and then token retrieval. It can store the signed JWT form the gateway in a device-side container that all related-apps can access, upon launch. Should the second or third app detect that a valid and current JWT, with the relevant scopes, is present in the container of the keystore, it can opt to avoid the OAUTH handshake and simply present that JWT as an access token to web APIs. Ill guess that, in reality, the second and third app will use the shared “refresh token” from the container and will go get its own JWT…. with more suitable scopes for the WebAPIs in question.

Ok this was a useful 2h, and ill claim 2 CPEs for a vendor presentation. It showed how CA differentiates itself from Ping – whose module I evaluated in detail last year; it showed how openid connect is slowly making something of an entry; and it showed how apps on a device enroll for ssl client certs to enhance the oauth handshake and create an illusion of one app doing “single-sign on” for a collection of related apps.

Some handwaving was on show when a browser launched and did a website logon to a classical webapp (using the client cert, presumably).


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