Published on

Presented at Catania GTUG. This presentation is about the integration between openid and opensocial. Openid specification are described and the presentation involves in realization of a provider openid, a relying party a container opensocial and some gadgets.
Are described technologies like communityid, poidsy, shindig, pigeon, m4p2 and some others...

Published in: Technology
1 Comment
1 Like
  • For anyone looking for a turnkey deployment of OpenID and integrated publishing to the social networks, you might also want to have a look at Janrain's Engage:
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. OpenID + OpenSocial Integration between two “open” technologies Sebastiano Merlino aka eTr Gtug Group - Catania - Italy July 10th, 2010 1 / 33
  2. 2. OpenID + OpenSocial What about OpenID? OpenID (now at version 2.0) is an open, decentralized standard for authenticating users that can be used for access control, allowing users to log on to different services with the same digital identity where these services trust the authentication body. Wikipedia, the free encyclopedia Who controls OpenID? OpenID is decentralized and not owned by anyone. Every person can choose to become an OpenID provider without having to register or to be approved by any organization. The OpenID Foundation was formed to assist the open source community working like a legal entity. 2 / 33
  3. 3. OpenID + OpenSocial The OpenID protocol Glossary End-User: the person who wants to log in. Identifier: the standard URI or XRI used to identify the End-User (also called OpenID). OpenID provider: a service provider that offers the possibility to register OpenID URLs and XRIs and providing OpenID authentication. Relying Party: The site that wants to verify the End-User identity. It is also called Service Provider. Server Agent: The server that verifies the End-User’s OpenID. It usually is the same of the OpenID provider. User Agent: The program used by the End-User to access to the provider or to the relying party. It usually is a browser. 3 / 33
  4. 4. OpenID + OpenSocial The OpenID protocol There are two types of identifiers allowed: URLs and XRIs. There are two ways to obtain an OpenID enabled URL that can be used to access to a relying party: 1 To use an existing URL under user control linking to a page which contains OpenID tags in the HTML or serves a Yadis document. 2 To register to an OpenID provider. They usually offer to register a third level domain URL configured with OpenID HTML tags. Some providers generate on request a Yadis document with details about the end-user. XRIs are a new type of internet identifier designed for cross-domain identification. XRIs come in two forms: i-names and i-numbers that are registered as synonims. I-names can be reassigned but an i-number is never reassigned. An i-name is immediatly translated to it synonim i-number that is stored as OpenID by the relying party. 4 / 33
  5. 5. OpenID + OpenSocial The OpenID protocol The Login 1 The user provides his OpenID to the relying party using the form on their page. It is supposed that the user has already registered an OpenID identifier with an OpenID provider. 2 The relying party normalizes the provided OpenID. If the OpenID is an URL, the relying party implementing OpenID 1.0 requests the web page located at that URL and reads the proper HTML Tag to discover the identity provider service URL or receive a Yadis document with informations. With OpenID 2.0 instead, the OpenID is a XRI and the relying party discovers the identity provider service URL by requesting a XRDS document (Yadis) following the path indicated by the XRI. 5 / 33
  6. 6. OpenID + OpenSocial The OpenID protocol The Login 3 At this point the communication starts. The relying party can communicate with the provider without interaction with the user (checkid immediate) or, like it is popular in web, notificating the user and using his browser (checkid setup). 4 Relying party and provider establish a shared secret (starting from a nonce and using a Diffie-Hellman). With checkid setup the relying party redirects the user to the OpenID provider. 5 The provider requires the user a permission for the relying party. 6 If the user declines, he is redirected to the relying party with an error message, instead, if the user confirms the relying party verifies the authentication validating the shared secret. 7 At this point if the validation is successful, the user is considered logged in. 6 / 33
  7. 7. OpenID + OpenSocial The OpenID protocol HTML with OpenID Tags An OpenID tagged HTML page must contains these two links: <link rel=‘‘openid2.provider openid.server’’ href=‘‘’’/> <link rel=‘‘openid2.local id openid.delegate’’ href=‘‘’’/> XRIs An XRI (eXtensible Resource Identifier) is a scheme resolution protocol for abstract identifiers. If an XRI starts with “=” it identifies a person, if starts with “@” identify an organization an if starts with “+” indicates a generic concept. Every name (i-name) can be converted into an i-number. xri://=Sebastiano.Merlino xri://=!1000.aib3.c6f2 xri://+phone.number xri://+!1000.f4f5.c3f5 xri:// xri://!1000.aib3.c6f2) 7 / 33
  8. 8. OpenID + OpenSocial The OpenID protocol Yadis Yadis is a communication protocol for discovery of services. A Yadis ID can be a URL or a XRI i-name that can be resolved to a URL. The Yadis protocol specifies how to retrieve a service descriptor called Yadis Resource Descriptor. This descriptor follows the XRDS format to connect to several services. < ?xml version=1.0 encoding=UTF-8?> <xrds:XRDS xmlns:xrds=xri://$xrds xmlns=xri://$xrd*($v*2.0) xmlns:openid=} <XRD> <Service priority=50} <Type></Type> <URI></URI> <openid:Delegate></openid:Delegate> </Service> </XRD> </xrds:XRDS> 8 / 33
  9. 9. OpenID + OpenSocial and...OAuth? OAuth and OpenID sounds like the same thing but they are really different. If OpenID exists to give access to multiple web sites, OAuth lets to authorize one website (called consumer) to access data from another web site (provider). The Open Authentication Google and Plaxo have released a hybrid protocol that combines OpenID with OAuth. Often, when a site wants to use services by another site, it requires login access details that the user may doesn’t want to condivide. To circumvent this problem has been created OAuth that drive the user to the provider, sending back him after the login. This technique can be improved with OpenID that can make this operation automatic. 9 / 33
  10. 10. OpenID + OpenSocial OpenID: Advantages and Disadvantages Advantages Accelerate SignUp process Reduce frustration of mantaining multiple Username and Password Minimize Password security risk Gain greater control over online identity Disadvantages The OpenID provider may track users’ habits. Third party authenticate your users. 10 / 33
  11. 11. OpenID + OpenSocial OpenID implementations Provider Community-ID (PHP) Relying Party Prarie (PHP) Poidsy (PHP) Masquerade (Ruby) Openid4Java (Java) DjangoID (Python) jopenid (Java) Packetizer OpenID Server (Perl) DotNetOpenAuth (.NET) DotNetOpenID (.NET) JOS (Java) 11 / 33
  12. 12. OpenID + OpenSocial OpenID provider: Community-ID Community-ID is an OpenID PHP implementation of a provider which is OpenID 2.0 compliant. Community-ID is totally free in use and is build 100% over Open Source software. This software is licensed under the BSD license. To use Community-ID, you have only to install it. For the installation the software requires a WebServer installed with support for PHP 5.2.4 or greater with the MySQLi installed. It is also required a MySQL database (version 4.1 or greater). These modules are required: php5-core php5-mysql php5-pdo mysql php5-gd php5-gmp. 12 / 33
  13. 13. OpenID + OpenSocial Relying Party: Poidsy Example <?php session start(); if (isset($ POST[’openid url’]) isset($ REQUEST[’openid mode’])) { if (isset($ POST[’openid type’]) && $ POST[’openid type’] != ’openid url’) { define(’OPENID URL’, $ POST[’openid type’]); } require(’../../processor.php’); //the poidsy validation script } else { [...some layout stuff...] if (isset($ SESSION[’openid’][’error’])) { unset($ SESSION[’openid’][’error’]); } else if (isset($ SESSION[’openid’][’validated’]) && $ SESSION[’openid’][’validated’]) { unset($ SESSION[’openid’][’validated’]); if (isset($ SESSION[’openid’][’sreg’])) { [ data...] unset($ SESSION[’openid’][’sreg’]); } 13 / 33
  14. 14. OpenID + OpenSocial Relying Party: Poidsy Poidsy is a full functional set of PHP script that serves like OpenID relying party. The difference between Poidsy and other libraries is the ability of this implementation to not expose the OpenID logic. It can only be used without writing a single line of code. In the previous example, it is shown how to use the poidsy library. It is required to start a session where the library stores his values. If is passed to the page an OpenID url, the scripts requires the processor.php script to validate and authenticate the user. The same page is used to receive a response from the provider. If the response is an error, it is possible to print on the screen an error message, otherwise it is possible to read the response and use it like user data. 14 / 33
  15. 15. OpenID + OpenSocial Relying Party: Pigeon 32 valor medals were consigned to pigeons during the Second World War. Only 26 to dogs. 3 to horses. Only 1 to a cat. (What has he done? He has perhaps eaten a german pigeon?!?!) Remember: when the battle starts and the situation becomes chaotic with machine guns, artigliery and gas, we must trust the pigeons. Pigeon service was implemented by Dario Mazza, Sebastiano Merlino, Marco Messina, Davide Giuseppe Monaco, Paolo Pino and Eugenio Priscimone. It uses Openid4Java to realize a fully compatible relying party for OpenID verions: 1.0, 1.1 and 2.0. 15 / 33
  16. 16. OpenID + OpenSocial Relying Party: Pigeon Classes Pigeon consists in three classes: PigeonService, AuthenticationServlet, OIDResponseServlet. PigeonService implementation PigeonService consists in four methods: getConsumerManager : necessary to obtain the Openid4Java ConsumerManager. discoverOnIdentifier : used to obtain DiscoveryInformation necessary to the user’s effective authentication. createAuthRequest: method used to obtain the AuthRequest to send. processData: necessary to obtain an userID from the provider’s response. 16 / 33
  17. 17. OpenID + OpenSocial Relying Party: Pigeon getConsumerManager private static ConsumerManager getConsumerManager(){ if (consumerManager == null) { [...] consumerManager = new ConsumerManager(); consumerManager.setAssociations(new InMemoryConsumerAssociationStore()); consumerManager.setNonceVerifier(new InMemoryNonceVerifier(10000)); } [...] return consumerManager; } This method first initialize an empty ConsumerManager, then it decides what class is responsible to store the associations with providers. At the end the method sets a validity time for the nonce and returns the ConsumerManager. 17 / 33
  18. 18. OpenID + OpenSocial Relying Party: Pigeon discoverOnIdentifier public static DiscoveryInformation discoverOnIdentifier(String userSuppliedIdentifier){ DiscoveryInformation ret = null; ConsumerManager consumerManager = getConsumerManager(); [...] List discoveries =; ret = consumerManager.associate(discoveries); [...] return ret; } This method first initializes a null DiscoveryInformation and then using the ConsumerManager it discovers informations about the userSuppliedIdentifier. At the end the method returns the DiscoveryInformation. 18 / 33
  19. 19. OpenID + OpenSocial Relying Party: Pigeon createAuthRequest public static AuthRequest createAuthRequest(DiscoveryInformation discoveryInformation, String returnToAviary){ AuthRequest retValue = null; [..] retValue = getConsumerManager().authenticate(discoveryInformation, returnToAviary); SRegRequest req = SRegRequest.createFetchRequest(); retValue.addExtension(req); [..] return retValue; } This method uses the DiscoveryInformation to authenticate the user imposing to redirect to the url indicated in returnToAviary after the login. The method at the end returns the authRequest. 19 / 33
  20. 20. OpenID + OpenSocial Relying Party: Pigeon processData public static UserId processData(DiscoveryInformation discoveryInformation, ParameterList parameterList, String returnToAviary){ UserId ret = null; [...] VerificationResult verificationResult = getConsumerManager().verify(returnToAviary, parameterList, discoveryInformation); Identifier verifiedIdentifier = verificationResult.getVerifiedId(); if (verifiedIdentifier != null) { AuthSuccess authSuccess = (AuthSuccess) verificationResult.getAuthResponse(); ret = new UserId(UserId.Type.valueOf(me), verifiedIdentifier.getIdentifier()); } [...] return ret; } This method first verifies the idenitfier with the nonce and then stores it inside an UserID. 20 / 33
  21. 21. OpenID + OpenSocial Relying Party: Pigeon Authentication Servlet [...] DiscoveryInformation discoveryInformation = PigeonService.discoverOnIdentifier(userSuppliedIdentifier); req.getSession(true).setAttribute(“discoveryInformation”, discoveryInformation); AuthRequest authRequest = PigeonService.createAuthRequest(discoveryInformation, returnToUrl); res.sendRedirect(authRequest.getDestinationUrl(true)); [...] OIDResponseServlet [...] UserId uid = PigeonService.processData((DiscoveryInformation) req.getSession(true).getAttribute(“discoveryInformation”), new ParameterList(req.getParameterMap()), returnToUrl); UserHelper.setSessionUid(req,uid.getUserId()); UserHelper.setSessionUserHash(req,uid.hashCode()); AuthenticationResponse ar = new AuthenticationResponse(uid.getUserId()); [...] 21 / 33
  22. 22. OpenID + OpenSocial Relying Party: Pigeon These two servlet respectively requires authentication to the provider and receives his response. It could be seen how the servlet have only to use the methods implemented by the class Pigeon. Like can be seen in the previous slides is really simple to implement a relying party also using the java api Openid4Java. In this case, unlike Poidsy, we are not blind in front of the software implementation, so we need to have a knowledge of OpenID specification to make general at all our implementation. 22 / 33
  23. 23. OpenID + OpenSocial OpenSocial It’s open, it’s social, it’s up to you OpenSocial is a set of web API designed by Google, MySpace and many others web organizations with the objective to make interoperable every application implementing it with any social network system that supports them. It’s a set of two APIs, for javascript and REST. The javascript API are designed for “web gadgets” written in Google’s gadgets architecture. The REST API is for other apps: desktop, mobile and server. Gadgets are written using the Gadgets API. Any site that can host gadgets is called container. 23 / 33
  24. 24. OpenID + OpenSocial OpenSocial: Gadgets Structure of a Gadget <?xml version=‘‘1.0’’ encoding=‘‘UTF-8’’ ?> <Module> <ModulePrefs title=‘‘Hello World!’’> <Require feature=‘‘opensocial-0.8’’ /> </ModulePrefs> <Content type=‘‘html’’> <![CDATA[ Hello, world! ]]> </Content> </Module> <Module> indicates that this XML contains a gadget. <ModulePrefs> contains information about the gadget. <Require feature=“opensocial-0.8” /> denotes a required feature of the gadget. <Content type=“html”> indicates that the gadget’s content type is HTML. 24 / 33
  25. 25. OpenID + OpenSocial OpenSocial: Container Apache Shindig The reference implementation for an OpenSocial Container is Apache Shindig. An OpenSocial container is not merely a box designed to contains gadget but it also involves in the creation of a social infrastructure between members of the site implementing the API. There are two implementation for the Shindig Container: Java and PHP; these two versions have 3 major server side components: Persistent Data Loading Mechanism; Gadget Rendering Infrastructure OpenSocial server-side Implementation 25 / 33
  26. 26. OpenID + OpenSocial OpenSocial: Container Some features are client side, like: The real gadget container (in javascript) The OpenSocial container JSon, Restful and Caja support OpenSocial APIs OpenSocial’s API implemented are: OpenSocial REST : for Server-to-Server communications OpenSocial JSON-RPC : for Gadget-to-Server communications Javascript: for Gadgets implementation 26 / 33
  27. 27. OpenID + OpenSocial OpenSocial: Container Implementation Shindig Installation The shindig installation system is really simple. It just consists in extracting the downloaded archive to the directory where you wish install Apache Shindig. For the J2EE version the installation consists in copying the WAR file to $TOMCAT HOME/webapps if the server used is Tomcat. Building from source requires Java 1.5 or later with JAVA HOME environment variable set and Apache Maven already installed. For the PHP version you have just to copy shindig-php into a directory in /var/www obviously intending you have installed an Apache PHP server. Prerequisites are PHP 5.2.x with mod rewrite enabled with the json, simplexml, mcrypt and curl extensions enabled. 27 / 33
  28. 28. OpenID + OpenSocial OpenSocial: Container Implementation To personalize your container (client-side in js) you have to override methods from the default implementation changing functionalities to resemble what you want. Usually you have rewrite the main funcion renderGadgets. M4P2 M4P2 is an extension of the javascript client-side shindig container adding to it some functionalities using jQuery library. It has been realized by Dario Mazza, Sebastiano Merlino, Marco Messina, Davide Giuseppe Monaco, Paolo Pino and Eugenio Priscimone. It just consists in a single js script that can be used like container for OpenSocial Gadgets. 28 / 33
  29. 29. OpenID + OpenSocial OpenSocial: Container Implementation function renderGadgets(incoming, enable cb, disable cb) { enable sorting=(typeof(enable cb)==’function’) ? enable cb : function() {}; disable sorting=(typeof(disable cb)==’function’) ? disable cb : function() {}; [...] eval(var json data = + incoming); var ids = []; var urls = []; for (var el in json data) } ids.push(json data[el].id); var buffer = gadgets.container.createGadget(}specUrl: json data[el].url{); gadgets.container.addGadget(buffer); urls.push(buffer); } gadgets.container.layoutManager.setGadgetChromeIds(ids); for (var el in urls) { gadgets.container.renderGadget(urls[el]); var gadgetIframe = document.getElementById(urls[el].getIframeId()); gadgetIframe.setAttribute(’style’, ’width: 100%; max-height: 400px;’); } gadgets.container.refreshGadgets(); } 29 / 33
  30. 30. OpenID + OpenSocial OpenSocial: Container Implementation M4P2 In the previous slide is presented a piece of code from the overriding of the function renderGadgets. This function accepts three params: incoming, enable cb, disable cb. The first parameter is a string in JSON format: [{’id’:’gadget-chrome-x’,’url’: ’gadgets/Login/Login.xml’},{ ’id’:’gadget-chrome-y’, ’url’:’http://localhost:8080/examples/getFriendsHasApp.xml’ }] “id” indicates the name of the div that has to contain the gadget. “url” is the path to reach the gadget. The block that follows registers the gadget and renderizes it. 30 / 33
  31. 31. OpenID + OpenSocial A final merge <?xml version=“1.0” encoding=“UTF-8”?> <Module> <ModulePrefs title=“OpenSocial - Login utente” height=“250”> </ModulePrefs> <Content type=“html”> <![CDATA[ [...javascript inclusions...] [ some stuff to print layout...] function accesso(){ var parametri = document.getElementById(“logstring”).value.split(“-”); var username = parametri[0]; var opname = parametri[1]; if(username==none){ window.location = “” + opname; } else { var uid = document.getElementById(“userid”).value; window.location = “” + opname + “&uid=” + uid; } [ some stuff to fill form...] } ]]> </Content> </Module> 31 / 33
  32. 32. OpenID + OpenSocial A final merge An OpenID gadget In the previous slide it can be seen an example of a OpenID login gadget. In this example have been used a modified shindig container (M4P2) that uses a relying party “Pigeon” developed on openid4java connecting with a huge number of provider. At this point we have realized our global authentication tool that using OpenID makes easy the life of the user. In addiction to this, we can distribute our gadget to any site implementing OpenSocial containers and that wants to use it. Supposing we want to start our OpenID provider it could be an extremely interessant example of software distribution as advertisement. An interessant plan for the future could be to implement support also to OAuth allowing easy data exchange and creating an automatic site ring. 32 / 33
  33. 33. OpenID + OpenSocial Links... - to read about OpenID specifications. - article and oauth extension/latest/ specifications about the OAuth extension of OpenID. - A link to a collection of library to realize an OpenID provider. - The official OpenSocial project page. - Shindig official web page. 33 / 33