opennetadmin/ona-core

New core components for ONA. Implements core logic and a REST interface.

ona-core's Issues

Auth statements. several to be implemented still.

The following is a list of statements defining out Authentication is working. Trying to capture a small bit of documentation as well as the ideas yet to be implemented.

• By default all tokens will have a STD expiration time of say 1 hour.
• There are two types of user accounts. Standard user and Service Account (for server 2 server). A flag indicating which type should be set for all users. Default would likely be standard user.
• All user types will use the /login endpoint to get a token.
• The token obtained from the /login endpoint needs to be stored in a secure way. Typically for standard users this would be in a cookie or http storage on the browser. Service accounts would likely store the token on the filesystem. Those must be treated appropriately with only limited access and not copied around etc.
• The user type setting will control the expiration date on the token.. Service accounts will have a multi year expiration and thus never expire.
• Tokens will be generated specifically for the client IP that initiated the /login transaction.
• Tokens will contain user identification to be used to look up permissions each time the token is used in a transaction. This way longer lived tokens can have specific permissions revoked from the user.
• The signing key for the tokens will be specific to each instance of ona-core. This can be a random number generated for that specific install of ona-core. Provide a way to ensure it is unique for each instance as part of installation.
• Tokens that do not expire should have a JTI associated with them that is tracked and revokable.
• If multiple service account logins happen from a specific client, then the old JTI should be stored in a revoke table.
• There should only ever be one token for a service account associated with a specific IP address that is active.