Global Login System specification

 

#000001: Overview

#000002: Data transfer between hosts

#000003: Bookmarks

#000004: Security

#000005: Logging in

 

===========================================================================

#000001: Overview

=======================================

Suppose we have a given list of independent web hosts located at different places, each accessible by a different domain.

Each host has its own set of user accounts.

 

Common functions of GLS are:

  1. Performing data transfer between hosts
  2. Providing bookmarks

 

===========================================================================

 

 

===========================================================================

#000002: Data transfer between hosts

=======================================

 

1.    Functions description

2.    Requests format description

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

1.    Functions description

 

The main feature of GLS is to allow different independent hosts connect to each other directly and transfer some data.

Each host has a private and a public PGP keys and a list of other hosts’ public keys. We do not consider here the problem of how these data will be entered (let us enter them by hand).

 

So, GLS must contain a library (a PHP class) with following functions:

a.  Get a list of registered hosts

b.  Send a custom request to the remote host and get the response

 

Thus, GLS must also contain the second part, a library which would:

a.  Receive a request from the remote host

b.  Perform some pre-defined actions depending on the local destination of the request (described below)

c.  Return some data (if necessary)

 

GLS doesn’t touch contents of the request. Its function is only in transmitting.

 

2.    Requests format description

 

Request is some data sent from one host to another; the system contains many parts which use these functions, so each part will use GLS to send some necessary data. So we should discuss the following things:

 

Format:

We will use RPC and packets in XML format.

More precisely, GLS must have a function with parameters:

·         Host id

·         Request type

·         Request data

GLS will access a table containing the following data for each host of the system:

·         Id

·         URL

·         Comment

·         Public PGP key

The parts of the system, calling this function, will send ordinary PHP variables (arrays) as “Request data”. GLS has to form an XML request from this data.

GLS must include “Request type” into an XML request also.

So after forming XML request, GLS sends the XML packet to the corresponding server (B).

When the GLS library of the server B gets a packet from the server A, it looks at the “Request type” included in to the packet. Then depending on the value of the “Request type”, it calls one of the functions of the system. You will be given a list of accordance “request type” – “function name and location”. When the function responses, GLS sends the response back to A.

 

===========================================================================

 

===========================================================================

#000003: Bookmarks

=======================================

      User’s home site will store some set of pages of foreign hosts to visit. The user can manage this list (add/edit/delete bookmarks’ names/links). These links must be clickable. A click will open a new explorer window at a place the bookmark leads to. Every user has it’s own personal set of the links.

      Every page of the remote host contains an “Add to my bookmarks” link (visible to the logged in users only, of course). When it’s clicked, a corresponding request to the home host is sent.

 

      So, GLS must provide:

a.  Bookmarks managing page

b.  Adding bookmark (sends request to the home site)

 

Now, more detailed description of what should happen when the user clicks the link:

User’s logging in into the home site (A) causes a corresponding session to A to be created. A has the list of opened sessions to foreign sites. From the beginning, this list is empty.

When the user clicks the link leading to the foreign host, A produces a page with a redirection to B. This page contains an encrypted XML packet with data of:

a.    pseudo used

b.    preferred language

c.    time of request (the present time of computing this data that will be checked by B; the difference should be no more than a few seconds)

d.    what page one wants to access

e.    possibly, other info (later)

So, the host B receiving the request from the user will decrypt this data (knowing from the request that it comes from A, and deducing from it what symmetric key to use for decryption) and, if the time is checked to be ok, open a session with session variables set:

a.    what host A it is from

b.    pseudo

c.    preferred language

Then B sends back to the user the page wanted by one.

If the user already has an opened session to B, A includes to XML only the page the user wants to access.

The user can view the list of opened sessions and close some of them (this will send a logout request from home host to remote host - unless it is a request by the user to the remote host that will inform back the home host).

Thus, GLS must also provide following:

a.    List of bookmarks

b.    List of hosts one has opened sessions to

c.    Computing an XML packet, creating a redirection page

d.    Getting a request from the user who hasn’t been logged in yet and creating a session for him.

Note: A and C points must be implemented separately: the redirection page is needed not only from the bookmarks list, but also from somewhere else.

e.    Remote logout: when A sends a request to B to close user’s session

===========================================================================

 

===========================================================================

#000004: Security

=======================================

 

We have two tasks concerning security problem:

a)    Prevent hackers to trace (decrypt) data stream between the servers

b)    If the case somebody hacks some server, prevent him to access other servers.

 

Earlier we had a solution to use SSL sessions between servers (send XML packets over HTTPS) but recently I’ve been told another idea from the developer of GLS, it is a little more simple but quite as secure as an older one. In a day or two we shall coordinate the solutions and I will include the most suitable into this specification.

 

Concerning the point b), when the user gets the write access to the server, he certainly gets its private key. And he certainly accesses passwords of all the users of the server (even using hash-encrypting does not allow do avoid it: he can modify PHP files and thus create a logging of all the sent login data from logging in users).

 

Anyway, the main idea of security is encrypting outgoing XML packets (from A to B) using the pair (A’s private key, B’s public key) and then decrypting them by B with the pair (B’s private key, A’s public key). That’s how we provide two things:

a)    Security of data transmitting

b)    Confidence of the opponent is who we think he is (absence of the man-in-the-middle changing the received packets).

 

===========================================================================

 

===========================================================================

#000005: Logging in

=======================================

 

There is a little addition.

GLS must include interface for users to login into their home hosts. There are many different parts of the system that are being developed independently, and each of them needs such interface.

 

So there must be a page containing “login” and “password” fields and a submit button. Corresponding table in the DB is already created.

 

When the user clicks submit, in the case the entered data is valid, GLS must create a new session.

GLS must also check such things as session expiration time and changing user’s password.

 

If the user has successfully logged in, then he is shown a welcome page containing links to different parts of the system:

-Forums

-Web mail

-Dating system

...

-Options

-Logout

 

In the “options” menu he sees a link to change password and to choose a place (for example, webmail or forums) to be automatically loaded right after he logs in without showing this page of choices. But from the very beginning, this page must be shown by default.

 

You will have to create a library with a function that would have to be called any time the user navigates to a new page of the system. This library will manage session variables (update session expiration time, etc).

 

===========================================================================