**FOR EDUCATIONAL PURPOSES ONLY**
Please subscribe to get credentials to access publications
✅ Subscription Complete !!
Subscribe To Another Document
Enter Credentials (gotten from Owner) to access publications
Processing Request ...
Request Another Document
I hereby define the Entities
that are involved in the architecture, and their roles
The Owner (hosted on mosesike.org)
This is the entity that produces or owns the documents and wishes to delegate access control of his documents to the third-party publisher.
The Owner accepts subscription request from users, and issues them credentials.
The owner is responsible of specifying his access control policies based on user subscriptions and licenses (access duration or lifetimes).
The Owner maintains a repository of his documents, an updatable policy and a credential base of all his registrants.
The Publisher (hosted on Amazon EC2 Cloud)
This is the entity that hosts the owner’s documents in his cloud infrastructure.
The publisher’s is responsible for enforcing the access control policies of the owner against the users who requests access to the owner’s documents.
The publisher maintains copies of the owner’s documents, and an updatable access control policy from the owner for each document.
The User (your browser)
This is the entity that needs and request access to the owner’s documents hosted by the publisher.
The User is responsible for first securing credentials from the owner through subscription or registration,
and then query the publisher with those acquired credentials to access to the intended documents.
- A user visits the URL of the publisher’s web application, which contains a web portal of the owner where the user can subscribe to get credentials to a document.
- The users subscribes or registers with the owner (through the portal) for a set of documents he needs access to,
and is given a security token which composes of his identity information, access token, license lifetime, and cryptographic secure random number.
- The owner updates his credential base with the new users subscription information and communicates the new user’s authorizations with the publisher.
- The publisher updates his local access control policy of the owner’s documents.
- The user uses the security token he got from the owner to query the publisher, and if successful, is presented the document with restrictions based on his authorizations.
- Confidentiality (Symmetric Encryption)
- Integrity (Secure Hash Algorithm)
- Authenticity (Message Authentication Code)
- Freshness Guarantees (Time Stamps)
- One-Time-Key/Pad (Perfect Secrecy)
- Non SQL Database (Immune to SQL Injection)
- WS-Security (Secure Policy Enforcement)
- Cryptographic Secure Pseudo Random Number Generator
The user uses the web application to send his credentials to the Publisher requesting access to a document.
The protocol used is HTTPS so the channel has integrity and confidentiality.
The publisher verifies the credentials against the owner’s access control policy,
and if valid, it issues a document link to the user’s browser to retrieve the document. But....
One Time Key/Pad ??
The document link sent to the browser contains an 128bit hex string (referred to as an OTP-token), which is an encryption output
of the user's username with a cryptographic secure 128bit random key (referred to as a One-Time-Pad or OTP). This OTP is communicated to the
Document Access Server (a component of the publisher's side system). The browser uses its OTP-token to authenticate itself to the Document Access Server,
who verifies it by performing the same encryption and comparing.
The One-Time-Pad is only good for one request, and is discarded after a request is satisfied. This way the document access server is secured against any form of replay or spoof attacks.
Hacking a One Time Pad is almost impossible since it is only used once, and its generated by a cryptographic secure pseudo random number generator (PRNG)
The communication channel between the owner and publisher is encrypted because of the sensitivity of the information being transferred.
The owner transfers his updated access policy, user identity, and sometimes new documents to the publisher, so the traffic channel need to be secured.
Security measures include confidentiality by symmetric encryption, integrity by hashing algorithm, and authenticity by message authentication code.
Integrity and authenticity can be combined in a message authentication code. The Owner communications with the Publisher using SOAP,
and security policy is specified and enforced by WS-Security.
Every secured communication carries a timestamp that guarantees FRESHNESS of the message.
Hence the system is protected against Replay Attacks.
The user visits the website using HTTPS which guarantees the confidentiality and integrity of the web application.
This implies that the security token returned by the owner to the user is confidential.
The web page contains the owner’s portal which implements an AJAX API to the owner’s server app.
It also contains the Publisher’s portal which implements an AJAX API to the publishers server app.
Immune to SQL Injection/Attack
PHP is the main programming language used on the server side to implement administration and management of document store, credential base, and policy specification.
The database where all this resources are stored is not SQL, but a simple custom database management system I created using directory structures and tree hierarchical definitions.
Hence my system is immune to SQL Injection attacks.