Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fraudpointer - Google Apps integration


Published on

Presenting the integration process and tips of Fraudpointer with Google Apps

Published in: Technology, Business
  • Be the first to comment

Fraudpointer - Google Apps integration

  1. 1. YOUR (RAILS) APP ONTHE GOOGLE APPSMARKETPLACELessons learned from integratingFraudpointer
  2. 2. Should I be interested? Scenario 1 :  You are a SaaS vendor  Your application is organization oriented (users belong to groups / organizations) Scenario 2 (with some constraints / changes) :  Same as 1 but user oriented Scenario 3 :  Your organization is using Google Apps  You have custom applications with “admin” sections
  3. 3. Presentation Outline What is Google Apps ™ / Marketplace What is Fraudpointer / Fraudpointer integration points Bootstrapping Dev environment Integrating Gotchas Further work Resources Acknowledgements Q/A
  4. 4. Google Apps Marketplace Google *what*?
  5. 5. Google Apps Marketplace  Thousands of applications that integrate with Google Apps accounts  You search, pick, ad d and use  Payment either transparent through the Marketplace or independently through the Vendors
  6. 6. Google Apps Marketplace Applications added to your Google Apps account are added organization-wide Applications added to your Google Apps account gain restricted access to your Google user’s data Only admins can add new applications
  7. 7. Google Apps Marketplace  As a vendor you sell your own applications
  8. 8. Benefits Organization perspective :  Streamlined experience  Integration with existing tools  Zero friction setup (hopefully) Vendor perspective  New marketing channel  Easier sign-ups / conversions  Customer happiness!
  9. 9. Google Apps MarketplaceIntegration points Required  SingleSign On  Universal navigation Optional  Provisioning  DataAPIs  Gmail contextual gadgets
  10. 10. Fraudpointer Fraud prevention platform  Credit card fraud  Account phising  Digital rights misuse  … SaaS A tool to be used alongside existing “enterprise” tools like  E-Commerce platform  CRM  ERP  Productivity / communication tools (Google Apps!)
  11. 11. Fraudpointer Major components  Account setup & configuration  Fraud Assessment API  Rule Engine  Reputation Database  Case Management …
  12. 12. Fraudpointer Integration Major components  Account setup & configuration  Fraud Assessment API  Rule Engine  Reputation Database  Case Management …
  13. 13. Fraudpointer Integration One click account creation & setup Single Sign On Gmail & Contacts integration Rule engine lists management from Google Spreadsheets Cases exporting to Google Spreadsheets
  14. 14. Fraudpointer Integration One click account creation & setup  Provisioning API (Read) Single Sign On  OAuth Gmail & Contacts integration  Gmail API (Read/Write/Send)  Contacts API (Read) Rule engine lists management from Google Spreadsheets  Spreadsheets API (Read/Write)  Docs API (Read/ Write) Cases exporting to Google Spreadsheets  Spreadsheets API (Read/Write)  Docs API (Read/Write)
  15. 15. Bootstrapping Google Apps account Not a @gmail one – a custom domain one! Free or paid Permissions to install applications on your Google Apps domain (needed during development)
  16. 16. Act as a vendor  You will act as a Vendor, selling your application  This is true both for live / development phase  GOTCHA : Vendor profiles “per user”. Not “per domain”
  17. 17. Add a listing  Create a new listing in your Vendor profile  This is what you are selling
  18. 18. Listing details  Application manifest is the most important thing  Listing manifest is not required!
  19. 19. Application Manifest Best practices  Declare the various API scopes in your code  Automatically generate the URLs from Rails helpers  Copy-paste the generated xml to the listing Gotchas  Watch out for whitespaces & blank lines before/after the actual XML!  Totally stupid listing form with totally stupid validation errors!
  20. 20. Listing save & preview  Save & preview without fear – nobody will see  Ignore the Analytics id and the Google APIs
  21. 21. Add it to start development! Don’t submit Just “Add it now” This is your development installation This is the same experience your users will have!
  22. 22. Addition is a 2-phase process When “agree” is pressed application is “added” No access to data yet! No configuration yet!
  23. 23. Addition is a 2-phase process Granting data access Read from the application manifest
  24. 24. Setup/Configuration (optional) Application has access Knows nothing (yet) about it’s addition though! This is where you “hook” and bootstrap the account!
  25. 25. Setup/Configuration (optional) The Google Apps admin sees a configuration screen Selects users / groups to import Configures other account settings The alternative is to import all Google Apps users (ouch!)
  26. 26. Successful addition
  27. 27. Successful addition
  28. 28. Development environment Hack your hosts so redirects / URLs are not “localhost”! Get a Google Apps account! One “installation” per developer (doesn’t scale really…)
  29. 29. Single Sign On Required integration point Based on OpenID Google is an OpenID Identity Provider via the OpenID Federated Login Service Fraudpointer acts as an OpenID Relying Party Google’s OpenID implementation : ence_implementation.html With Federated Login enabled, Google Apps users authenticate with OpenID to Fraudpointer Attention to the Discovery Mechanism : discovery
  30. 30. OpenID Authentication  Proves an end user “controls” an “identifier”  Simply put : one account – login to multiple sites!  Relying Party doesn’t require access to end user credentials (such as password)  User just types one piece of information (such as OpenID identifier)
  31. 31. OpenID authentication flow
  32. 32. OpenID Authentication Read guidelines for UI Use an existing library! Ruby has ruby-openid   Both for Relying Party & Provider  BTW, Fraudpointer does not use it directly and neither should you!
  33. 33. Single Sign On *Should* work out of the box with :  rack-openid  HTTPish API around ruby-openid  Uses ruby-openid internally  ruby-openid-apps-discovery  Support for Google’s discovery mechanism
  34. 34. Single Sign Onrequire gapps_openid # ....this is from ruby-openid-apps-discoveryrequire rack/openid # ....this is from rack-openid# ... inside the method that handles your login ...# you essentially respond with requirement to authenticate# since the user is considered unauthorized. You also provide# a callback URL and method so that when authentication ends# you take back the control. Discovery and the whole authentication# process is transparent to your code. You do not have to do anything# more than this.#headers[WWW-Authenticate] = Rack::OpenID.build_header( :identifier => options[:open_id], :required => ["", "", ""], :return_to => url_for(options[:return_to_options]), :method => options[:return_to_method])render :nothing => true, :status => :unauthorized
  35. 35. Single Sign Onrequest.env["rack.openid.response"]will have information about the success or failure of theauthentication.1st make sure that nothing of the following is falseparams[:open_id].blank? ||request.env["rack.openid.response"].nil? ||request.env["rack.openid.response"].status != :successIf everything ok, then you can be sure that user hasbeen authenticated and you can get his data andredirect to your home page:ax = OpenID::AX::FetchResponse.from_success_response(request.env["rack.openid.response"])@email = ax.get_single("")@first_name = ax.get_single("")@last_name = ax.get_single("")
  36. 36. Authorization  oauth  two-legged-oauth  Fraudpointer is a “consumer”
  37. 37. Authorization “two legged oauth”???
  38. 38. Access to Google Data APIs 2-legged Oauth is the source of the biggest confusion! On normal situations (no Google Apps) : A Google user ( grants access to a 3rd party application (freemium- for their data  3rd party application can now access this user’s data So for example, freemium-saas has access to all of the user’s Google Documents
  39. 39. Access to Google Data APIs On Google Apps situation is different A Google Apps domain administrator grants access for the all the domain’s users data to a 3rd party application ( 3rd party application plays the role of the currently logged in user by sending the identity of the user (xoauth_requestor_id) The current instance of the 3rd party application has same access to data as the requesting user would have The real user has no way of restraining access to his data for this app (only the admin)
  40. 40. Access to Google Data APIs Normal requests to Google Data APIs are like this : But for Google Apps using 2-legged Oauth it becomes this :
  41. 41. two-legged-oauth gem Transparent hack for all Ruby Google APIs libraries with OAuth support Rewriting on the fly the URLs so that it contains the magic “xoauth_requestor_id” parameter Ugly but seems to work so far (thus the 0.0.2 version) @!#$!@#$%%#$@ (yeah a lot of yelling, crying and bleeding because of this) Feel free to improve it!
  42. 42. Authorization (using the libs) Create OAuth::Consumer with key and secret Request (on Consumer) a request token Request (on Request Token) an access token On access token give as parameter the API resource you want to access Resource should be included in the manifest
  43. 43. Authorization and accessconsumer = Settings.google_apps.consumer_key, Settings.google_apps.consumer_key_secret),
  44. 44. Authorization - Scopes Data access to Google requires correct Scopes Scopes correspond to Google APIs Examples :  Contacts API :  Spreadsheets API : Some resources are “read only”
  45. 45. Existing Ruby libraries Provisioning  {SingleSign On}  two-legged-oauth  _our custom not-ready-for-prime-time library_
  46. 46. Existing Ruby Libraries Gmail  {Single Sign On}  gmail  gmail_xoauthPlus : Contacts  {SingleSign On}  two-legged-oauth  google_contacts_api
  47. 47. Existing Ruby Libraries Spreadsheets  {SingleSign On}  two-legged-oauth  google-spreadsheet-ruby
  48. 48. User Experience  Search and find the application in the marketplace  Watch for the icons!
  49. 49. Gotchas No official Google support for Ruby  Sparse documentation #@$@#$^& Development environment doesn’t scale for big teams
  50. 50. Further work Google Apps Marketplace meta-gem  Containing all gems that are required  Proper instructions (!!!) Merge various patches to official gem repos Better documentation
  51. 51. Q/A Ask ask ask! In any case :  Fraudpointer : support at  Authors :  n.dimitrakopoulosat  p.matsinopoulos at