Systems Integration with Free Software Xavier Castaño García

This session We are going to talk about: Systems integration Single Sign On Workshop Centralized authentication Central Authentication Service

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.

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:

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?

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.

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.

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.

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...

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.

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.

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.

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.

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.

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:

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 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 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 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.

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, ...

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.

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:

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.

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.

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.

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: <?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>

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>

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”.

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”.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

CAS CAS allows integration with several systems: Database LDAP Customized repositories... There are already several systems integrated with CAS: Acegi, PAM, Mantis, Horde, etc.

CAS allows integration with several systems:

Database

LDAP

Customized repositories...

There are already several systems integrated with CAS: Acegi, PAM, Mantis, Horde, etc.

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.

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.

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.

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.

CAS Protocol (without proxy):

Protocol (without proxy):

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 .

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 .