Structure
Instead of
runQuery2|3('query string constructed from params', ...)
the front-end piece will do
['//service/apps/accountsettings/dashboard:api', { ... }, modtask]
The third param is optional and if ommited will mean the current module.
This service launch operator //
should be implemented as follows:
- It will have a standard handleQuery(queryJsonObject, cb) signature
- It will always have success: boolean and optional status:200,...
- :security_context: is the real syntax where the security context could be
* empty is by default the izyware cloud
* localhost
* browser extension
* ....
- each security context will use its own transport layer (i.e. window.post, http, ...) where appropriate
- For the IzyCloud we will use
izy-proxy
apigateway
feature to launch the package, passing the execution context
- The result will be placed in the modtask.outcome object (queryJsonObject may optionally customize this key if it needs to)
The advantage of using the transition style is that:
- easier to read
- easy to transfer to other context
- easier to debug as we will have debugging facilities and tracking tools based on the transition style
- perfect for hybrid apps and mix of local, browser, etc. scenarios
Model
- Users (Identities or IIDs)
- Apps that connect the users to the IzyCloud or thirdparty resources
- IzyCloud that has resouces (databases, email delivery, etc.) that have valuable stuff (information, processing power, access, etc.)
Recommendations
- Use 1 access control table per database.
* This will not not pollute the table schemas with access control information
* Therefore it will decouple the identity and access information from the underlying objects
* Each app will have its own business rules for allowing/disallowing different access to resouces based on the IID and hosting environment. The Izyware will make sure that no tampering is done with the IID and the hosting environment. beyond that it is the responsibility of the app to ensure security requirements.
Users
- There is a single universal izyware managed IID database that izyware will manage
* each user gets a unique IID
* izyware system will handle figuring out the identity of the user via cookies, decide key, etc.
* This is provided to the app via the Izyware framework
Apps
- Apps have differnet privilages that defines which DB/host they have access to.
- Apps will have different packages and each package will have an
execusion context
* execusion context means may run in the browser, in an izynode (backend), etc.
* The front-end packages will be hosted in the browser
* browser js
* front-end stuff
* runQuery and send it to the backend package
* load and execute packages from izyware cloud
* The backend packages will be hosted in the izyware cloud and will be put in the correct security context with the correct access right (i.e. db user, node environment, etc.)
- Apps will define feature flags per each user ID. Each app is responsible for storing and managing the feature flags for each user IID.
- IzyCloud will NOT manage whether or not a user has access to an App. The list of apps that the user sees when they first login, is infact rendered by the
dashboard
app which would need to manage this internally via its own db.
- IzyCloud will provide a simple object storage
per app per user
to allow very simple app configuration out of the box without relying on creating new tables. However, if your app needs to do more complext data operations then you should consider creating tables, normalizing data, etc.
Izy Cloud
- Each request that gets sent to the izy-cloud, will have a sessionID that consists of:
* an appID - this will be generated when the root package is loaded and will get passed onto the loaded app context. the current IID does not access privilages to the app it will be denied.
* an IID - the current user
- The appID will be consumed internally by the IzyCloud to:
* verify that the request is targeting a package that belongs to the app and wont be visible to the app.
* load and run the package in the proper execution context (db acccess, etc.)
- the IID will be passed down to the app package. it is up to the app to enforce business rules for what the users may or may not see (whithin the app limits)
Scenraios
I. A resource shared across different IIDs
An example of this would be the Web Presence App
- Users sign-up and install the app
- The app will get the Session IID from the parent context (in this case it is the IzyWare dashboard)
- The app will 'trust' that the Session IID is not tampered with. This is enforced in the backend secure context because the IID
- The app will use the IID to enforce the following business logic
The business logic
- Each IID will only be able to do CRUD on the domains they added
- Admin IIDs will be able to CRUS on all others
In this scenario, having a domain table with an IID columm is not ideal:
- access control change requests will require updates to domain table
- generally speaking bringing a new table in would be difficult sinc
- would not allow access control for multiple iids
Instead and access control table should be used that
- defines all the access control rules for objects inside the entire db
- apps will honor and use the guideline