Skip to content
/ j3a Public

J3A - Javascript Authorization, Authentication and Accounting for static web pages. Secure solution, private pages encrypted.

License

Notifications You must be signed in to change notification settings

praserx/j3a

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

51 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

J3A - Javascript authentication, authorization and accounting

Project is under development.

What is it about?

It is all about authorized access to the web pages based on cryptography. With this you can create multiple user accounts with multiple roles and each role can have different access rights. J3A also support secret-key cryptography and public-key cryptography for user login. What does it mean? You can use password type access or certificate type access. Really, it is quite simple. Just use it!

If you want to try it, see demo page. If you want to know more, see documentation.

How it works?

Everyone knows that static web does not provide any secure way to get authorized access to the web page (yeah there is a way throw HTTP authentication header, but it is very limited way). J3A using cryptography and something similar to RBAC (role-based access control) to provide authorized access to web pages. Thanks to AES and RSA are web pages with private content secure also on the web server.

In short, you have to encrypt your site and publish it on the web. After that everyone can get access to the private content via his secret key (crypto key derived from password) or private key. Every user has his own account with assigned roles. Thanks to that you can precisely set access to the private content.

Now we explain how this "crypto system" works and you have to know that this can be quite complicated and maybe confusing. How many crypto keys are used? The answer is too many. Every resource (private content - whole page or part) has own crypto key, every role has own crypto key and every user has own crypto key. There are too many crypto keys and system working something like this:

  1. Encrypt resource (private content) and save crypto key to ACL (ACL resource)
  2. Encrypt every ACL resource and get these crypto keys to relevant roles
  3. Encrypt roles and get these crypto keys to relevant users
  4. Encrypt user with specified password (crypto key derived from pass)

Decryption process is similar. So, what about encryption process? Let suppose, that we have prepared standard static web page (possibly generated by SSG). We have to do this:

  1. Define roles and users
  2. Define private content of web pages
  3. Run postprocessing

After that we have new site with encrypted content, which is ready to deploy.

Do you want to know more?

If you want to know more, it is recommended to read documentation which contains more information about whole system and mechanism.

Static site generators

You can integrate this library to almost every SSG. How? You can simply insert this library to the theme and define private content as new page layout. If user want private page, he just use this page layout.

Hugo SSG integration examples

Jekyll SSG integration examples

coming soon

License

J3A library and other software is under MIT license.

About

J3A - Javascript Authorization, Authentication and Accounting for static web pages. Secure solution, private pages encrypted.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published