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:
===========================================================================
===========================================================================
#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).
===========================================================================