authentication and single sing on
TRANSCRIPT
Aplication AAplication BAplication CDBDBLDAP
Aplication AAplication BAplication CDBDBLDAP
DB
BrowserCASService
Authenticate
Initialrequest
Ticket transfer
Validate
Systems Integrationwith Free Software
Xavier Castao Garca
This session
We are going to talk about:
Systems integration
Single Sign On
Workshop
Centralized authentication
Central Authentication Service
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.
Systems integration
For example, this scenario:
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?
Systems integration
Other examples, and scenarios:
Systems accessing to different data sources.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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, ...
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.
Workshop
Workshop
New classes to implement:
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.
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.
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.
Workshop
Server development help:
sso.php should contain too:
getResponse: Generates a XML like this:
\n
user