Authentication, single sing on
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Authentication, single sing on

on

  • 2,575 views

 

Statistics

Views

Total Views
2,575
Views on SlideShare
2,573
Embed Views
2

Actions

Likes
0
Downloads
23
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Authentication, single sing on Presentation Transcript

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