Posts Tagged ‘Linkedin’

Introduction to OAuth 2.0, OpenID Connect, and SCIM


The development of SAML dates from January 2001. As discussed in an earlier post, SAML 2.0 provides a Single Sign On (SSO) authentication and authorization protocol that many view as applicable primarily for federations of enterprises. Mobile applications and dominant Internet applications such as Salesforce, Facebook, Google Apps, Linked In, etc. were providing more or less independent and light-weight “micro-services” fronted by APIs. SAML was deemed too heavy-weight to be supported by such APIs.

By 2014, authentication, authorization, and delegation (of authorized rights) for APIs, are embodied in the standards OAuth, OpenID Connect, and SCIM. These standards call for authentication and access tokens encoded in JavaScript-like Object Notation JSON rather than SAML’s (somewhat more verbose) XML. These JSON tokens are then passed in HTTP headers.

OAuth 2.0 has evolved to be a base technology for authorization, but it’s hard to do authorization without knowing to whom or to what you’re giving rights, and thus authentication sneaks in to the standard. To better address this, OpenID Connect has evolved from earlier versions of OpenID and other security work done by vendors to become a layer on top of OAuth 2.0 for authentication. It would seem that these two standards should merge.

While the proponents of OAuth and OpenID Connect predict that they will eventually supersede SAML, this doesn’t seem likely in the near future as SAML seems to do quite well for enterprises with existing relationships such as supply chains and portals. In addition, there are some use cases where the co-existence of SAML, OAuth, and OpenID Connect seems natural in spite of some duplication of functionality.

Finally SCIM, the System for Cross-domain Identity Management, addresses cross-domain identity management and specifically provides REST APIs for provisioning, change, and de-provisioning, all of which lie outside the realm of OAuth and SAML. SCIM adds considerable complexity to identity management systems, and I’m a little nervous that the initial implementations will have security problems. On the other hand, neglecting these functions is probably worse for security.

My next few IAM posts will discuss the latest versions for each of OAuth, OpenID Connect, and SCIM. I’ll also work an example of co-existence with SAML. The OAuth 2.0 post is next. It is here.

Learning from Financial Trading Bugs


The commodities and securities trading exchanges provide challenging examples for cloud and big data application development. Their users are disparate traders world wide. They have user requirements for high trading volumes and for low latency. They utilize enormous amounts of storage, networking, and computer processing power. My IEEE Computer Society talk, here, discusses some of the technical features for such applications and for the hardware on which they run. Ordinary public cloud systems cannot currently address these needs, and perhaps they never will. On the other hand, those of us developing big data and/or cloud software applications can learn a lot by studying these “bleeding edge” applications, their bugs, and the consequences of such bugs.

Big Data pioneers such as Yahoo!, Linkedin, Facebook, Google, eBay, etc. have, of course, their own bugs that have economic consequences for both the companies and their customers. Larger service providers such as Amazon, Microsoft, GoDaddy, and Rackspace have outages that do serious damage to their customers. However, financial trading applications can cause millions of dollars of damage in just a few seconds, and the governmental oversight agencies eventually get involved. This has happened in a big way this year [1,2] with four incidents that seem to have galvanized these agencies into action:

  • On Feb 24, options market maker Ronin Capital injected more than 30,000 mispriced quotes into the NYSE Amex exchange.
  • On March 23, the BATS Exchange, handling its own IPO traffic on top of other traffic, crashed. (How embarrassing!) Among other losses, this caused a brief 9% price decline in Apple shares.
  • On May 18, the Facebook IPO had many orders stalled and not executed on the NASDAQ exchange. The Union Bank of Switzerland, alone, lost more than $350 Million, and curiously Knight Capital lost $35.4 Million in this incident.
  • On August 1, the Knight Capital Group lost $440 Million by flooding the NYSE with bad orders.

Since “You can’t know the players without a program…”, here is a brief cheat sheet of agency acronyms:

  • CFTC = Commodity Futures Trading Commission
  • FIA = Futures Industry Association
  • FIA-EPTA = European version of the FIA-PTG
  • FIA-PTG = FIA’s Principal Traders Group
  • FRB = Federal Reserve Bank
  • FSOC = Financial Stability Oversight Council (established by the Dodd-Frank Act)
  • IOSCO = International Organization of Securities Commission
  • MFA = Managed Funds Association (hedge funds)
  • SEC = Securities Exchange Commission

Of course numerous observers clamored for reform, e.g. [5,6,7,10] but the above agencies started to issue calls for action:

  • MFA requested of the SEC mandatory risk checks on all orders, new requirements on system testing, and a requirement for an individual with a “kill switch” to watch over all trading activity. (Imagine not trusting computer programs and wanting a human being to watch over automated trading!) [14]
  • The FIA PTG/EPTA issued its “Software Development and Change Management Recommendations”, March 2012. While both reasonable and comprehensive, there is nothing new in the report from an academic software development perspective. What is interesting is that they felt it was necessary to prepare it for financial application development. [13,14]
  • The FSOC made some vague recommendations in July 2012 that the SEC and the CFTC consider establishing error control and standards for exchanges, clearing houses, and other market participants that are relevant to high-speed trading. [11]
  • August 2, the FIA PTG make a “soft” statement to the SEC at their Roundtable noting that the 2005 regulations, designed to encourage market competition created “different safety controls” which now need “smart regulatory policies.” August 3, FIA PTG/EPTA issued a stronger statement on the “Knight Capital” problem, stating “Rapid advances in trading technology have brought very substantial benefits… but … they also have introduced new sources of risk.” They reiterated their earlier recommendations for “tests and controls” that trading firms should consider when they change their technology systems. [12, 13]
  • August 2012 The IOSCO issued a “Consultation Report” entitled “Technological Challenges to Effective Market Surveillance Issues and Regulatory Tools” which called for greater data collection for the purposes of surveillance of automatic or algorithmic trading of securities. [8] It refers to an earlier paper “Objectives and Principles of Securities Regulation” dated May 2003 that has 38 “principles” for such software development and regulation. Both papers are good reading. IOSCO further warns of the dangers of the then (and now) situation due to the neglect of these principles. [3]
  • October 1, 2012 the FRB of Chicago issued a report “How to keep markets safe in the era of high-speed trading” by Carol Clark. By interviewing various vendors, the author points out that there are a few places in the system where checks can and should be made. It makes solid recommendations on various risk limits, risk mitigation techniques, kill switches, position limits, and profit and loss limits. Good paper. [4]
  • October 4, 2012 The FIA PTG responded to the Chicago FRB’s report, supporting its recommendations. [15]
  • October 10, 2012 The FIA PTG/EPTG responded to IOSCO’s recommendations for market surveillance and audit trail quality, wanting more, especially, surveillance for illegal or inappropriate conduct which might be facilitated by automated trading. [3]

Wow! Four bugs caused all this commotion? Well, no. The noticeable problems were occurring prior to 2012 and also outside of the US. (Many of these are discussed in earlier posts.) There clearly was a welling up of (and I’m not sure this is the right word, but) anger.

So, besides just being new, what is wrong? Well, in high frequency trading, speed is king, and it would appear that no one wants to slow down their software by putting in audit trails that IOSCO recommends. Vendors force the regulators to read the code to audit their systems! Can you imagine how worthless that exercise is? No one seems to realize that such code additions would actually help test and debug their systems. Risk and profit/loss limits seem easy to implement, but again while it does slow down the system a little bit, the more likely reason is that such limits are an annoyance. Again regulation is needed.

Complexity is probably the number two reason for such bugs hitting. Here comes the argument that good testing won’t find all bugs. On the other hand, most of the bugs reported (or deduced) seem well within the current art of testing. I’ve seen no bugs reported that only occur on weird combinations of extreme data. In one case, the addition of new code activated some old “dead” code [14]. Both bugs (dead code and the new activation problem) could have easily been caught by reasonable testing. I’ve read about the now boring excuse of rushing new functionality to market for competitive reasons. Give me a break. With hundreds of millions of dollars at stake, shouldn’t the vendors be able to afford decent automated test suites? Properly done, such test suites make the development go faster! On the other hand, I’d hate to see government regulations on testing. It would be a case of the ignorant policing the ignorant. My guess is that the best government regulations would be to impose massive fines and to enforce total restoration of all money lost due to a bug.  Even with proper catastrophe insurance, this should be significant motivation for quality!

For sure, a desire for high performance with complex software, made more difficult by dealing with relatively new big data infrastructure, is a recipe for lots of bugs. While I’ll discuss big data and cloud application development in subsequent posts, my thinking here is simple: Invest at least as much in your testing and its automation as you do in writing your application. Follow the IOSCO principles by adding code for debugging and for auditing. It will pay for itself. Get audited. Audits probably won’t find anything, but your financial and legal consequences will probably be less severe should a bug rear its ugly head. Also, when high performance in networking and IO is desired, go with new hardware that has built-in measurement and time-stamping features. It this is not possible, then add such measurements to your software. Finally, do some sanity checks and reasonability calculations to make sure you are not doing something fundamentally wrong.






[4] “How to Keep Markets Safe in the Era of High-Speed Trading”, Carol Clark, 9/17/2012, Essays on Issues, The Federal Reserve Bank of Chicago, October 2012, Number 303.











[15] October 2012 News.

Gayn’s Guide to Starting on Linkedin


Gayn’s Guide to Starting on Linkedin

There are many fine introductions to Linkedin.  There are some great courses as well.  For my friends who ask me for help, I’ve created the following:

0.  Signup with Linkedin.  It’s free.  Fill out a basic profile to get you started.  You can always (and you should frequently) edit and polish your profile.  I think a profile should include a photo appropriate for business.  I also recommend using an alias or secondary email address for Linkedin.  The spammers will eventually get your Linkedin email address, and it should be easy to change to avoid spam.

NOTE:  There are several ways to generate contacts in Linkedin.  My most fundamental advice is to do it one-at-a-time with an individualized message.  It could be to ask an old friend or colleague to get together, or it could be to explain to someone that you have common interests and that it would be mutually beneficial to get to know each other.  Always edit or add to Linkedin’s default message “I’d like to add you to my professional network.”  Also, never let Linkedin have access to your contact list, and never give Linkedin a distribution list (list of email address) to request contacts on your behalf.  The problem is that you can’t customize the request message!  I think impersonal requests cause more harm than good.  Linkedin and its users frown on using the “Don’t know” category in a connection request.  Some Linkedin users are LIONs (“Linked In Open Networkers”) who accept any invitation.  You can use “Friend” or your current company to connect to such users.  Often LIONs will add their email address to their public information to make it easy to contact and connect to them.  None-the-less, customize the invitation, even to a LION.

1.  To really start, convert your current contact lists to Linkedin contacts.  It doesn’t matter if they are in an old fashioned paper Rolodex, or in an email contact list.  Look the person up in Linkedin and click “Add to my network.”  If you’ve done business with that person before, click that button and select your company.  (This list comes from filling out your profile.) If you are just friends, click that button.  If you know their email address, click the “Other” button to get going. If you don’t know an email address, call the person.  Say what’s up, and ask for an email address so that you can connect on Linkedin.  If the person is not on Linkedin, call them up and refresh your acquaintance anyway.  For each person you talk to, ask, “Who do you think I should talk to about this?”  If their recommendation is someone you don’t know, ask for a referral/introduction.”

2.  Every business person in your XXX Club [Fill in XXX with any club you belong to. E.g. bowling, real estate, investing, etc.] should be in your Linkedin contact list.  Use the club’s membership list.  Make it a goal to happen.  You may need to call some members.  It’s a good excuse to talk, as above.  Do this also for all networking groups you join.

3.  Join just under 50 Linkedin groups that interest you. Set your group email for each to WEEKLY; otherwise you’ll be inundated with daily email from the group. The point here is that each group has a lot of chatter, often informative, and most have a list of open jobs and other opportunities.  Participate in the group dialogs, at the very least with a short introductory note when you join.  Note that everyone has access to your Linkedin profile, so that rambling on as to who you are is unnecessary.

4.  Do newspaper and web research.  When you find a name of interest, look it up on Linkedin, and see what groups that person belongs to.  If you’ve groups in common, then Linkedin will let you communicate directly to ask for a connection.  If not, join one of their groups.  [This is why you initially join under the limit of 50 groups – so that you can add more.]  If the person is interesting, then their groups are probably interesting.  When I personalize my connection request, I mention how that person’s name came up.

5.  Each time you get a connection, look at your contact’s contacts.  Obviously if you know someone, especially one you worked with before, ask them to connect.  Anyone who is interesting that you don’t know, but one who is in a common group, you can ask to connect using the Group option.  If this fails, ask your new contact for an introduction.

6.  Spend 30 minutes to an hour/day gathering contacts.  If you are really busy, skip that day, but don’t skip often or you won’t get anywhere.  After a few weeks, you’ll have enough contacts to seriously use Linkedin, but never stop adding connections. (Some have thousands!)

7.  Ask key contacts to write you a brief Linkedin recommendation.  As you reacquaint yourself with past colleagues, ask them (as appropriate) if they would like you to write a Linkedin recommendation for them.

8.  Linkedin Help works rather well.  Googling your help question also works, e.g. Google “how to delete a group in Linkedin”.  Also explore for more help and information.

9.  Using Linkedin for a job (or consulting) search.

a.  Look up and “Follow” each of your target companies.  Try to add as many contacts as you can from each such company using the above techniques.

b.  When you find an interesting opportunity in company X, look up your contacts in X, or try to add some.  Ask such a contact for details on the position, from their perspective, who was in the position formerly, who the hiring manager is, etc.  Note that the job description might say that the position reports to “Manager of FooBar”.  Use Linkedin’s Advanced Search to find out who that is.  With no luck finding the hiring manager, you can try for an HR manager who might give you some information.

c.  Linkedin’s job listings aren’t bad, especially if you have a simple set of attributes of job titles, e.g. “program manager” or “accounting director”.  Linkedin will cleverly send you listing of similar positions.

d.  Guy Kawasaki’s famous post “Ten Ways to Use LinkedIn to Find a Job” on his blog is worth reading.

e. Check if your target company is still hiring.  Company pages on LinkedIn include a section called “New Hires” that lists people who have recently joined the company.  Ask these new hires how they got their new job.  At the very least examine their backgrounds to surmise what made them attractive to your target company.

Good luck,