Authentication and Single Sing on


Published on

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Authentication and Single Sing on

  1. 1. Systems Integration with Free Software Xavier Castaño García
  2. 2. This session <ul><li>We are going to talk about: </li></ul><ul><ul><li>Systems integration </li></ul></ul><ul><ul><li>Single Sign On </li></ul></ul><ul><ul><li>Workshop </li></ul></ul><ul><ul><li>Centralized authentication </li></ul></ul><ul><ul><li>Central Authentication Service </li></ul></ul>
  3. 3. Systems integration <ul><li>Often, when we talk about systems integration in GNU/Linux, we are talking about systems administration. </li></ul><ul><li>In this session we are going to change our point of view about systems integration. </li></ul><ul><ul><li>We are going to talk about other kind of systems integration. </li></ul></ul>
  4. 4. Systems integration <ul><li>For example, this scenario: </li></ul>
  5. 5. Systems integration <ul><li>A user has to introduce always his personal data several times to different applications. </li></ul><ul><li>The user's password could be different, so the user should remember all the credentials to all the systems. </li></ul><ul><li>How could we improve this? </li></ul>
  6. 6. Systems integration <ul><li>Other examples, and scenarios: </li></ul><ul><ul><li>Systems accessing to different data sources. </li></ul></ul>
  7. 7. Systems integration <ul><li>How could we add new applications to these scenarios? </li></ul><ul><ul><li>If we want to use the current users... </li></ul></ul><ul><ul><li>If we want to access to current data sources ... </li></ul></ul><ul><li>We are in trouble if we don't forecast this situation during the first steps of our projects. </li></ul>
  8. 8. Systems integration <ul><li>Sometimes it's difficult to forecast this scenarios... </li></ul><ul><ul><li>... but we can analyze our problems a bit taking some important steps regarding our system scalability. </li></ul></ul>
  9. 9. Systems integration <ul><li>If we can forecast that: </li></ul><ul><ul><li>Several systems are going to access to a data source... </li></ul></ul><ul><ul><li>Several systems are going to manage common users... </li></ul></ul><ul><ul><li>Several systems are going to be accessed by subsets of users... </li></ul></ul><ul><ul><li>Several systems are going to manage independent users with independent usernames... </li></ul></ul>
  10. 10. Systems integration <ul><li>Several systems are going to access to several common data sources... </li></ul><ul><ul><li>We can define a generic API to access to the data source. </li></ul></ul><ul><ul><li>We can offer services to access to the data source. </li></ul></ul><ul><ul><li>We can think in a middleware framework. </li></ul></ul>
  11. 11. Systems integration <ul><li>Middleware... </li></ul><ul><ul><li>is software that connects components or applications. </li></ul></ul><ul><ul><li>is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture. </li></ul></ul><ul><ul><li>sits &quot;in the middle&quot; between application software working on different operating systems. It is similar to the middle layer of a three-tier single system architecture. </li></ul></ul>
  12. 12. Systems integration <ul><li>SOAP </li></ul><ul><ul><li>Simple Object Access Protocol </li></ul></ul><ul><ul><li>is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. </li></ul></ul><ul><ul><li>SOAP specifies the formats that XML messages should use, the way in which they should be processed, a set of encoding rules for standard and application-defined data types, and a convention for representing remote procedure calls and responses. </li></ul></ul>
  13. 13. Systems integration <ul><li>SOA: </li></ul><ul><ul><li>is an architecture where functionality is grouped around business processes and packaged as interoperable services. </li></ul></ul><ul><ul><li>SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. </li></ul></ul><ul><ul><li>Service contract: WSDL + XML schema + Web service policy. </li></ul></ul>
  14. 14. Systems integration <ul><li>Several systems are going to be accessed by subsets of users... </li></ul><ul><ul><li>All we did in the previous slide is still useful. </li></ul></ul><ul><ul><li>We can analyze if we can offer to users an unique point to access the systems. </li></ul></ul><ul><ul><li>We can analyze if we store users only in one repository. </li></ul></ul><ul><ul><li>We can analyze if the users should only introduce theirs credentials once. </li></ul></ul>
  15. 15. Single Sign On <ul><li>Single Sign On: </li></ul><ul><ul><li>Access control method to allow authentication in several systems introducing credentials once. </li></ul></ul><ul><ul><li>The user only need to introduce its username and password once, without having to re-introduce them to each accessed system. </li></ul></ul><ul><ul><li>The are several implementations for the concept and there isn't an standard. </li></ul></ul>
  16. 16. Single Sign On <ul><li>Single Sign On examples: </li></ul><ul><ul><li>Kerberos based: Kerberos requires credentials and offer a ticket. The other systems use the kerberos ticket. </li></ul></ul><ul><ul><li>Smart card based: Initial sign on promts the user for smart card and other systems use the smart card to get the credentials. </li></ul></ul><ul><ul><li>Enterprise Single Sign On: Designed to solve the problem of introduce credentials in several systems inside the organization. </li></ul></ul>
  17. 17. Single Sign On <ul><li>Single Sign On examples: </li></ul><ul><ul><li>Shared Authentication Schemes are not SSO strictly although they are designed to solve similar problems. </li></ul></ul><ul><ul><ul><li>OpenID: allows users to log on several web sites using a digital entity and eliminating the need for a different user name and password. OpenID is descentralized. </li></ul></ul></ul><ul><ul><ul><ul><li>It's the ID which has information about the provider. </li></ul></ul></ul></ul>
  18. 18. Single Sign On <ul><li>Single Sign On specific implementations: </li></ul><ul><ul><li>SSO web one to one: A site is used as authentication central. </li></ul></ul><ul><ul><ul><li>Advantages: You define the algorithm and the security level. </li></ul></ul></ul><ul><ul><ul><li>Disadvantages: All the implied systems need custom implementation and the protocol is specific. </li></ul></ul></ul>
  19. 19. Single Sign On <ul><li>Single Sign On specific implementations: </li></ul><ul><ul><li>Authentication central: central system developed to solved the generic problem and trying to define a standard. </li></ul></ul><ul><ul><ul><li>Advantages: Systems already supported. Not only web. </li></ul></ul></ul><ul><ul><ul><li>Disadvantages: Less control over the protocol. </li></ul></ul></ul>
  20. 20. Workshop <ul><li>We are going to develop a Single Sign On web server and a Single Sign On web client to test the SSO concept. </li></ul><ul><ul><li>We are going to use “ssoclient.tgz” and “ssoserver.tgz” as the basis for this task. </li></ul></ul><ul><ul><li>This is not the best solution but it's a very good exercise to know how can works other solutions like CAS, OpenID, ... </li></ul></ul>
  21. 21. Workshop <ul><li>Reviewing the ssoserver.tgz: </li></ul><ul><ul><li>Classes: Several classes that help us to use some libs: </li></ul></ul><ul><ul><ul><li>session.php: Session management. </li></ul></ul></ul><ul><ul><ul><li>mysqldb.php: Mysql lib wrapper. </li></ul></ul></ul><ul><ul><ul><li>user.php: User class to store user information. </li></ul></ul></ul><ul><ul><ul><li>util.php: Generic utility class. </li></ul></ul></ul><ul><ul><li>User: Contains the authentication handlers and the login form. </li></ul></ul><ul><ul><li>index.php and config.php: Main file that controls the flow for the application. </li></ul></ul>
  22. 22. Workshop
  23. 23. Workshop <ul><li>New classes to implement: </li></ul>
  24. 24. Workshop <ul><li>Reminder “Sessions in php”: </li></ul><ul><ul><li>Php creates all the infraestructure every request. </li></ul></ul><ul><ul><li>The way php can relate one click with another is the session. </li></ul></ul><ul><ul><li>The session has an unique identifier and this identifier is stored in the user agent (the browser) as cookie or it is propagated in the URL. </li></ul></ul>
  25. 25. Workshop <ul><li>Reminder “Sessions in php”: </li></ul><ul><ul><li>The session information is stored in the server and it's only recoverable with the session identifier. </li></ul></ul><ul><ul><li>The session can be accessed using $_SERVER variable and it is an associative array. </li></ul></ul><ul><ul><li>This variable is stored to hard disk several times during a single request and all the information is completely overwritten. </li></ul></ul>
  26. 26. Workshop <ul><li>Server development help: </li></ul><ul><ul><li>Add a class sso.php to “classes” that implements: </li></ul></ul><ul><ul><ul><li>IMPORTANT: GET session variable name should be the same than the stored cookie. </li></ul></ul></ul><ul><ul><ul><ul><li>This variable should be set as current session. </li></ul></ul></ul></ul><ul><ul><ul><li>isValidSession: Checks if session is valid comparing session and GET variable and obtaining the username from session checking that is tha same than the GET parameter. </li></ul></ul></ul>
  27. 27. Workshop <ul><li>Server development help: </li></ul><ul><ul><li>sso.php should contain too: </li></ul></ul><ul><ul><ul><li>getResponse: Generates a XML like this: </li></ul></ul></ul><ul><ul><ul><ul><ul><ul><ul><li><?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> </li></ul></ul></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><ul><ul><li><response> </li></ul></ul></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><ul><ul><li><parameter name=&quot;username&quot;>user</parameter> </li></ul></ul></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><ul><ul><li><parameter name=&quot;session”>sessioncookie</parameter> </li></ul></ul></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><ul><ul><li><parameter name=&quot;authenticated&quot;>1</parameter> </li></ul></ul></ul></ul></ul></ul></ul><ul><li></response> </li></ul>
  28. 28. Workshop <ul><li>Server development help: </li></ul><ul><ul><li>Add directory sso to add ssoserver.php to sso directory where: </li></ul></ul><ul><ul><ul><li>The system retrieves two GET variables: username and session. </li></ul></ul></ul><ul><ul><ul><li>The system calls to getResponse with retrieved variables and shows the XML to the client. </li></ul></ul></ul><ul><ul><li>Modify index.php to call ssoserver.php depending on a GET parameter. For example: “sso=server”. </li></ul></ul>
  29. 29. Workshop <ul><li>Server development help: </li></ul><ul><ul><li>Configuration parameters: sessionname and clienturl. The second is needed to call the client, but it should be managed from database to allow several clients. </li></ul></ul><ul><ul><li>Modify loginform.php adding client url to template, in order to allow accessing to the client. </li></ul></ul>
  30. 30. Workshop <ul><li>Client development help: </li></ul><ul><ul><li>Add a sso directory to add ssoclient.php where: </li></ul></ul><ul><ul><ul><li>The url to the server with the session and username parameters should be added. </li></ul></ul></ul><ul><ul><ul><li>Process the XML output from the server and check if authenticated is true. </li></ul></ul></ul><ul><ul><ul><li>Call to validateUser that checks if username exists in our system. </li></ul></ul></ul><ul><ul><ul><li>If user exists then adds username to the session. </li></ul></ul></ul>
  31. 31. Workshop <ul><li>Client development help: </li></ul><ul><ul><li>Add a userssohandler.php to implement validateUser checking only username. </li></ul></ul><ul><ul><li>Configuration parameters: sessionname, session_server_name and serverurl to build the url where the session and user are going to be checked. </li></ul></ul><ul><ul><li>Add to index.php a “require_once” to ssoclient.php to pre-process all the needs before validate. </li></ul></ul>
  32. 32. Centralized authentication <ul><li>This is a solution to Single Sign On scenario. </li></ul><ul><li>Only one server authenticate the user. </li></ul><ul><li>All the systems that rely on the authentication server don't ask for the credentials if the user is already authenticated. </li></ul>
  33. 33. Centralized authentication <ul><li>The central authentication systems has some advantages to other solutions: </li></ul><ul><ul><li>There are systems that are already adapted to the protocol. </li></ul></ul><ul><ul><li>Not only web systems can use this kind of systems (depending on the specific solution). </li></ul></ul><ul><li>But they have some disadvantages: </li></ul><ul><ul><li>You have less control in the decisions related with the protocol, for example, navigation control. </li></ul></ul>
  34. 34. CAS <ul><li>CAS is the “Central Authentication Service”. </li></ul><ul><li>This service was developed by Yale University to provide a trusted way for an application to authenticate user. </li></ul><ul><li>CAS is developed in Java and it needs an application server to run. </li></ul>
  35. 35. CAS <ul><li>CAS allows integration with several systems: </li></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>LDAP </li></ul></ul><ul><ul><li>Customized repositories... </li></ul></ul><ul><li>There are already several systems integrated with CAS: Acegi, PAM, Mantis, Horde, etc. </li></ul>
  36. 36. CAS <ul><li>CAS actors: </li></ul><ul><ul><li>Authentication central: The arbitrate to rely the authentication. </li></ul></ul><ul><ul><li>Services: Different clients that rely on the central to allow users access. </li></ul></ul><ul><ul><li>Proxies: Services that wants act as authentication central. </li></ul></ul><ul><ul><ul><li>Typical example: pam module to connect to IMAP server. </li></ul></ul></ul><ul><ul><li>Target : A service that accepts proxied credentials from at least one particular proxy. </li></ul></ul>
  37. 37. CAS <ul><li>CAS: </li></ul><ul><ul><li>CAS changes information using tickets. </li></ul></ul><ul><ul><li>There are several types of tickets: </li></ul></ul><ul><ul><ul><li>TGC: Stored as cookie by the browser and only CAS will use it. Only should be used in a secure channel. </li></ul></ul></ul><ul><ul><ul><li>ST: Ticked sent to a service to use once. </li></ul></ul></ul><ul><ul><ul><li>PGT, PGTIU and PT: Ticket for proxy purposes. </li></ul></ul></ul>
  38. 38. CAS <ul><li>Protocol (without proxy): </li></ul>
  39. 39. CAS <ul><li>Protocol steps: </li></ul><ul><ul><li>User access to web site. </li></ul></ul><ul><ul><li>Web site redirects to CAS. </li></ul></ul><ul><ul><li>CAS asks for credentials. </li></ul></ul><ul><ul><li>CAS send ticket and redirects to service. </li></ul></ul><ul><ul><li>Service validate ticket with CAS. </li></ul></ul><ul><ul><li>Service gets user. </li></ul></ul><ul><ul><li>Service allows user access . </li></ul></ul>