How LinkedIn changed its security model in order to offer an API
•
19 likes•8,843 views
LinkedIn changed its security model from a simple permission-based model to a more complex role-based access control (RBAC) model to allow third-party partners to access its API on behalf of LinkedIn members. It also adopted an Amazon-style authorization approach for its API that signs requests rather than using expiring session IDs. Finally, it extended these concepts to its website by signing browser cookies in the same manner.
Report
Share
How LinkedIn changed its security model in order to offer an API
- 1. Security 2.0 How LinkedIn changed its security model in order to offer an API Yan Pujante Distinguished Software Engineer Member of the Founding Team @ LinkedIn ypujante@linkedin.com http://www.linkedin.com/in/yan
- 2. Background ■ LinkedIn created in 03/2003 • close to 30M members • profitable with 5 revenue lines • HQ in Mountain View (400 employees) ■ Technologies • 2 datacenters (~ 600 machines) • SOA, java, tomcat, spring framework, http, Oracle, MySQL, servlets, jsp, graph, OSGi... • dev on MacOS X, prod on Solaris
- 3. Content ■ Part I: • Security model and how we changed it ■ Part II: • API security: Yahoo vs Amazon models ■ Part III: • Beyond API: scaling the website
- 4. Content ■ Part I: • Security model and how we changed it ■ Part II: • API security: Yahoo vs Amazon models ■ Part III: • Beyond API: scaling the website
- 5. Website only ■ Simple model: BL checks permission level • Guest ? • Identified (remembered but not logged in) ? • Logged in ? ■ If not => logging screen
- 6. API / Partner ■ Opening LinkedIn to partners: make calls on behalf of a user (REST api) ■ Requires LinkedIn member to agree (one time operation) agree display agreement em/pwagreement key Partner LinkedIn Partner servers servers servers agreement key
- 7. API / Partners BL Linkedin WebSite Guest ? Indentified ? Business Logic Logged In ? API Server Partner Server ■ Does not work with partner... • Identity is different (partner with member) • Partner levels (trusted, basic...) • Different set of permissions
- 11. RBAC ■ RBAC stands for: Role-Based Access Control ■ Subject has 1 or more roles (principals) ■ Permissions are assigned to specific roles • You don’t do: ■ are you in role R ? (are you Identified ?) • Instead you do: ■ are you in a role that gives you permission to execute operation O ? (checkPermission)
- 12. Content ■ Part I: • Security model and how we changed it ■ Part II: • API security: Yahoo vs Amazon models ■ Part III: • Beyond API: scaling the website
- 13. API security / Yahoo ■ Yahoo model • login => get back sessionID • all requests include sessionID (expires) • client must manage sessionID ■ To be user friendly code must do: try execute request catch error if error == session expired login execute request
- 14. API Security / Amazon ■ Amazon model • Easier to implement ■ no more login, all requests are identical ■ no recovery to implement ■ no session to manage • Safer ■ valid a shorter amount of time ■ sign other parts of the request
- 15. Authorization Header ■ Each request has a new header • authenticate + signs the request ■ ptrID = partner ID ■ memberKey = member agreement ■ now = current time in seconds ■ signature = signs this header + request
- 16. Signature Hexa(HMAC-SHA1(UTF-8-Encoding-Of(StringToSign))) StringToSign= quot;PTMnquot; + Entity + quot;nquot; + now + quot;nquot; + HTTP-Method + quot;nquot; + Request-URI + quot;nquot; + Content-Type + quot;nquot; + Content-Length + quot;nquot; + Content-MD5 + quot;nquot; With: Entity = <api_key>/<agreement_key> now = number of seconds since Epoch (01/01/1970 UTC midnight) HTTP-Method = quot;GETquot; | quot;POSTquot;... Request-URI = everything after the host:port part of the URI Content-Type = content of the header (quot;quot; if header missing) Content-Length = content of the header (quot;0quot; if header missing) Content-MD5 = content of the header (quot;quot; if header missing)
- 17. Example: POST ■ Example: • ptrID = abcdef • memberKey = 1234 • Shared Key = “9876543210” POST /foo HTTP/1.1 Content-Type: text/plain Content-Length: 100 Authorization: LINAPI PTM:abcdef/1234:1189532154546:786533ec913320fd31ebaee878f055cf ■ String To Sign: PTMn abcdef/1234n 1189532154546n POSTn /foon text/plainn 100n n
- 18. API Security / Amazon ■ Drawback • bigger samples => easier to ‘guess’ the shared key • does not prevent re-playability issue ■ Solution • 2 shared keys ■ one for HTTP calls ■ one for HTTPS calls • API is read-only for now... need to fix it
- 19. Example: python
- 20. Content ■ Part I: • Security model and how we changed it ■ Part II: • API security: Yahoo vs Amazon models ■ Part III: • Beyond API: scaling the website
- 21. The website ■ Ported the concepts to the website • cookie is a token generated at login time ■ Signature uses same algorithm • signs the rest of the cookie • uses shared key (and secure shared key) ■ Every request ‘recovers’ the Subject: • verify signature • check expiration
- 22. New Architecture ■ Same path: • 1. recover Subject • 2. execute BL call
- 23. Single Sign On ■ Separate server for single sign on ■ Stateless front-end (good for scalability)
- 24. Conclusion ■ Pitfalls • permission representation is a nightmare: big + version • communication between servers makes it hard to track problems ■ Good news • It works! • It is scalable and flexible